gmane.comp.emulators.qemu

Re: Signal management in qemu-user

Alex Barcelo — 2012-05-24T07:19:34

Ok, makes sense.


I see. But, does qemu-system play this sort of game? I haven't been
able to find this sort of protect-catch-unprotect for execution, and
my goal is to run qemu-system on top of qemu-user. The self-modifying
code is done through the write protection of memory pages, but I can't
see which would be the root problem. It seems that self-modifying code
is done in two levels, in qemu-user and in qemu-system, but this
should not be a problem... once the signal mask is correctly managed
by usermode. Am I right?

I plan to bugfix the usermode masking problem as best as I can, but
first I wanted to make sure that this will bring me closer to the
goal.

Thanks a lot for your time and patience

Re: [PATCH 1.1] audio: Always call fini on exit

Gerd Hoffmann — 2012-05-24T07:11:51

I think you better call VOICE_DISABLE only in case the voice is actually
enabled.


Likewise.


cheers,
  Gerd

Re: [PATCH 1.1] audio: Always call fini on exit

Gerd Hoffmann — 2012-05-24T07:10:37

Waded through the source.  Have to agree with Jan here: Handling this
via VOICE_{ENABLE,DISABLE} isn't going to fly.  It would mean to move
the complete pulseaudio setup (connect to daemon, create streams, create
worker thread, ...).from init() to VOICE_ENABLE so we can cleanup in
VOICE_DISABLE and don't need fini().  This isn't how it is supposed to
work ...

cheers,
  Gerd

Re: [PATCHv2 1/3] ui/spice-display.c: add missing initialization for valgrind

Gerd Hoffmann — 2012-05-24T06:51:40

Ah, yea, copying will make valgrind complain of course ...

I'll go queue it up.

cheers,
  Gerd

Re: [PATCH] Support virtio-scsi-pci adapter hot-plug

Michael S. Tsirkin — 2012-05-24T06:51:38

Let's separate bugfixes from adding new commands.


No, it has support costs.

Re: [PATCHv2 1/3] ui/spice-display.c: add missing initialization for valgrind

Alon Levy — 2012-05-24T06:43:47

Because we allocate this struct on the stack and then copy it over an fd
to spice, through the dispatcher pipe.

echo quit | valgrind --log-file=/tmp/valgrind.log
--leak-check=full ./x86_64-softmmu/qemu-system-x86_64 -monitor stdio
-spice port=1234 -vga qxl

==2677== Syscall param write(buf) points to uninitialised byte(s)
==2677==    at 0x659504D: ??? (syscall-template.S:82)
==2677==    by 0x91BCD54: write_safe (dispatcher.c:103)
==2677==    by 0x91BD168: dispatcher_send_message (dispatcher.c:182)
==2677==    by 0x91BEC24: red_dispatcher_create_primary_surface_sync (red_dispatcher.c:489)
==2677==    by 0x91BECAD: red_dispatcher_create_primary_surface (red_dispatcher.c:502)
==2677==    by 0x91BED03: qxl_worker_create_primary_surface (red_dispatcher.c:509)
==2677==    by 0x3403CC: qemu_spice_create_primary_surface (spice-display.c:106)
==2677==    by 0x340BAB: qemu_spice_create_host_primary (spice-display.c:260)
==2677==    by 0x40EC50: qxl_enter_vga_mode (qxl.c:931)
==2677==    by 0x40EFCA: qxl_soft_reset (qxl.c:982)
==2677==    by 0x40F088: qxl_hard_reset (qxl.c:1004)
==2677==    by 0x40F0DA: qxl_reset_handler (qxl.c:1011)
==2677==  Address 0x7feffef98 is on thread 1's stack

Re: [PATCH] Support virtio-scsi-pci adapter hot-plug

Kelvin Wang — 2012-05-24T06:31:00

So, may I sent another patch to "avoid need for manual bus rescans"?
device_add should be used by users, but another way supplied to users is not
necessarily, but always harmless, right?

Re: [PATCH] Support virtio-scsi-pci adapter hot-plug

Kelvin Wang — 2012-05-24T05:43:26

OK, Thanks!
Ouch, ashamed for my carelessness.

Re: Virtio-pci issue

Evgeny Voevodin — 2012-05-24T03:18:33

Oh, thanks a lot, Stefan! As soon as I have a time to continue 
refactoring, I'll check this functionality.
And also there is another problem that I've faced with. It is the 
ability to plug as many pci back-ends as board wants.
I mean that if for each back-end board should create a transport, then 
user have to know maximum number of transport instances
created by board. In the case of mmio transport I think that it's a 
correct behaviour, but for pci transport seems not.

[Bug 393430] Re: kvm: use PulseAudio instead of ALSA

Serge Hallyn — 2012-05-23T22:34:20

** Changed in: kvm (Ubuntu)
       Status: Incomplete => Fix Released

[PATCH] version: update version info

2012-05-24T02:54:46

From: Zhi Yong Wu <wuzhy< at >linux.vnet.ibm.com>

Signed-off-by: Zhi Yong Wu <wuzhy< at >linux.vnet.ibm.com>
---
 VERSION |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/VERSION b/VERSION
index 87903b6..9084fa2 100644
--- a/VERSION
+++ b/VERSION
< at >< at > -1 +1 < at >< at >
-1.0.93
+1.1.0

Re: [PATCH] TCG: Fix TB invalidation after breakpointinsertion/deletion

Jan Kiszka — 2012-05-24T02:44:25

Sorry, forgot the tag: this should go in before 1.1 of course.

Re: [PATCH v2 13/15] net: Remove obsolete vlan info

Zhi Yong Wu — 2012-05-24T02:42:59

As you have known, vlan concept is replaced with hub. So i think that
it is more reasonable to remove this in monitor.

(qemu) info network
  virtio-net-pci.0: type=nic,model=virtio-net-pci,macaddr=52:54:00:12:34:56
   \ hub0port0: type=(null),
  virtio-net-pci.1: type=nic,model=virtio-net-pci,macaddr=52:54:00:12:34:57
   \ hub1port0: type=(null),
hub 1
    port 1 peer user.1
    port 0 peer virtio-net-pci.1
hub 0
    port 1 peer user.0
    port 0 peer virtio-net-pci.0

[PATCH] Clarify comments oftb_invalidate_phys_[page_]range

Jan Kiszka — 2012-05-24T02:41:53

From: Jan Kiszka <jan.kiszka< at >siemens.com>

They could suggest that all TBs of the page containing the range would
be invalidated.

Signed-off-by: Jan Kiszka <jan.kiszka< at >siemens.com>
---
 exec.c |   22 ++++++++++++----------
 1 files changed, 12 insertions(+), 10 deletions(-)

diff --git a/exec.c b/exec.c
index efa1345..a1c12ec 100644
--- a/exec.c
+++ b/exec.c
< at >< at > -1076,11 +1076,11 < at >< at > TranslationBlock *tb_gen_code(CPUArchState *env,
 }
 
 /*
- * invalidate all TBs which intersect with the target physical pages
- * starting in range [start;end[. NOTE: start and end may refer to
- * different physical pages. 'is_cpu_write_access' should be true if called
- * from a real cpu write access: the virtual CPU will exit the current
- * TB if code is modified inside this TB.
+ * Invalidate all TBs which intersect with the target physical address range
+ * [start;end[. NOTE: start and end may refer to *different* physical pages.
+ * 'is_cpu_write_access' should be true if called from a real cpu write
+ * access: the virtual CPU will exit the current TB if code is modified inside
+ * this TB.
  */
 void tb_invalidate_phys_range(tb_page_addr_t start, tb_page_addr_t end,
                               int is_cpu_write_access)
< at >< at > -1092,11 +1092,13 < at >< at > void tb_invalidate_phys_range(tb_page_addr_t start, tb_page_addr_t end,
     }
 }
 
-/* invalidate all TBs which intersect with the target physical page
-   starting in range [start;end[. NOTE: start and end must refer to
-   the same physical page. 'is_cpu_write_access' should be true if called
-   from a real cpu write access: the virtual CPU will exit the current
-   TB if code is modified inside this TB. */
+/*
+ * Invalidate all TBs which intersect with the target physical address range
+ * [start;end[. NOTE: start and end must refer to the *same* physical page.
+ * 'is_cpu_write_access' should be true if called from a real cpu write
+ * access: the virtual CPU will exit the current TB if code is modified inside
+ * this TB.
+ */
 void tb_invalidate_phys_page_range(tb_page_addr_t start, tb_page_addr_t end,
                                    int is_cpu_write_access)
 {

Re: The image size of instance VM keeps growing

Charles.Tsai-蔡清海-研究發展部 — 2012-05-24T02:35:46

Thanks. Good alternative view.

-----Original Message-----
From: Michael Tokarev [mailto:mjt< at >tls.msk.ru] 
Sent: Wednesday, May 23, 2012 9:11 PM
To: Stefan Hajnoczi
Cc: Charles.Tsai-蔡清海-研究發展部; Jonah.Wu-吳君勉-研究發展部; qemu-devel< at >nongnu.org
Subject: Re: [Qemu-devel] The image size of instance VM keeps growing

On 23.05.2012 16:57, Stefan Hajnoczi wrote:
[]

Dont't forget about possible snapshots inside the qcow2 file.  So it is quite well possible to have qcow2 file sized much larger than virtual disk size :)

/mjt

[PATCH] TCG: Fix TB invalidation after breakpointinsertion/deletion

Jan Kiszka — 2012-05-24T02:34:34

From: Jan Kiszka <jan.kiszka< at >siemens.com>

tb_invalidate_phys_addr has to called with the exact physical address of
the breakpoint we add/remove, not just the page's base address.
Otherwise we easily fail to flush the right TB.

Regression of 1e7855a558.

Reported-by: TeLeMan <geleman< at >gmail.com>
Signed-off-by: Jan Kiszka <jan.kiszka< at >siemens.com>
---
 exec.c |    3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/exec.c b/exec.c
index a0494c7..efa1345 100644
--- a/exec.c
+++ b/exec.c
< at >< at > -1492,7 +1492,8 < at >< at > void tb_invalidate_phys_addr(target_phys_addr_t addr)
 
 static void breakpoint_invalidate(CPUArchState *env, target_ulong pc)
 {
-    tb_invalidate_phys_addr(cpu_get_phys_page_debug(env, pc));
+    tb_invalidate_phys_addr(cpu_get_phys_page_debug(env, pc) +
+                            (pc & ~TARGET_PAGE_MASK));
 }
 #endif
 #endif /* TARGET_HAS_ICE */

Re: The image size of instance VM keeps growing

Charles.Tsai-蔡清海-研究發展部 — 2012-05-24T02:33:59

Stefan,

Thank you for information. What we worried is an endless growth of the image size.
If virtual disk size is the ceiling of the max. image size to be grew, we should not have to worry about this issue.

-----Original Message-----
From: Stefan Hajnoczi [mailto:stefanha< at >gmail.com] 
Sent: Wednesday, May 23, 2012 8:57 PM
To: Charles.Tsai-蔡清海-研究發展部
Cc: qemu-devel< at >nongnu.org; Jonah.Wu-吳君勉-研究發展部
Subject: Re: [Qemu-devel] The image size of instance VM keeps growing

On Wed, May 23, 2012 at 11:47 AM, Charles.Tsai-蔡清海-研究發展部
<charles.tsai< at >cloudena.com> wrote:

What is the size of the backing file?  3G is small for a Windows guest.  Any sector that is written to could cause 64 KB to be allocated in the image file.

If qemu-img check sees no inconsistencies then it seems the guest is writing to previously untouched regions of the disk...causing the
qcow2 to grow.

However, the qcow2 file should not grow much beyond its virtual disk size.  So if you find the qcow2 is 3G but the virtual disk size is 1G, then there is a bug.  But from what you've posted so far I suspect the guest is simply writing to the disk.

Stefan

Re: [PATCH] exec: fix breakpoint_invalidate() breakage

Jan Kiszka — 2012-05-24T02:21:12

Oops, too fast: in fact the introductory comment of
tb_invalidate_phys_page_range is misleading, there is a sub-page-level
range check. And now my test also actually triggers. Was probably
running the wrong qemu version before.

Jan

Re: [PATCH] exec: fix breakpoint_invalidate() breakage

TeLeMan — 2012-05-24T02:16:59

     if (!(tb_end <= start || tb_start >= end)) {
...
          tb_phys_invalidate(tb, -1);
...
     }

If start is wrong, tb_phys_invalidate() may not be called.

Re: [PATCH] exec: fix breakpoint_invalidate() breakage

TeLeMan — 2012-05-24T02:12:49

Sorry, I did't notice this rule before. Now I don't want to violate
it. But I confuse myself if TeLeMan can be as my real name. Actually
TeLeMan is not my Chinese name. I used TeLeMan as my nickname and
English name. In other words TeLeMan can identify myself. I won't use
my Chinese name because I think it's my privacy. I used QEMU to do my
researching tools not as Andreas imagined.

Re: [PATCH] exec: fix breakpoint_invalidate() breakage

Jan Kiszka — 2012-05-24T02:00:44

The tb containing 0x1234 would be linked to the list of TBs that are
related to the 0x1000 page. As we declare that page invalid, all
affected TBs are dropped, not just the one containing the breakpoint.
See tb_invalidate_phys_page_range.

Jan