Re: [Qemu-devel] Use of flash for x86 BIOS
On 03/23/2013 03:09 AM, Jordan Justen wrote: Admittedly, I've been completely ineffectual in resolving the kvm portion. More recently I tried to make use of KVM_MEM_READONLY to address this. I was able to get an VM exit on writes to flash, but not able to get the memory region to convert to full device mode so VM exits would occur on reads as well. I am once again stalled... Hi Jordan, What's memory region you want to get? I should admit that I do not have enough background of flash, could you please explain this requirement more detail? Thanks!
Re: [Qemu-devel] [PATCH 1/1] rng backend: open backend in blocking mode
On (Wed) 03 Apr 2013 [15:08:40], Anthony Liguori wrote: Amit Shah amit.s...@redhat.com writes: On (Tue) 02 Apr 2013 [07:52:19], Anthony Liguori wrote: Amit Shah amit.s...@redhat.com writes: backends/rng-random.c:44:entropy_available: assertion failed: (len != -1) without this fix. This fix would cause QEMU to block indefinitely which I don't think is very good behavior. I think a better solution would be: How about relegating it to glib functions, and hooking it up so that /dev/random is polled for data, and this function gets called when /dev/random has data to give out? Sure, when a read is attempted, there might be no data available again, but we could then go back to polling. The fix I posted minus the needed s/EINTR/EAGAIN/g is pretty straight forward and IMHO the proper way to handle this. Is there something you think is broken with it? I guess I should turn it into a real patch but I was hoping you would so I didn't have to recreate the original problem :-) Oh yes, I'll do that and test, and will submit a patch. My concern is just that we'll forget checking for EINTR and fall into these traps with open-coded read() calls instead of using wrappers. Amit
Re: [Qemu-devel] [RFC qemu PATCH] only writing out the last byte of MAC makes it have effect
On Mon, Mar 25, 2013 at 08:58:49AM +0200, Michael S. Tsirkin wrote:
On Mon, Mar 25, 2013 at 10:23:57AM +0800, Amos Kong wrote:
On Fri, Mar 22, 2013 at 10:45:09AM +1030, Rusty Russell wrote:
Michael S. Tsirkin m...@redhat.com writes:
On Thu, Mar 21, 2013 at 02:44:50PM +0800, Amos Kong wrote:
The lengcy guests don't have mac programming command, we don't know
when
it's safe to use MAC. This patch changed qemu to makes MAC change
effect
when the last byte of MAC is written to config space.
MAC address takes first 6 bytes of config space of virtio-net, the addr
is 5 when the last byte is written in virtio_config_writeb().
MAC change will effect when n-mac is updated in
virtio_net_set_config().
Signed-off-by: Amos Kong ak...@redhat.com
Let's see what Rusty says about the spec change.
Implementation notes like this belong as a footnote, eg:
For older systems, it is recommended and typical that the device
write byte 5 of the mac address last, so devices can use that as
a trigger to commit the mac address change.
Now, is this a real, or theoretical issue? Have we seen this problem in
practice, or should we continue to ignore it?
Hi Rusty, Michael
I didn't touch any problem. MST, and you?
In Linux guest, we should disable the interface before changing mac address.
ifconfig eth0 down
ifconfig eth0 hw ether 10:12:13:14:15:16
ifconfig eth0 up
In Windows 7 guest, after changing mac address in register table,
re-enabling interface to make it effect.
reg add HKLM
SYSTEM\CurrentControlSet\Control\Class\{4D36E972-E325-11CE-BFC1-08002BE10318}\0001]
/v NetworkAddress /d 0123456789AB
netsh interface set interface Local Area Connection DISABLED
netsh interface set interface Local Area Connection ENABLED
So when we change the mac address, guest os always disable interface
to receive all packages. It seems the theoretical issue doesn't exist?
Cheers,
Rusty.
--
Amos.
Nope. Looks like no spec change is necessary. We already say it's
not atomic and it looks like guests expect exactly that
and disable link to prevent strange issues.
I just found Jiri has a commit to allow changing mac when iface
is running. It seems only the virt nics are allowned, right?
But the leagcy guests don't allow to change mac when interface is
running, so no spec change is necessary.
[upstream kernel]
commit d4fc6918f4b3cc844185f59fc518351525950449
Author: Jiri Pirko jpi...@redhat.com
Date: Wed Jun 27 05:27:46 2012 +
virtio_net: allow to change mac when iface is running
Signed-off-by: Jiri Pirko jpi...@redhat.com
Signed-off-by: David S. Miller da...@davemloft.net
RH-BZ: https://bugzilla.redhat.com/show_bug.cgi?id=882868
--
Amos.
Re: [Qemu-devel] [PATCH arm-devs v1 05/15] xilinx_spips: lqspi: Dont trash config register
Hi Peter, On Sat, Apr 6, 2013 at 4:46 AM, Peter Maydell peter.mayd...@linaro.org wrote: On 3 April 2013 05:32, Peter Crosthwaite peter.crosthwa...@xilinx.com wrote: The LQSPI code currently manipulates the config register to achieve its ends. Some (agressively designed) drivers assume that the config register preserves state across a transition into and out of LQSPI mode. Fixed by just restoring R_CONFIG to its original value after LQSPI does its thing. Signed-off-by: Peter Crosthwaite peter.crosthwa...@xilinx.com --- hw/xilinx_spips.c |3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/hw/xilinx_spips.c b/hw/xilinx_spips.c index 29636ce..06c2ec5 100644 --- a/hw/xilinx_spips.c +++ b/hw/xilinx_spips.c @@ -467,6 +467,7 @@ lqspi_read(void *opaque, hwaddr addr, unsigned int size) int flash_addr = (addr / num_effective_busses(s)); int slave = flash_addr LQSPI_ADDRESS_BITS; int cache_entry = 0; +uint32_t r_config_save = s-regs[R_CONFIG]; DB_PRINT(config reg status: %08x\n, s-regs[R_LQSPI_CFG]); @@ -512,6 +513,8 @@ lqspi_read(void *opaque, hwaddr addr, unsigned int size) s-regs[R_CONFIG] |= CS; xilinx_spips_update_cs_lines(s); +s-regs[R_CONFIG] = r_config_save; +xilinx_spips_update_cs_lines(s); q-lqspi_cached_addr = addr; return lqspi_read(opaque, addr, size); -- 1.7.0.4 Is this a we don't implement this the way the hardware does but this is close enough kind of thing? (in particular does the hardware really do the same thing to the cs lines that those two calls to update_cs_lines() presumably do?) No. Turns out I obsoleted by own patch. The Automatic CS feature (introduced later in the series) is how LQSPI is supposed to work its CSs. Creating a new patch after the auto CS that fixes this. This patch is a goner. Regards, Peter about what we do vs what hardware does / what we theoretically ideally should do, if you happen to know. -- PMM
Re: [Qemu-devel] [PATCH arm-devs v1 06/15] xilinx_spips: Fix QSPI FIFO size
On Sat, Apr 6, 2013 at 4:50 AM, Peter Maydell peter.mayd...@linaro.org wrote: On 3 April 2013 05:32, Peter Crosthwaite peter.crosthwa...@xilinx.com wrote: QSPI has a bigger FIFO than the regular SPI controller. Differentiate between the two with correct FIFO sizes for each. Signed-off-by: Peter Crosthwaite peter.crosthwa...@xilinx.com --- hw/xilinx_spips.c |7 +++ 1 files changed, 7 insertions(+), 0 deletions(-) diff --git a/hw/xilinx_spips.c b/hw/xilinx_spips.c index 06c2ec5..78a3fec 100644 --- a/hw/xilinx_spips.c +++ b/hw/xilinx_spips.c @@ -106,6 +106,9 @@ #define RXFF_A 32 #define TXFF_A 32 +#define RXFF_A_Q (64 * 4) +#define TXFF_A_Q (64 * 4) + /* 16MB per linear region */ #define LQSPI_ADDRESS_BITS 24 /* Bite off 4k chunks at a time */ @@ -575,6 +578,10 @@ static void xilinx_qspips_realize(DeviceState *dev, Error **errp) s-num_txrx_bytes = 4; xilinx_spips_realize(dev, errp); +fifo8_destroy(s-rx_fifo); +fifo8_destroy(s-tx_fifo); +fifo8_create(s-rx_fifo, RXFF_A_Q); +fifo8_create(s-tx_fifo, TXFF_A_Q); memory_region_init_io(s-mmlqspi, lqspi_ops, s, lqspi, (1 LQSPI_ADDRESS_BITS) * 2); sysbus_init_mmio(sbd, s-mmlqspi); Destroying and recreating the fifos seems a bit odd -- can you structure this so the base class instance init just creates them at the right size? I guess the obvious way would be to have the class struct have a field for fifo size which the class init function sets appropriately, and then instance init creates a fifo of that size. Done. Regards, Peter This is kind of like how target-arm/cpu.c handles ID register fields, but in the class rather than the instance struct. -- PMM
Re: [Qemu-devel] Use of flash for x86 BIOS
On Sun, Apr 7, 2013 at 11:06 PM, Xiao Guangrong xiaoguangr...@linux.vnet.ibm.com wrote: On 03/23/2013 03:09 AM, Jordan Justen wrote: Admittedly, I've been completely ineffectual in resolving the kvm portion. More recently I tried to make use of KVM_MEM_READONLY to address this. I was able to get an VM exit on writes to flash, but not able to get the memory region to convert to full device mode so VM exits would occur on reads as well. I am once again stalled... Hi Jordan, What's memory region you want to get? I should admit that I do not have enough background of flash, could you please explain this requirement more detail? The flash memory requires two modes. Read/Execute mode: * Initial state * Writes will trap to QEMU, and may transition to Device mode based on QEMU device emulation Device mode: * Region is not executable * All reads writes will trap to QEMU * May transition back to Read/Execute mode based on QEMU device emulation Using KVM_MEM_READONLY I was able to get Read/Execute mode to work, but I was not able to get the memory region to transition to Device mode. (I couldn't get reads to trap to QEMU.) -Jordan
Re: [Qemu-devel] [PATCH arm-devs v1 07/15] xilinx_spips: Trash LQ page cache on mode change
Hi Peter,
On Sat, Apr 6, 2013 at 4:53 AM, Peter Maydell peter.mayd...@linaro.org wrote:
On 3 April 2013 05:32, Peter Crosthwaite peter.crosthwa...@xilinx.com wrote:
Invalidate the LQSPI cached page when transitioning into LQSPI mode.
Otherwise there is a possibility that the controller will return stale
data to the guest when transitioning back to LQ_MODE after a page
program.
Signed-off-by: Peter Crosthwaite peter.crosthwa...@xilinx.com
---
hw/xilinx_spips.c |8
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/hw/xilinx_spips.c b/hw/xilinx_spips.c
index 78a3fec..4f921f8 100644
--- a/hw/xilinx_spips.c
+++ b/hw/xilinx_spips.c
@@ -390,6 +390,9 @@ static void xilinx_spips_write(void *opaque, hwaddr addr,
int mask = ~0;
int man_start_com = 0;
XilinxSPIPS *s = opaque;
+/* FIXME: abstract away somehow */
+XilinxQSPIPS *q = (XilinxQSPIPS *)object_dynamic_cast(OBJECT(s),
+ TYPE_XILINX_QSPIPS);
Hmm, a C cast of the result of an object_dynamic_cast()?
Would be nice to do this some other way... Maybe a member
function (ie fn ptr in the class struct) which does nothing
on SPIPS and clears the cached page on QSPIPS?
Went a different route. Added the MemoryRegionOps to the class instead
and switched that out on class init. qspis alternate write handler
just calls spis then does its side effects on top. This way, spi has
no awareness of qspi which is more ideal the child class specific
abstract fns in the base class def.
Regards,
Peter
DB_PRINT(addr= TARGET_FMT_plx = %x\n, addr, (unsigned)value);
addr = 2;
@@ -435,6 +438,11 @@ static void xilinx_spips_write(void *opaque, hwaddr
addr,
case R_TXD3:
tx_data_bytes(s, (uint32_t)value, 3);
goto no_reg_update;
+case R_LQSPI_CFG:
+if (q) {
+q-lqspi_cached_addr = ~0ULL;
+}
+break;
}
s-regs[addr] = (s-regs[addr] ~mask) | (value mask);
no_reg_update:
--
1.7.0.4
-- PMM
Re: [Qemu-devel] [PATCH arm-devs v1 11/15] xilinx_spips: Fix striping behaviour
Hi Peter,
On Sat, Apr 6, 2013 at 4:59 AM, Peter Maydell peter.mayd...@linaro.org wrote:
On 3 April 2013 05:33, Peter Crosthwaite peter.crosthwa...@xilinx.com wrote:
The QSPI controller was using byte-wide stripes when striping across
the two flashes in dual parallel mode. The real hardware however uses
individual bit striping. QEMU misbehaves in the (corner) case where
data is written/read in dual-parallel mode and read/written back in
single mode.
Signed-off-by: Peter Crosthwaite peter.crosthwa...@xilinx.com
---
hw/xilinx_spips.c | 74
++---
1 files changed, 53 insertions(+), 21 deletions(-)
diff --git a/hw/xilinx_spips.c b/hw/xilinx_spips.c
index a2019e4..43ce2d8 100644
--- a/hw/xilinx_spips.c
+++ b/hw/xilinx_spips.c
@@ -258,35 +258,67 @@ static void xilinx_spips_reset(DeviceState *d)
xilinx_spips_update_cs_lines(s);
}
+static inline void stripe8(uint8_t *x, int num, bool dir)
+{
+uint8_t r[num];
+memset(r, 0, sizeof(uint8_t) * num);
Don't interleave code and variable definitions, please.
+int idx[2] = {0, 0};
+int bit[2] = {0, 0};
+int d = dir;
+
+for (idx[0] = 0; idx[0] num; ++idx[0]) {
+for (bit[0] = 0; bit[0] 8; ++bit[0]) {
+r[idx[d]] |= x[idx[!d]] 1 bit[!d] ? 1 bit[d] : 0;
+idx[1] = (idx[1] + 1) % num;
+if (!idx[1]) {
+bit[1]++;
+}
+}
+}
+memcpy(x, r, sizeof(uint8_t) * num);
+}
This function could really use a comment saying what it's doing...
+/* N way (num) in place bit striper. Lay out row wise bits (LSB to MSB)
+ * column wise (from element 0 to N-1). num is the length of x, and dir
+ * reverses the direction of the transform. Best illustrated by example:
+ * Each digit in the below array is a single bit (num == 3):
+ *
+ * {{ 76543210, } - stripe (dir == false) - {{ FCheb630, }
+ * { hgfedcba, } { GDAfc741, }
+ * { HGFEDCBA, }} upstripe (dir == true) - { HEBgda52, }}
+ */
+
Regards,
Peter
thanks
-- PMM
Re: [Qemu-devel] [PATCH arm-devs v1 15/15] xilinx_spips: lqspi: Fix byte/misaligned access
On Sat, Apr 6, 2013 at 5:01 AM, Peter Maydell peter.mayd...@linaro.org wrote:
On 3 April 2013 05:33, Peter Crosthwaite peter.crosthwa...@xilinx.com wrote:
The LQSPI bus attachment supports byte/halfword and misaligned
accesses. Fixed. Refactored the LQSPI cache to be byte-wise
instead of word wise accordingly.
Signed-off-by: Peter Crosthwaite peter.crosthwa...@xilinx.com
---
hw/xilinx_spips.c | 31 +--
1 files changed, 17 insertions(+), 14 deletions(-)
diff --git a/hw/xilinx_spips.c b/hw/xilinx_spips.c
index 32d8db8..cb45a9c 100644
--- a/hw/xilinx_spips.c
+++ b/hw/xilinx_spips.c
@@ -160,7 +160,7 @@ typedef struct {
typedef struct {
XilinxSPIPS parent_obj;
-uint32_t lqspi_buf[LQSPI_CACHE_SIZE];
+uint8_t lqspi_buf[LQSPI_CACHE_SIZE];
Is it really right that this buffer isn't in the vmstate,
by the way?
Yes,
Its a software transparent cache. The cache is lost on migration. Post
load the first access just refreshes the cache and the guest is none
the wiser.
Regards.
{eter
hwaddr lqspi_cached_addr;
} XilinxQSPIPS;
-- PMM
Re: [Qemu-devel] [PATCHv5 06/10] migration: search for zero instead of dup pages
Am 05.04.2013 um 21:23 schrieb Kevin Wolf kw...@redhat.com: Am 26.03.2013 um 10:58 hat Peter Lieven geschrieben: virtually all dup pages are zero pages. remove the special is_dup_page() function and use the optimized buffer_find_nonzero_offset() function instead. here buffer_find_nonzero_offset() is used directly to avoid the unnecssary additional checks in buffer_is_zero(). raw performace gain checking 1 GByte zeroed memory over is_dup_page() is approx. 10-12% with SSE2 and 8-10% with unsigned long arithmedtic. Signed-off-by: Peter Lieven p...@kamp.de Reviewed-by: Orit Wasserman owass...@redhat.com Reviewed-by: Eric Blake ebl...@redhat.com Okay, so I bisected again and this is the second patch that is involved in the slowness of qemu-iotests case 007. Can you try if the following solves your issue: diff --git a/exec.c b/exec.c index 786987a..54baa4a 100644 --- a/exec.c +++ b/exec.c @@ -1071,6 +1071,7 @@ ram_addr_t qemu_ram_alloc_from_ptr(ram_addr_t size, void *host, memory_try_enable_merging(new_block-host, size); } } +qemu_madvise(new_block-host, size, QEMU_MADV_DONTNEED); new_block-length = size; /* Keep the list sorted from biggest to smallest block. */ BR, Peter
Re: [Qemu-devel] [PATCHv5 06/10] migration: search for zero instead of dup pages
Il 06/04/2013 00:06, Peter Lieven ha scritto: I think we should MADV_DONTNEED it. i have to correct myself, on Linux it seems that MADV_DONTNEED guarantees that subsequent reads will return a zero filled page. If I am right with that we could MADV_DONTNEED the memory on startup and keep not sending zero pages in bulk stage if we are running under Linux. Am I right with that? Actually we can use mmap+munmap to allocate a well-aligned, always zero block for the RAM. Paolo
Re: [Qemu-devel] [PATCHv5 06/10] migration: search for zero instead of dup pages
Am 08.04.2013 um 10:33 schrieb Peter Lieven p...@kamp.de:
Am 05.04.2013 um 21:23 schrieb Kevin Wolf kw...@redhat.com:
Am 26.03.2013 um 10:58 hat Peter Lieven geschrieben:
virtually all dup pages are zero pages. remove
the special is_dup_page() function and use the
optimized buffer_find_nonzero_offset() function
instead.
here buffer_find_nonzero_offset() is used directly
to avoid the unnecssary additional checks in
buffer_is_zero().
raw performace gain checking 1 GByte zeroed memory
over is_dup_page() is approx. 10-12% with SSE2
and 8-10% with unsigned long arithmedtic.
Signed-off-by: Peter Lieven p...@kamp.de
Reviewed-by: Orit Wasserman owass...@redhat.com
Reviewed-by: Eric Blake ebl...@redhat.com
Okay, so I bisected again and this is the second patch that is involved
in the slowness of qemu-iotests case 007.
actually this might be better?!:
diff --git a/exec.c b/exec.c
index 786987a..334a46e 100644
--- a/exec.c
+++ b/exec.c
@@ -1071,6 +1071,11 @@ ram_addr_t qemu_ram_alloc_from_ptr(ram_addr_t size, void
*host,
memory_try_enable_merging(new_block-host, size);
}
}
+if (mem_prealloc) {
+memset(new_block-host, size, 0x00);
+} else {
+qemu_madvise(new_block-host, size, QEMU_MADV_DONTNEED);
+}
new_block-length = size;
/* Keep the list sorted from biggest to smallest block. */
Re: [Qemu-devel] Use of flash for x86 BIOS
On Mon, Apr 08, 2013 at 01:18:10AM -0700, Jordan Justen wrote: On Sun, Apr 7, 2013 at 11:06 PM, Xiao Guangrong xiaoguangr...@linux.vnet.ibm.com wrote: On 03/23/2013 03:09 AM, Jordan Justen wrote: Admittedly, I've been completely ineffectual in resolving the kvm portion. More recently I tried to make use of KVM_MEM_READONLY to address this. I was able to get an VM exit on writes to flash, but not able to get the memory region to convert to full device mode so VM exits would occur on reads as well. I am once again stalled... Hi Jordan, What's memory region you want to get? I should admit that I do not have enough background of flash, could you please explain this requirement more detail? The flash memory requires two modes. Read/Execute mode: * Initial state * Writes will trap to QEMU, and may transition to Device mode based on QEMU device emulation Device mode: * Region is not executable * All reads writes will trap to QEMU * May transition back to Read/Execute mode based on QEMU device emulation Using KVM_MEM_READONLY I was able to get Read/Execute mode to work, but I was not able to get the memory region to transition to Device mode. (I couldn't get reads to trap to QEMU.) You need to drop memslot when you transition to Device mode. -- Gleb.
Re: [Qemu-devel] [PATCHv5 06/10] migration: search for zero instead of dup pages
Am 08.04.2013 um 10:33 hat Peter Lieven geschrieben: Am 05.04.2013 um 21:23 schrieb Kevin Wolf kw...@redhat.com: Am 26.03.2013 um 10:58 hat Peter Lieven geschrieben: virtually all dup pages are zero pages. remove the special is_dup_page() function and use the optimized buffer_find_nonzero_offset() function instead. here buffer_find_nonzero_offset() is used directly to avoid the unnecssary additional checks in buffer_is_zero(). raw performace gain checking 1 GByte zeroed memory over is_dup_page() is approx. 10-12% with SSE2 and 8-10% with unsigned long arithmedtic. Signed-off-by: Peter Lieven p...@kamp.de Reviewed-by: Orit Wasserman owass...@redhat.com Reviewed-by: Eric Blake ebl...@redhat.com Okay, so I bisected again and this is the second patch that is involved in the slowness of qemu-iotests case 007. Can you try if the following solves your issue: diff --git a/exec.c b/exec.c index 786987a..54baa4a 100644 --- a/exec.c +++ b/exec.c @@ -1071,6 +1071,7 @@ ram_addr_t qemu_ram_alloc_from_ptr(ram_addr_t size, void *host, memory_try_enable_merging(new_block-host, size); } } +qemu_madvise(new_block-host, size, QEMU_MADV_DONTNEED); new_block-length = size; /* Keep the list sorted from biggest to smallest block. */ It does. But perhaps Paolo's suggestion of using mmap() to allocate the memory would be better. I'm not sure how MADV_DONTNEED behaves on non-Linux. Kevin
Re: [Qemu-devel] [PATCHv5 06/10] migration: search for zero instead of dup pages
Am 08.04.2013 um 10:49 schrieb Kevin Wolf kw...@redhat.com: Am 08.04.2013 um 10:33 hat Peter Lieven geschrieben: Am 05.04.2013 um 21:23 schrieb Kevin Wolf kw...@redhat.com: Am 26.03.2013 um 10:58 hat Peter Lieven geschrieben: virtually all dup pages are zero pages. remove the special is_dup_page() function and use the optimized buffer_find_nonzero_offset() function instead. here buffer_find_nonzero_offset() is used directly to avoid the unnecssary additional checks in buffer_is_zero(). raw performace gain checking 1 GByte zeroed memory over is_dup_page() is approx. 10-12% with SSE2 and 8-10% with unsigned long arithmedtic. Signed-off-by: Peter Lieven p...@kamp.de Reviewed-by: Orit Wasserman owass...@redhat.com Reviewed-by: Eric Blake ebl...@redhat.com Okay, so I bisected again and this is the second patch that is involved in the slowness of qemu-iotests case 007. Can you try if the following solves your issue: diff --git a/exec.c b/exec.c index 786987a..54baa4a 100644 --- a/exec.c +++ b/exec.c @@ -1071,6 +1071,7 @@ ram_addr_t qemu_ram_alloc_from_ptr(ram_addr_t size, void *host, memory_try_enable_merging(new_block-host, size); } } +qemu_madvise(new_block-host, size, QEMU_MADV_DONTNEED); new_block-length = size; /* Keep the list sorted from biggest to smallest block. */ It does. But perhaps Paolo's suggestion of using mmap() to allocate the memory would be better. I'm not sure how MADV_DONTNEED behaves on non-Linux. its not guaranteed to zero memory. Peter Kevin
[Qemu-devel] 答复: 答复: 答复: 答复: question about performance of dataplane
-邮件原件- 发件人: Abel Gordon [mailto:ab...@il.ibm.com] 发送时间: 2013年4月8日 0:40 收件人: 张磊强 抄送: Luohao (brian); Haofeng; qemu-devel@nongnu.org; Stefan Hajnoczi; Stefan Hajnoczi; Zhangleiqiang 主题: Re: [Qemu-devel] 答复: 答复: 答复: question about performance of dataplane 张磊强 leiqzh...@gmail.com wrote on 07/04/2013 07:10:24 PM: HI, Abel Stefan: After thinking twice about the benchmarks and the idea of dataplane, I am still confused. Please note while I am familiar with the documentation and architecture of dataplane, I didn't contribute to the dataplane code. So Stefan is actually the right person to answer your questions. It's my understanding that the advantage of dataplane mainly includes two parts. The first is that splitting the IO thread from vcpu thread will avoid the global mutex competition, and the second is that the individual IO thread will not be blocked when vm exit occurs in vcpu thread. Am I right? As far as I understand you are right. But wait for Stefan's confirmation. OK, I will also wait for Stefan's confirmation, ：） These two advantages will always be effective whether the vcpus is more than host's cores or not. I would say that the advantage is effective as far as at least one vcpu thread executing guest I/O runs simultaneously with the back-end I/O thread (each thread on a different core). But why the advantage of dataplane is only so obvious when vcpus is more than host's cores? Maybe the issue is related to the fact that no-dataplane experiences more bottlenecks when your run more and more VCPU threads. So it not that dataplane performs better with more VCPUs, the issue is that no-dataplane performs worse with more VCPUs. I think maybe Anthony is right. In previous benchmarks, maybe the non-dataplane already reached the physical disk's IOPS upper limit. So I did another benchmark which ensures the vcpus is less than the host's cores, but also make continuous IO pressure by one VM when testing in the other VM. The result showed that dataplane did have some advantage over non-dataplane. 1. IO Pressure Mode: 8 worker, 16K IO size, 25% Read, 100% Random, and 50 outstanding IO 2. Benchmark Mode: 8 worker, 16K IO size, 0% Read, 100% Random, and 50 outstanding IO 2. Testing Results: a). IOPS: 178.324867 (non-dataplane) vs 230.956328 (dataplane) b). MBPS: 2.786326 (non-dataplane) vs 3.608693 (dataplane) -- Leiqzhang Best Regards
Re: [Qemu-devel] Use of flash for x86 BIOS
On 04/08/2013 04:43 PM, Gleb Natapov wrote: On Mon, Apr 08, 2013 at 01:18:10AM -0700, Jordan Justen wrote: On Sun, Apr 7, 2013 at 11:06 PM, Xiao Guangrong xiaoguangr...@linux.vnet.ibm.com wrote: On 03/23/2013 03:09 AM, Jordan Justen wrote: Admittedly, I've been completely ineffectual in resolving the kvm portion. More recently I tried to make use of KVM_MEM_READONLY to address this. I was able to get an VM exit on writes to flash, but not able to get the memory region to convert to full device mode so VM exits would occur on reads as well. I am once again stalled... Hi Jordan, What's memory region you want to get? I should admit that I do not have enough background of flash, could you please explain this requirement more detail? The flash memory requires two modes. Read/Execute mode: * Initial state * Writes will trap to QEMU, and may transition to Device mode based on QEMU device emulation Device mode: * Region is not executable * All reads writes will trap to QEMU * May transition back to Read/Execute mode based on QEMU device emulation Using KVM_MEM_READONLY I was able to get Read/Execute mode to work, but I was not able to get the memory region to transition to Device mode. (I couldn't get reads to trap to QEMU.) You need to drop memslot when you transition to Device mode. Yes. After delete the memslot, you can intercept both write and read. ;)
Re: [Qemu-devel] [PATCH][RFC v2 2/7] hw/power: add main power chip implementation
On 8 April 2013 01:32, li guang lig.f...@cn.fujitsu.com wrote: 在 2013-04-05五的 10:23 +0100，Peter Maydell写道： QEMU is fundamentally modelling real hardware platforms, not abstract devices. You have to model a real power controller to at least some extent, because that's what guest OSes expect to be interacting with, and what device and board hardware models expect to be dealing with. Hmm, let me see ... but you know, in my mind OS mostly dose not care more about power controller, for example, if OS want to reset, it just issues a command or writes a special value to register in a chip(not power controller), like PC, one of reset path is to issue a KBC reset command to IO register 0x64. so it seems OS has no idea about power controller(chip), This is architecture specific, which is my point. You can provide generic mechanisms for making it easier to implement power control, but you have to be clear about what is generic (and optional) mechanism and what is board and hardware specific. -- PMM
Re: [Qemu-devel] [PATCHv5 06/10] migration: search for zero instead of dup pages
Am 08.04.2013 um 10:38 schrieb Paolo Bonzini pbonz...@redhat.com:
Il 06/04/2013 00:06, Peter Lieven ha scritto:
I think we should MADV_DONTNEED it.
i have to correct myself, on Linux it seems that MADV_DONTNEED guarantees
that
subsequent reads will return a zero filled page.
If I am right with that we could MADV_DONTNEED the memory on startup and keep
not sending zero pages in bulk stage if we are running under Linux. Am I
right with that?
Actually we can use mmap+munmap to allocate a well-aligned, always zero
block for the RAM.
like this?
diff --git a/exec.c b/exec.c
index 786987a..dfd1ad3 100644
--- a/exec.c
+++ b/exec.c
@@ -1048,27 +1048,31 @@ ram_addr_t qemu_ram_alloc_from_ptr(ram_addr_t size,
void *host,
new_block-host = host;
new_block-flags |= RAM_PREALLOC_MASK;
} else {
-if (mem_path) {
+if (xen_enabled()) {
+xen_ram_alloc(new_block-offset, size, mr);
+memory_try_enable_merging(new_block-host, size);
+} else {
+if (mem_path) {
#if defined (__linux__) !defined(TARGET_S390X)
-new_block-host = file_ram_alloc(new_block, size, mem_path);
-if (!new_block-host) {
-new_block-host = qemu_vmalloc(size);
-memory_try_enable_merging(new_block-host, size);
-}
+new_block-host = file_ram_alloc(new_block, size, mem_path);
#else
-fprintf(stderr, -mem-path option unsupported\n);
-exit(1);
+fprintf(stderr, -mem-path option unsupported\n);
+exit(1);
#endif
-} else {
-if (xen_enabled()) {
-xen_ram_alloc(new_block-offset, size, mr);
-} else if (kvm_enabled()) {
+}
+if (!new_block-host kvm_enabled()) {
/* some s390/kvm configurations have special constraints */
new_block-host = kvm_vmalloc(size);
-} else {
-new_block-host = qemu_vmalloc(size);
}
-memory_try_enable_merging(new_block-host, size);
+if (!new_block-host) {
+new_block-host = mmap(0, size, PROT_READ | PROT_WRITE,
+ MAP_ANONYMOUS | MAP_PRIVATE, -1, 0);
+if (new_block-host == MAP_FAILED) {
+fprintf(stderr,qemu_ram_alloc: can't mmap RAM pages
%d\n,errno);
+exit(1);
+}
+memory_try_enable_merging(new_block-host, size);
+}
}
}
new_block-length = size;
@@ -1142,25 +1146,19 @@ void qemu_ram_free(ram_addr_t addr)
;
} else if (mem_path) {
#if defined (__linux__) !defined(TARGET_S390X)
+munmap(block-host, block-length);
if (block-fd) {
-munmap(block-host, block-length);
close(block-fd);
-} else {
-qemu_vfree(block-host);
}
#else
abort();
#endif
} else {
-#if defined(TARGET_S390X) defined(CONFIG_KVM)
-munmap(block-host, block-length);
-#else
if (xen_enabled()) {
xen_invalidate_map_cache_entry(block-host);
} else {
-qemu_vfree(block-host);
+munmap(block-host, block-length);
}
-#endif
}
g_free(block);
break;
diff --git a/kvm-all.c b/kvm-all.c
index 9b433d3..90be8e3 100644
--- a/kvm-all.c
+++ b/kvm-all.c
@@ -1742,7 +1742,7 @@ void *kvm_vmalloc(ram_addr_t size)
return mem;
}
#endif
-return qemu_vmalloc(size);
+return NULL;
}
void kvm_setup_guest_memory(void *start, size_t size)
Re: [Qemu-devel] [PATCH][RFC v2 3/7] vl: create power chip device
Il 08/04/2013 02:18, li guang ha scritto: In short, the purpose is to implement a power control process just like real world(hardware platform), a power chip(controller) connect power signals to other devices, and devices can do power (on, off, ...) controlled by power chip(controller). Is this reasonable? It may be reasonable, but it will be board-dependent. The meaning of power on/power off varies wildly depending on the kind of device, the platform, etc. Similarly, reset is very different from a power cycle. Are you trying to implement D-states? Paolo
Re: [Qemu-devel] [PATCH V11 11/17] qmp: add ImageInfo in BlockDeviceInfo used by query-block
Am 02.04.2013 um 13:47 hat Wenchao Xia geschrieben:
Now image info will be retrieved as an embbed json object inside
BlockDeviceInfo, backing chain info and all related internal snapshot
info can be got in the enhanced recursive structure of ImageInfo.
Signed-off-by: Wenchao Xia xiaw...@linux.vnet.ibm.com
---
block/qapi.c | 38 ++--
include/block/qapi.h |4 ++-
qapi-schema.json |5 +++-
qmp-commands.hx | 67
+-
4 files changed, 108 insertions(+), 6 deletions(-)
diff --git a/block/qapi.c b/block/qapi.c
index fa61c85..e98a028 100644
--- a/block/qapi.c
+++ b/block/qapi.c
@@ -202,9 +202,14 @@ int bdrv_query_image_info(BlockDriverState *bs,
return 0;
}
-BlockInfo *bdrv_query_info(BlockDriverState *bs)
+/* @p_info will be set only on success. */
+void bdrv_query_info(BlockDriverState *bs,
+ BlockInfo **p_info,
+ Error **errp)
{
BlockInfo *info = g_malloc0(sizeof(*info));
+BlockDriverState *bs0;
+ImageInfo **p_image_info;
info-device = g_strdup(bs-device_name);
info-type = g_strdup(unknown);
info-locked = bdrv_dev_is_medium_locked(bs);
@@ -258,8 +263,28 @@ BlockInfo *bdrv_query_info(BlockDriverState *bs)
info-inserted-iops_wr =
bs-io_limits.iops[BLOCK_IO_LIMIT_WRITE];
}
+
+bs0 = bs;
+p_image_info = info-inserted-image;
+while (1) {
+if (bdrv_query_image_info(bs0, p_image_info, errp)) {
+goto err;
+}
+if (bs0-drv bs0-backing_hd) {
+bs0 = bs0-backing_hd;
+(*p_image_info)-has_backing_image = true;
+p_image_info = ((*p_image_info)-backing_image);
+} else {
+break;
+}
+}
}
-return info;
+
+*p_info = info;
+return;
+
+ err:
+qapi_free_BlockInfo(info);
}
SnapshotInfoList *qmp_query_snapshots(Error **errp)
@@ -286,11 +311,18 @@ BlockInfoList *qmp_query_block(Error **errp)
while ((bs = bdrv_next(bs))) {
BlockInfoList *info = g_malloc0(sizeof(*info));
-info-value = bdrv_query_info(bs);
+bdrv_query_info(bs, info-value, errp);
+if (error_is_set(errp)) {
+goto err;
+}
This doesn't do what you think it does: The caller can pass NULL as
errp, and then this becomes never true. I think you need to use a
local_err and propagate it to errp in error cases.
*p_next = info;
p_next = info-next;
}
return head;
+
+ err:
+qapi_free_BlockInfoList(head);
+return NULL;
}
Kevin
[Qemu-devel] [PATCH] qdev: don't ref parent bus
Since bus refs its children, it introduces reference cycle when qdev
refs its parent bus.
Signed-off-by: Hu Tao hu...@cn.fujitsu.com
---
hw/qdev.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/hw/qdev.c b/hw/qdev.c
index e2bb37d..c84bffb 100644
--- a/hw/qdev.c
+++ b/hw/qdev.c
@@ -103,7 +103,6 @@ static void bus_add_child(BusState *bus, DeviceState *child)
void qdev_set_parent_bus(DeviceState *dev, BusState *bus)
{
dev-parent_bus = bus;
-object_ref(OBJECT(bus));
bus_add_child(bus, dev);
}
@@ -783,7 +782,6 @@ static void device_unparent(Object *obj)
}
if (dev-parent_bus) {
bus_remove_child(dev-parent_bus, dev);
-object_unref(OBJECT(dev-parent_bus));
dev-parent_bus = NULL;
}
--
1.8.1.4
Re: [Qemu-devel] [PATCH V11 00/17] qmp/hmp interfaces for internal snapshot info
Am 02.04.2013 um 13:47 hat Wenchao Xia geschrieben: v11: General change: 5/17: check if snapshot 0 on success in caller, add comments on the function says that caller need to check it on success. 7/17: check if snapshot 0 on success before set info-has_snapshots. Address Eric's comments: 5/17: use error_setg_errno instead of strerror(). 12/17: also move bdrv_snapshot_dump() since it need to be changed using GString later. 13/17: using GString as buffer. 14/17: using GString to dump snapshot info. 16/17: using GString to dump image info. Address Kevin's comments: 11/17: return void for bdrv_query_info(). 17/17: spell fix in help message, using parameter -v to show verbose info. In patch 11 I commented on what I think is an error handling bug. The rest of the series is: Reviewed-by: Kevin Wolf kw...@redhat.com
Re: [Qemu-devel] [PATCHv5 06/10] migration: search for zero instead of dup pages
Il 08/04/2013 11:25, Peter Lieven ha scritto: Actually we can use mmap+munmap to allocate a well-aligned, always zero block for the RAM. like this? This doesn't align it. I'll send a patch shortly. Paolo
Re: [Qemu-devel] Virtualbox svga card in KVM
On Fri, Apr 05, 2013 at 04:52:05PM -0700, Sriram Murthy wrote: For starters, virtual box has better SVGA WDDM drivers that allows for a much richer display when the VM display is local. What does much richer display mean? Stefan
[Qemu-devel] [PATCH] migration: initialize RAM to zero
Using qemu_memalign only leaves the RAM zero by chance, because libc
will usually use mmap to satisfy our huge requests. But memory will
not be zero when using MALLOC_PERTURB_ with a nonzero value. In the
case of incoming migration, this breaks a recently-introduced
invariant (commit f1c7279, migration: do not sent zero pages in
bulk stage, 2013-03-26).
To fix this, use mmap ourselves to get a well-aligned, always zero
block for the RAM. Mmap-ed memory is easy to trim at the sides.
This also removes the need to do something special on valgrind
(see commit c2a8238a, Support running QEMU on Valgrind, 2011-10-31).
Signed-off-by: Paolo Bonzini pbonz...@redhat.com
---
util/oslib-posix.c | 30 +-
1 file changed, 13 insertions(+), 17 deletions(-)
diff --git a/util/oslib-posix.c b/util/oslib-posix.c
index 433dd68..91f5aab 100644
--- a/util/oslib-posix.c
+++ b/util/oslib-posix.c
@@ -52,12 +52,8 @@ extern int daemon(int, int);
#include sysemu/sysemu.h
#include trace.h
#include qemu/sockets.h
+#include sys/mman.h
-#if defined(CONFIG_VALGRIND)
-static int running_on_valgrind = -1;
-#else
-# define running_on_valgrind 0
-#endif
#ifdef CONFIG_LINUX
#include sys/syscall.h
#endif
@@ -108,22 +104,22 @@ void *qemu_memalign(size_t alignment, size_t size)
/* alloc shared memory pages */
void *qemu_vmalloc(size_t size)
{
-void *ptr;
size_t align = QEMU_VMALLOC_ALIGN;
+size_t total = size + align - getpagesize();
+void *ptr = mmap(0, total, PROT_READ | PROT_WRITE,
+ MAP_ANONYMOUS | MAP_PRIVATE, -1, 0);
+size_t offset = QEMU_ALIGN_UP((uintptr_t)ptr, align) - (uintptr_t)ptr;
-#if defined(CONFIG_VALGRIND)
-if (running_on_valgrind 0) {
-/* First call, test whether we are running on Valgrind.
- This is a substitute for RUNNING_ON_VALGRIND from valgrind.h. */
-const char *ld = getenv(LD_PRELOAD);
-running_on_valgrind = (ld != NULL strstr(ld, vgpreload));
-}
-#endif
+ptr += offset;
+total -= offset;
-if (size align || running_on_valgrind) {
-align = getpagesize();
+if (offset 0) {
+munmap(ptr - offset, offset);
+}
+if (total size) {
+munmap(ptr + size, total - size);
}
-ptr = qemu_memalign(align, size);
+
trace_qemu_vmalloc(size, ptr);
return ptr;
}
--
1.8.1.4
Re: [Qemu-devel] 答复: qemu crashed when starting vm(kvm) with vnc connect
On Sun, Apr 07, 2013 at 04:58:07AM +, Zhanghaoyu (A) wrote: I start a kvm VM with vnc(using the zrle protocol) connect, sometimes qemu program crashed during starting period, received signal SIGABRT. Trying about 20 times, this crash may be reproduced. I guess the cause memory corruption or double free. Which version of QEMU are you running? Please try qemu.git/master. Stefan I used the QEMU download from qemu.git (http://git.qemu.org/git/qemu.git). Great, thanks! Can you please post a backtrace? The easiest way is: $ ulimit -c unlimited $ qemu-system-x86_64 -enable-kvm -m 1024 ... ...crash... $ gdb -c qemu-system-x86_64.core (gdb) bt Depending on how your system is configured the core file might have a different filename but there should be a file name *core* the current working directory after the crash. The backtrace will make it possible to find out where the crash occurred. Thanks, Stefan
Re: [Qemu-devel] [PATCH v2 2/2] configure: Don't fall back to gthread coroutine backend
On Thu, Mar 14, 2013 at 05:57:10PM +, Peter Maydell wrote: -block-obj-$(CONFIG_WIN32) += coroutine-win32.o win32 +block-obj-y += coroutine-$(CONFIG_COROUTINE_BACKEND).o ...backend name expanded into object file name... +if test $coroutine = ; then + if test $mingw32 = yes; then +coroutine=windows windows Please change windows to win32 so the Windows build works. Stefan
Re: [Qemu-devel] 答复: 答复: 答复: 答复: question about performance of dataplane
Zhangleiqiang zhangleiqi...@huawei.com wrote on 08/04/2013 12:06:17 PM: I think maybe Anthony is right. In previous benchmarks, maybe the non-dataplane already reached the physical disk's IOPS upper limit. Yep, agree. Try to run the same benchmark in the host to see what is the bare-metal performance of your system (upper limit) and how far are dataplane and non-dataplane from this value. Note your are currently focusing on throughput but you should also consider latency and CPU utilization. So I did another benchmark which ensures the vcpus is less than the host's cores, but also make continuous IO pressure by one VM when testing in the other VM. The result showed that dataplane did have some advantage over non-dataplane. 1. IO Pressure Mode: 8 worker, 16K IO size, 25% Read, 100% Random, and 50 outstanding IO 2. Benchmark Mode: 8 worker, 16K IO size, 0% Read, 100% Random, and 50 outstanding IO 2. Testing Results: a). IOPS: 178.324867 (non-dataplane) vs 230.956328 (dataplane) b). MBPS: 2.786326 (non-dataplane) vs 3.608693 (dataplane) Note that running other VM just to synthetically degrade the performance of the system may cause some side effects and confuse the results (e.g. the other VM may stress the system differently and do more pressure when you use dataplane than when you don't use dataplane) Last thing, IMHO, you should also evaluate scalability: how dataplane and no-dataplane perform when you run multiple VMs ? For example, first 1 VM with 2 VCPUs then 2 VMs with 2 VCPUs each then 3 VMs with 2 VCPUs each ... up to 12 VMs with 2 VCPUs each It seems like you unintentionally tested what happens with 2 VMs when you added the other VM to create I/O pressure.
Re: [Qemu-devel] question about performance of dataplane
On Sun, Apr 07, 2013 at 09:05:47AM -0500, Anthony Liguori wrote: Zhangleiqiang zhangleiqi...@huawei.com writes: Hi, Stefan： I have done some testing to compare the performance of dataplane and non-dataplane. But the result did not meet my expectations, the performance of disk with dataplane enabled did not have advantage over non-dataplane. The following contains the environment info and testing results. Does my testing method or testing environment have something wrong ? Could you give me some advice? I can provide more information if need. 1. Environment: a). Qemu 1.4 master branch b). kernel: 3.5.0-2.fc17.x86_64 c). virtual disks location: the same local SATA harddisk with ext4 fs I doubt you'll see any performance difference with a single SATA drive. There's no real parallelism possible as you have exactly one spindle available. Sorry for the delay, catching up on emails after my Easter vacation. I agree with Anthony here. It seems your benchmark configuration is bottlenecked below the point where data plane makes a difference. Stefan
[Qemu-devel] [PATCH v3 0/2] configure: fix coroutine backend selection logic
The main aim of this patchset is patch 2, which changes the coroutine backend selection logic so that it goes 'ucontext - sigaltstack' rather than 'ucontext - gthread', since the gthread backend is broken. To do this properly on all platforms we have to refactor the code a bit (which it needed anyway). The first patch here is a generic configure cleanup to how we print error messages, which I wanted for the third patch because otherwise the various error paths would have been rather verbose. Changes v2-v3: * canonicalize user-facing 'windows' backend name to 'win32' so we pick up the right filename for windows builds Changes v1-v2: * fix the tests makefile too * CONFIG_COROUTINE_BACKEND=foo rather than CONFIG_FOO_COROUTINE=y; this simplifies both the configure code and the makefiles * dropped the 'move upper()' patch as no longer needed (in this series, anyway) Peter Maydell (2): configure: Provide and use convenience error reporting function configure: Don't fall back to gthread coroutine backend Makefile.objs | 11 +-- configure | 260 ++-- tests/Makefile | 14 +-- 3 files changed, 122 insertions(+), 163 deletions(-) -- 1.7.9.5
[Qemu-devel] [PATCH v3 2/2] configure: Don't fall back to gthread coroutine backend
The gthread coroutine backend is broken and does not produce a working
QEMU; it is only useful for some very limited debugging situations.
Clean up the backend selection logic in configure so that it now runs
if on windows use windows; else prefer ucontext; else sigaltstack.
To do this we refactor the configure code to separate out test
whether we have a working ucontext, pick a default if user didn't
specify and validate that user didn't specify something invalid,
rather than having all three of these run together. We also simplify
the Makefile logic so it just links in the backend the configure
script selects.
Signed-off-by: Peter Maydell peter.mayd...@linaro.org
---
Makefile.objs | 11 +
configure | 69 +---
tests/Makefile | 14 +---
3 files changed, 48 insertions(+), 46 deletions(-)
diff --git a/Makefile.objs b/Makefile.objs
index f99841c..e568c01 100644
--- a/Makefile.objs
+++ b/Makefile.objs
@@ -16,16 +16,7 @@ block-obj-y += qapi-types.o qapi-visit.o
block-obj-y += qemu-coroutine.o qemu-coroutine-lock.o qemu-coroutine-io.o
block-obj-y += qemu-coroutine-sleep.o
-ifeq ($(CONFIG_UCONTEXT_COROUTINE),y)
-block-obj-$(CONFIG_POSIX) += coroutine-ucontext.o
-else
-ifeq ($(CONFIG_SIGALTSTACK_COROUTINE),y)
-block-obj-$(CONFIG_POSIX) += coroutine-sigaltstack.o
-else
-block-obj-$(CONFIG_POSIX) += coroutine-gthread.o
-endif
-endif
-block-obj-$(CONFIG_WIN32) += coroutine-win32.o
+block-obj-y += coroutine-$(CONFIG_COROUTINE_BACKEND).o
ifeq ($(CONFIG_VIRTIO)$(CONFIG_VIRTFS)$(CONFIG_PCI),yyy)
# Lots of the fsdev/9pcode is pulled in by vl.c via qemu_fsdev_add.
diff --git a/configure b/configure
index a097fde..3738de4 100755
--- a/configure
+++ b/configure
@@ -3071,31 +3071,58 @@ fi
##
# check and set a backend for coroutine
-# default is ucontext, but always fallback to gthread
-# windows autodetected by make
-if test $coroutine = -o $coroutine = ucontext; then
- if test $darwin != yes; then
-cat $TMPC EOF
+# We prefer ucontext, but it's not always possible. The fallback
+# is sigcontext. gthread is not selectable except explicitly, because
+# it is not functional enough to run QEMU proper. (It is occasionally
+# useful for debugging purposes.) On Windows the only valid backend
+# is the Windows-specific one.
+
+ucontext_works=no
+if test $darwin != yes; then
+ cat $TMPC EOF
#include ucontext.h
#ifdef __stub_makecontext
#error Ignoring glibc stub makecontext which will always fail
#endif
int main(void) { makecontext(0, 0, 0); return 0; }
EOF
-if compile_prog ; then
-coroutine_backend=ucontext
-else
- coroutine_backend=gthread
-fi
+ if compile_prog ; then
+ucontext_works=yes
+ fi
+fi
+
+if test $coroutine = ; then
+ if test $mingw32 = yes; then
+coroutine=win32
+ elif test $ucontext_works = yes; then
+coroutine=ucontext
+ else
+coroutine=sigaltstack
fi
-elif test $coroutine = gthread ; then
- coroutine_backend=gthread
-elif test $coroutine = windows ; then
- coroutine_backend=windows
-elif test $coroutine = sigaltstack ; then
- coroutine_backend=sigaltstack
else
- error_exit unknown coroutine backend $coroutine
+ case $coroutine in
+ windows)
+if test $mingw32 != yes; then
+ error_exit 'windows' coroutine backend only valid for Windows
+fi
+# Unfortunately the user visible backend name doesn't match the
+# coroutine-*.c filename for this case, so we have to adjust it here.
+coroutine=win32
+;;
+ ucontext)
+if test $ucontext_works != yes; then
+ feature_not_found ucontext
+fi
+;;
+ gthread|sigaltstack)
+if test $mingw32 = yes; then
+ error_exit only the 'windows' coroutine backend is valid for Windows
+fi
+;;
+ *)
+error_exit unknown coroutine backend $coroutine
+;;
+ esac
fi
##
@@ -3402,7 +3429,7 @@ echo GLX support $glx
echo libiscsi support $libiscsi
echo build guest agent $guest_agent
echo seccomp support $seccomp
-echo coroutine backend $coroutine_backend
+echo coroutine backend $coroutine
echo GlusterFS support $glusterfs
echo virtio-blk-data-plane $virtio_blk_data_plane
echo gcov $gcov_tool
@@ -3735,11 +3762,7 @@ if test $rbd = yes ; then
echo CONFIG_RBD=y $config_host_mak
fi
-if test $coroutine_backend = ucontext ; then
- echo CONFIG_UCONTEXT_COROUTINE=y $config_host_mak
-elif test $coroutine_backend = sigaltstack ; then
- echo CONFIG_SIGALTSTACK_COROUTINE=y $config_host_mak
-fi
+echo CONFIG_COROUTINE_BACKEND=$coroutine $config_host_mak
if test $open_by_handle_at = yes ; then
echo CONFIG_OPEN_BY_HANDLE=y $config_host_mak
diff --git a/tests/Makefile b/tests/Makefile
index 567e36e..7fa15c6 100644
--- a/tests/Makefile
+++ b/tests/Makefile
@@ -24,19 +24,7 @@ gcov-files-test-string-input-visitor-y =
qapi/string-input-visitor.c
check-unit-y
[Qemu-devel] [PATCH v3 1/2] configure: Provide and use convenience error reporting function
Provide a convenience function for reporting an error and exiting,
and update various places in the configure script to use it.
This allows us to be a little more consistent about how format
our error messages and makes the calling code shorter.
Signed-off-by: Peter Maydell peter.mayd...@linaro.org
Reviewed-by: Paolo Bonzini pbonz...@redhat.com
---
configure | 193 -
1 file changed, 75 insertions(+), 118 deletions(-)
diff --git a/configure b/configure
index d685275..a097fde 100755
--- a/configure
+++ b/configure
@@ -27,6 +27,17 @@ printf '%s' $0 $@ config.log
echo config.log
echo # config.log
+error_exit() {
+echo
+echo ERROR: $1
+while test -n $2; do
+echo$2
+shift
+done
+echo
+exit 1
+}
+
do_cc() {
# Run the compiler, capturing its output to the log.
echo $cc $@ config.log
@@ -46,11 +57,10 @@ do_cc() {
esac
echo $cc -Werror $@ config.log
$cc -Werror $@ config.log 21 return $?
-echo ERROR: configure test passed without -Werror but failed with
-Werror.
-echo This is probably a bug in the configure script. The failing command
-echo will be at the bottom of config.log.
-echo You can run configure with --disable-werror to bypass this check.
-exit 1
+error_exit configure test passed without -Werror but failed with
-Werror. \
+This is probably a bug in the configure script. The failing command \
+will be at the bottom of config.log. \
+You can run configure with --disable-werror to bypass this check.
}
compile_object() {
@@ -494,11 +504,10 @@ SunOS)
LDFLAGS=-L/opt/SUNWspro/prod/lib -R/opt/SUNWspro/prod/lib $LDFLAGS
LIBS=-lsunmath $LIBS
else
-echo QEMU will not link correctly on Solaris 8/X86 or 9/x86 without
-echo libsunmath from the Sun Studio compilers tools, due to a lack of
-echo C99 math features in libm.so in Solaris 8/x86 and Solaris 9/x86
-echo Studio 11 can be downloaded from www.sun.com.
-exit 1
+error_exit QEMU will not link correctly on Solaris 8/X86 or 9/x86
without \
+libsunmath from the Sun Studio compilers tools, due to a lack of
\
+C99 math features in libm.so in Solaris 8/x86 and Solaris 9/x86 \
+Studio 11 can be downloaded from www.sun.com.
fi
fi
fi
@@ -1185,8 +1194,7 @@ if test $ARCH = unknown; then
echo Unsupported CPU = $cpu, will use TCG with TCI (experimental)
ARCH=tci
else
-echo Unsupported CPU = $cpu, try --enable-tcg-interpreter
-exit 1
+error_exit Unsupported CPU = $cpu, try --enable-tcg-interpreter
fi
fi
@@ -1198,8 +1206,7 @@ EOF
if compile_object ; then
: C compiler works ok
else
-echo ERROR: \$cc\ either does not exist or does not work
-exit 1
+error_exit \$cc\ either does not exist or does not work
fi
# Consult white-list to determine whether to enable werror
@@ -1254,8 +1261,7 @@ fi
if test $static = yes ; then
if test $pie = yes ; then
-echo static and pie are mutually incompatible
-exit 1
+error_exit static and pie are mutually incompatible
else
pie=no
fi
@@ -1294,8 +1300,7 @@ EOF
fi
else
if test $pie = yes; then
- echo PIE not available due to missing toolchain support
- exit 1
+ error_exit PIE not available due to missing toolchain support
else
echo Disabling PIE due to missing toolchain support
pie=no
@@ -1310,40 +1315,36 @@ if test $solaris = yes ; then
if has $install; then
:
else
-echo Solaris install program not found. Use --install=/usr/ucb/install or
-echo install fileutils from www.blastwave.org using pkg-get -i fileutils
-echo to get ginstall which is used by default (which lives in
/opt/csw/bin)
-exit 1
+error_exit Solaris install program not found. Use
--install=/usr/ucb/install or \
+install fileutils from www.blastwave.org using pkg-get -i fileutils \
+to get ginstall which is used by default (which lives in
/opt/csw/bin)
fi
if test `path_of $install` = /usr/sbin/install ; then
-echo Error: Solaris /usr/sbin/install is not an appropriate install
program.
-echo try ginstall from the GNU fileutils available from www.blastwave.org
-echo using pkg-get -i fileutils, or use --install=/usr/ucb/install
-exit 1
+error_exit Solaris /usr/sbin/install is not an appropriate install
program. \
+try ginstall from the GNU fileutils available from www.blastwave.org
\
+using pkg-get -i fileutils, or use --install=/usr/ucb/install
fi
if has ar; then
:
else
-echo Error: No path includes ar
if test -f /usr/ccs/bin/ar ; then
- echo Add /usr/ccs/bin to your path and rerun configure
+ error_exit No path includes ar \
+ Add /usr/ccs/bin to your path and rerun configure
fi
-
Re: [Qemu-devel] [PATCH] Document mcast+ipv6 (Was: Re: socket, mcast looping back frames - IPv6 broken)
On Mon, Apr 01, 2013 at 02:12:51AM +0200, Samuel Thibault wrote: Stefan Hajnoczi, le Mon 11 Mar 2013 09:36:14 +0100, a écrit : Otherwise we may just document that one has to disable Duplicate Address Detection to get IPv6 working :/ Seems like this might be the only way for now. Here is a patch Let's check out the 2 socket patch first. If that doesn't work out I'll merge the documentation warning. Stefan
Re: [Qemu-devel] 答复: 答复: 答复: 答复: question about performance of dataplane
-Original Message- From: Abel Gordon [mailto:ab...@il.ibm.com] Sent: Monday, April 08, 2013 7:04 PM To: Zhangleiqiang Cc: anth...@codemonkey.ws; Luohao (brian); Haofeng; 张磊强; qemu-devel@nongnu.org; Stefan Hajnoczi; Stefan Hajnoczi Subject: Re: 答复: [Qemu-devel] 答复: 答复: 答复: question about performance of dataplane Zhangleiqiang zhangleiqi...@huawei.com wrote on 08/04/2013 12:06:17 PM: I think maybe Anthony is right. In previous benchmarks, maybe the non-dataplane already reached the physical disk's IOPS upper limit. Yep, agree. Try to run the same benchmark in the host to see what is the bare-metal performance of your system (upper limit) and how far are dataplane and non-dataplane from this value. Note your are currently focusing on throughput but you should also consider latency and CPU utilization. So I did another benchmark which ensures the vcpus is less than the host's cores, but also make continuous IO pressure by one VM when testing in the other VM. The result showed that dataplane did have some advantage over non-dataplane. 1. IO Pressure Mode: 8 worker, 16K IO size, 25% Read, 100% Random, and 50 outstanding IO 2. Benchmark Mode: 8 worker, 16K IO size, 0% Read, 100% Random, and 50 outstanding IO 2. Testing Results: a). IOPS: 178.324867 (non-dataplane) vs 230.956328 (dataplane) b). MBPS: 2.786326 (non-dataplane) vs 3.608693 (dataplane) Note that running other VM just to synthetically degrade the performance of the system may cause some side effects and confuse the results (e.g. the other VM may stress the system differently and do more pressure when you use dataplane than when you don't use dataplane) I think do multiple benchmarks with the same situation and calc the average value will eliminate the side effects. Last thing, IMHO, you should also evaluate scalability: how dataplane and no-dataplane perform when you run multiple VMs ? For example, first 1 VM with 2 VCPUs then 2 VMs with 2 VCPUs each then 3 VMs with 2 VCPUs each ... up to 12 VMs with 2 VCPUs each It seems like you unintentionally tested what happens with 2 VMs when you added the other VM to create I/O pressure. Indeed, the fact I used 2 VMs in previous benchmark is to ensure the vcpus is less than the host's cores, eg, each vm had 8 vpus. Thanks for your advice, I will evaluate the scalability, :)
Re: [Qemu-devel] [PER] Re: socket, mcast looping back frames - IPv6 broken
On Mon, Apr 01, 2013 at 11:32:29AM +0200, Samuel Thibault wrote: Mike Lovell, le Mon 01 Apr 2013 00:35:03 -0600, a écrit : On 03/08/2013 05:47 AM, Samuel Thibault wrote: Samuel Thibault, le Fri 08 Mar 2013 10:08:55 +0100, a écrit : There does exist some unique address, which is returned by recvfrom, I'll have a look at how to get access to it. Ah, no, it's not unique... It's just the host IP address and the same port as the multicast address, so it'll be the same for all qemus on the same host. I've checked how Linux bounces the datagram, it's through the loopback interface, and thus dispatched over all listeners without distinction. I don't see any way to get the information that the packet comes from us, except using the ethernet content. one solution is to actually use two sockets. one that is bound to the multicast address, which receives the multicast packets, and another that is just bound to any ephemeral udp port, which is used for sending packets. Mmm, that should work indeed. if the group is interested is a solution like this, i can probably make some time over the next couple days to cook up a patch. thoughts? Yes, please. Yeah, great. It's a real problem that people are hitting so it would be worth fixing. Stefan
[Qemu-devel] [PATCH 1/4] migration: set f-is_write and flush in add_to_iovec
Signed-off-by: Paolo Bonzini pbonz...@redhat.com
---
savevm.c | 25 +
1 file changed, 9 insertions(+), 16 deletions(-)
diff --git a/savevm.c b/savevm.c
index b1d8988..c952c41 100644
--- a/savevm.c
+++ b/savevm.c
@@ -631,6 +631,11 @@ static void add_to_iovec(QEMUFile *f, const uint8_t *buf,
int size)
f-iov[f-iovcnt].iov_base = (uint8_t *)buf;
f-iov[f-iovcnt++].iov_len = size;
}
+
+f-is_write = 1;
+if (f-buf_index = IO_BUF_SIZE || f-iovcnt = MAX_IOV_SIZE) {
+qemu_fflush(f);
+}
}
void qemu_put_buffer_async(QEMUFile *f, const uint8_t *buf, int size)
@@ -645,14 +650,8 @@ void qemu_put_buffer_async(QEMUFile *f, const uint8_t
*buf, int size)
abort();
}
-add_to_iovec(f, buf, size);
-
-f-is_write = 1;
f-bytes_xfer += size;
-
-if (f-buf_index = IO_BUF_SIZE || f-iovcnt = MAX_IOV_SIZE) {
-qemu_fflush(f);
-}
+add_to_iovec(f, buf, size);
}
void qemu_put_buffer(QEMUFile *f, const uint8_t *buf, int size)
@@ -674,7 +673,6 @@ void qemu_put_buffer(QEMUFile *f, const uint8_t *buf, int
size)
if (l size)
l = size;
memcpy(f-buf + f-buf_index, buf, l);
-f-is_write = 1;
f-buf_index += l;
qemu_put_buffer_async(f, f-buf + (f-buf_index - l), l);
if (qemu_file_get_error(f)) {
@@ -697,15 +695,10 @@ void qemu_put_byte(QEMUFile *f, int v)
abort();
}
-f-buf[f-buf_index++] = v;
-f-is_write = 1;
+f-buf[f-buf_index] = v;
f-bytes_xfer++;
-
-add_to_iovec(f, f-buf + (f-buf_index - 1), 1);
-
-if (f-buf_index = IO_BUF_SIZE || f-iovcnt = MAX_IOV_SIZE) {
-qemu_fflush(f);
-}
+add_to_iovec(f, f-buf + f-buf_index, 1);
+f-buf_index++;
}
static void qemu_file_skip(QEMUFile *f, int size)
--
1.8.2
[Qemu-devel] [PATCH 3/4] migration: drop is_write complications
The same QEMUFile is never used for both read and write. Simplify
the logic to simply look for presence or absence of the right ops.
Signed-off-by: Paolo Bonzini pbonz...@redhat.com
---
savevm.c | 68 +++-
1 file changed, 20 insertions(+), 48 deletions(-)
diff --git a/savevm.c b/savevm.c
index b32e0a7..a2f6bc0 100644
--- a/savevm.c
+++ b/savevm.c
@@ -119,7 +119,6 @@ void qemu_announce_self(void)
struct QEMUFile {
const QEMUFileOps *ops;
void *opaque;
-int is_write;
int64_t bytes_xfer;
int64_t xfer_limit;
@@ -500,7 +499,6 @@ QEMUFile *qemu_fopen_ops(void *opaque, const QEMUFileOps
*ops)
f-opaque = opaque;
f-ops = ops;
-f-is_write = 0;
return f;
}
@@ -516,6 +514,11 @@ static void qemu_file_set_error(QEMUFile *f, int ret)
}
}
+static inline bool qemu_file_is_writable(QEMUFile *f)
+{
+return f-ops-writev_buffer || f-ops-put_buffer;
+}
+
/**
* Flushes QEMUFile buffer
*
@@ -526,26 +529,24 @@ static void qemu_fflush(QEMUFile *f)
{
ssize_t ret = 0;
-if (!f-ops-writev_buffer !f-ops-put_buffer) {
+if (!qemu_file_is_writable(f)) {
return;
}
-if (f-is_write) {
-if (f-ops-writev_buffer) {
-if (f-iovcnt 0) {
-ret = f-ops-writev_buffer(f-opaque, f-iov, f-iovcnt);
-}
-} else {
-if (f-buf_index 0) {
-ret = f-ops-put_buffer(f-opaque, f-buf, f-pos,
f-buf_index);
-}
+if (f-ops-writev_buffer) {
+if (f-iovcnt 0) {
+ret = f-ops-writev_buffer(f-opaque, f-iov, f-iovcnt);
}
-if (ret = 0) {
-f-pos += ret;
+} else {
+if (f-buf_index 0) {
+ret = f-ops-put_buffer(f-opaque, f-buf, f-pos, f-buf_index);
}
-f-buf_index = 0;
-f-iovcnt = 0;
}
+if (ret = 0) {
+f-pos += ret;
+}
+f-buf_index = 0;
+f-iovcnt = 0;
if (ret 0) {
qemu_file_set_error(f, ret);
}
@@ -556,11 +557,7 @@ static void qemu_fill_buffer(QEMUFile *f)
int len;
int pending;
-if (!f-ops-get_buffer)
-return;
-
-if (f-is_write)
-abort();
+assert(!qemu_file_is_writable(f));
pending = f-buf_size - f-buf_index;
if (pending 0) {
@@ -629,7 +626,6 @@ static void add_to_iovec(QEMUFile *f, const uint8_t *buf,
int size)
f-iov[f-iovcnt++].iov_len = size;
}
-f-is_write = 1;
if (f-buf_index = IO_BUF_SIZE || f-iovcnt = MAX_IOV_SIZE) {
qemu_fflush(f);
}
@@ -646,12 +642,6 @@ void qemu_put_buffer_async(QEMUFile *f, const uint8_t
*buf, int size)
return;
}
-if (f-is_write == 0 f-buf_index 0) {
-fprintf(stderr,
-Attempted to write to buffer while read buffer is not
empty\n);
-abort();
-}
-
f-bytes_xfer += size;
add_to_iovec(f, buf, size);
}
@@ -664,12 +654,6 @@ void qemu_put_buffer(QEMUFile *f, const uint8_t *buf, int
size)
return;
}
-if (f-is_write == 0 f-buf_index 0) {
-fprintf(stderr,
-Attempted to write to buffer while read buffer is not
empty\n);
-abort();
-}
-
while (size 0) {
l = IO_BUF_SIZE - f-buf_index;
if (l size)
@@ -680,7 +664,6 @@ void qemu_put_buffer(QEMUFile *f, const uint8_t *buf, int
size)
add_to_iovec(f, f-buf + f-buf_index, l);
f-buf_index += l;
} else {
-f-is_write = 1;
f-buf_index += l;
if (f-buf_index == IO_BUF_SIZE) {
qemu_fflush(f);
@@ -700,19 +683,12 @@ void qemu_put_byte(QEMUFile *f, int v)
return;
}
-if (f-is_write == 0 f-buf_index 0) {
-fprintf(stderr,
-Attempted to write to buffer while read buffer is not
empty\n);
-abort();
-}
-
f-buf[f-buf_index] = v;
f-bytes_xfer++;
if (f-ops-writev_buffer) {
add_to_iovec(f, f-buf + f-buf_index, 1);
f-buf_index++;
} else {
-f-is_write = 1;
f-buf_index++;
if (f-buf_index == IO_BUF_SIZE) {
qemu_fflush(f);
@@ -732,9 +708,7 @@ static int qemu_peek_buffer(QEMUFile *f, uint8_t *buf, int
size, size_t offset)
int pending;
int index;
-if (f-is_write) {
-abort();
-}
+assert(!qemu_file_is_writable(f));
index = f-buf_index + offset;
pending = f-buf_size - index;
@@ -779,9 +753,7 @@ static int qemu_peek_byte(QEMUFile *f, int offset)
{
int index = f-buf_index + offset;
-if (f-is_write) {
-abort();
-}
+assert(!qemu_file_is_writable(f));
if (index = f-buf_size) {
qemu_fill_buffer(f);
--
1.8.2
[Qemu-devel] [PATCH 2/4] migration: use a single I/O operation when writev_buffer is not defined
The recent patches to use vectored I/O for RAM migration caused a
regression in savevm speed. To restore previous performance,
add data to the buffer in qemu_put_buffer_async whenever writev_buffer
is not available in the QEMUFile.
Signed-off-by: Paolo Bonzini pbonz...@redhat.com
---
savevm.c | 49 ++---
1 file changed, 34 insertions(+), 15 deletions(-)
diff --git a/savevm.c b/savevm.c
index c952c41..b32e0a7 100644
--- a/savevm.c
+++ b/savevm.c
@@ -525,27 +525,24 @@ static void qemu_file_set_error(QEMUFile *f, int ret)
static void qemu_fflush(QEMUFile *f)
{
ssize_t ret = 0;
-int i = 0;
if (!f-ops-writev_buffer !f-ops-put_buffer) {
return;
}
-if (f-is_write f-iovcnt 0) {
+if (f-is_write) {
if (f-ops-writev_buffer) {
-ret = f-ops-writev_buffer(f-opaque, f-iov, f-iovcnt);
-if (ret = 0) {
-f-pos += ret;
+if (f-iovcnt 0) {
+ret = f-ops-writev_buffer(f-opaque, f-iov, f-iovcnt);
}
} else {
-for (i = 0; i f-iovcnt ret = 0; i++) {
-ret = f-ops-put_buffer(f-opaque, f-iov[i].iov_base, f-pos,
- f-iov[i].iov_len);
-if (ret = 0) {
-f-pos += ret;
-}
+if (f-buf_index 0) {
+ret = f-ops-put_buffer(f-opaque, f-buf, f-pos,
f-buf_index);
}
}
+if (ret = 0) {
+f-pos += ret;
+}
f-buf_index = 0;
f-iovcnt = 0;
}
@@ -640,6 +637,11 @@ static void add_to_iovec(QEMUFile *f, const uint8_t *buf,
int size)
void qemu_put_buffer_async(QEMUFile *f, const uint8_t *buf, int size)
{
+if (!f-ops-writev_buffer) {
+qemu_put_buffer(f, buf, size);
+return;
+}
+
if (f-last_error) {
return;
}
@@ -673,8 +675,17 @@ void qemu_put_buffer(QEMUFile *f, const uint8_t *buf, int
size)
if (l size)
l = size;
memcpy(f-buf + f-buf_index, buf, l);
-f-buf_index += l;
-qemu_put_buffer_async(f, f-buf + (f-buf_index - l), l);
+f-bytes_xfer += size;
+if (f-ops-writev_buffer) {
+add_to_iovec(f, f-buf + f-buf_index, l);
+f-buf_index += l;
+} else {
+f-is_write = 1;
+f-buf_index += l;
+if (f-buf_index == IO_BUF_SIZE) {
+qemu_fflush(f);
+}
+}
if (qemu_file_get_error(f)) {
break;
}
@@ -697,8 +708,16 @@ void qemu_put_byte(QEMUFile *f, int v)
f-buf[f-buf_index] = v;
f-bytes_xfer++;
-add_to_iovec(f, f-buf + f-buf_index, 1);
-f-buf_index++;
+if (f-ops-writev_buffer) {
+add_to_iovec(f, f-buf + f-buf_index, 1);
+f-buf_index++;
+} else {
+f-is_write = 1;
+f-buf_index++;
+if (f-buf_index == IO_BUF_SIZE) {
+qemu_fflush(f);
+}
+}
}
static void qemu_file_skip(QEMUFile *f, int size)
--
1.8.2
[Qemu-devel] [PATCH 0/4] QEMUFile improvements and simplifications
This fixes Kevin's reported regression with savevm, and simplifies the QEMUFile code further. Patch 2 could be made a bit smaller at the expense of fixing the regression in the last patch only. I prefer to fix the bug earlier. Tested with Autotest. Paolo Bonzini (4): migration: set f-is_write and flush in add_to_iovec migration: use a single I/O operation when writev_buffer is not defined migration: drop is_write complications migration: simplify writev vs. non-writev logic savevm.c | 104 ++- 1 file changed, 42 insertions(+), 62 deletions(-) -- 1.8.2
[Qemu-devel] [PATCH 4/4] migration: simplify writev vs. non-writev logic
Check f-iovcnt in add_to_iovec, f-buf_index in qemu_put_buffer/byte.
Signed-off-by: Paolo Bonzini pbonz...@redhat.com
---
savevm.c | 22 +-
1 file changed, 9 insertions(+), 13 deletions(-)
diff --git a/savevm.c b/savevm.c
index a2f6bc0..63f4c82 100644
--- a/savevm.c
+++ b/savevm.c
@@ -626,7 +626,7 @@ static void add_to_iovec(QEMUFile *f, const uint8_t *buf,
int size)
f-iov[f-iovcnt++].iov_len = size;
}
-if (f-buf_index = IO_BUF_SIZE || f-iovcnt = MAX_IOV_SIZE) {
+if (f-iovcnt = MAX_IOV_SIZE) {
qemu_fflush(f);
}
}
@@ -662,12 +662,10 @@ void qemu_put_buffer(QEMUFile *f, const uint8_t *buf, int
size)
f-bytes_xfer += size;
if (f-ops-writev_buffer) {
add_to_iovec(f, f-buf + f-buf_index, l);
-f-buf_index += l;
-} else {
-f-buf_index += l;
-if (f-buf_index == IO_BUF_SIZE) {
-qemu_fflush(f);
-}
+}
+f-buf_index += l;
+if (f-buf_index == IO_BUF_SIZE) {
+qemu_fflush(f);
}
if (qemu_file_get_error(f)) {
break;
@@ -687,12 +685,10 @@ void qemu_put_byte(QEMUFile *f, int v)
f-bytes_xfer++;
if (f-ops-writev_buffer) {
add_to_iovec(f, f-buf + f-buf_index, 1);
-f-buf_index++;
-} else {
-f-buf_index++;
-if (f-buf_index == IO_BUF_SIZE) {
-qemu_fflush(f);
-}
+}
+f-buf_index++;
+if (f-buf_index == IO_BUF_SIZE) {
+qemu_fflush(f);
}
}
--
1.8.2
Re: [Qemu-devel] 答复: 答复: 答复: 答复: question about performance of dataplane
Zhangleiqiang zhangleiqi...@huawei.com wrote on 08/04/2013 02:13:50 PM: I think do multiple benchmarks with the same situation and calc the average value will eliminate the side effects. Calculating the average of multiple benchmarks may not solve the issue. For example, if for the dataplane scenario the other VM do X IOPs and for no-dataplane the other VM do Y IOPs then you may not be comparing apples to apples (unless you consider the other VM as part of the results). Last thing, IMHO, you should also evaluate scalability: how dataplane and no-dataplane perform when you run multiple VMs ? For example, first 1 VM with 2 VCPUs then 2 VMs with 2 VCPUs each then 3 VMs with 2 VCPUs each ... up to 12 VMs with 2 VCPUs each It seems like you unintentionally tested what happens with 2 VMs when you added the other VM to create I/O pressure. Indeed, the fact I used 2 VMs in previous benchmark is to ensure the vcpus is less than the host's cores, eg, each vm had 8 vpus. Thanks for your advice, I will evaluate the scalability, :) Thanks, I am looking forward for the results :)
Re: [Qemu-devel] [PATCH 08/22] target-i386: ioapic: replace FROM_SYSBUS() with QOM type cast
On Mon, 08 Apr 2013 10:13:28 +0800
li guang lig.f...@cn.fujitsu.com wrote:
This patch should be combined with [PATCH 07/22]
在 2013-04-05五的 16:37 +0200，Igor Mammedov写道：
Signed-off-by: Igor Mammedov imamm...@redhat.com
---
hw/ioapic_common.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/hw/ioapic_common.c b/hw/ioapic_common.c
index d4aff29..561b987 100644
--- a/hw/ioapic_common.c
+++ b/hw/ioapic_common.c
@@ -59,7 +59,7 @@ static int ioapic_dispatch_post_load(void *opaque, int
version_id)
static int ioapic_init_common(SysBusDevice *dev)
{
-IOAPICCommonState *s = FROM_SYSBUS(IOAPICCommonState, dev);
+IOAPICCommonState *s = IOAPIC_COMMON(dev);
IOAPICCommonClass *info;
static int ioapic_no;
sure, will do this on the next respin.
Re: [Qemu-devel] [PATCH v4] block: Add support for Secure Shell (ssh) block device.
On Wed, Apr 03, 2013 at 11:14:30PM +0100, Richard W.M. Jones wrote: On Thu, Mar 28, 2013 at 11:47:32AM +0100, Stefan Hajnoczi wrote: On Wed, Mar 27, 2013 at 03:57:29PM +, Richard W.M. Jones wrote: Please run qemu-iotests, see tests/qemu-iotests/check. For example, with NBD: $ cd tests/qemu-iotests $ QEMU_PROG=$HOME/qemu/x86_64-softmmu/qemu-system-x86_64 PATH=$HOME/qemu:$PATH \ ./check -nbd A patch will be required to add -ssh support to ./check. I have added this in the updated patch. A question: Are the -qcow2 tests meant to pass? Many don't pass for my ssh driver (ie. './check -ssh -qcow2'). I tried using the nbd driver (ie. './check -nbd -qcow2') and a large number of those fail as well. To take an example, test 013 fails because it tries to run the 'mv' command on the nbd: URL (or the ssh: URL when running the test on my block driver). It looks like this and other qcow2 tests are a bit broken on anything other than plain files. Yes, I don't expect qemu-iotests to work with qcow2-on-nbd. Just ./check -nbd and ./check -ssh should work. Stefan
Re: [Qemu-devel] [PATCH 11/22] cpu: introduce get_firmware_id() method and override it for target-i386
On Mon, 08 Apr 2013 10:02:21 +0800
li guang lig.f...@cn.fujitsu.com wrote:
在 2013-04-05五的 16:37 +0200，Igor Mammedov写道：
get_firmware_id() adds possibily for generic code to get guest visible
CPI id without accessing CPUArchState. If target doesn't override it,
it will return cpu_index.
Override it on target-i386 to return APIC ID.
Signed-off-by: Igor Mammedov imamm...@redhat.com
---
* it will be used later by new cpu_exists() generic function and
acpi_piix.
---
include/qom/cpu.h | 4 ++--
qom/cpu.c | 6 ++
target-i386/cpu.c | 10 ++
3 files changed, 18 insertions(+), 2 deletions(-)
diff --git a/include/qom/cpu.h b/include/qom/cpu.h
index 210aca3..0d33009 100644
--- a/include/qom/cpu.h
+++ b/include/qom/cpu.h
@@ -46,7 +46,7 @@ typedef struct CPUState CPUState;
* @reset: Callback to reset the #CPUState to its initial state.
* @do_interrupt: Callback for interrupt handling.
* @resume: Callback for putting CPU in runable state
- * @get_firmware_id: Callback for getting arch depended CPU id
+ * @get_firmware_id: Callback for getting arch depended CPU ID
get_firmware_id ?
seems obscure to me.
can't it be get_arch_cpuid?
*_cpuid might be confused with cpuid term on x86, not sure athe it would be
better. Perhaps then get_{arch|}_id() will be sufficient, since it's a method
of CPUClass and CPU is implied.
Re: [Qemu-devel] [RFC PATCH v2 1/4] net: port tap onto glib
On Wed, Apr 03, 2013 at 05:28:39PM +0800, liu ping fan wrote: On Thu, Mar 28, 2013 at 10:32 PM, Stefan Hajnoczi stefa...@gmail.com wrote: On Thu, Mar 28, 2013 at 03:55:52PM +0800, Liu Ping Fan wrote: From: Liu Ping Fan pingf...@linux.vnet.ibm.com Bind each NetClientState with a GSource(ie,NetClientSource). Currently, these GSource attached with default context, but in future, after resolving the race between handlers and the interface exposed by NetClientInfo and other re-entrant issue, we can run NetClientState on different threads Signed-off-by: Liu Ping Fan pingf...@linux.vnet.ibm.com --- include/net/net.h | 27 +++ net/net.c | 96 + net/tap.c | 57 +-- 3 files changed, 169 insertions(+), 11 deletions(-) Please split this into two patches: 1. NetClientSource 2. Convert tap to NetClientSource Once you do that it turns out that NetClientSource has nothing to do with the net subsystem, it's a generic file descriptor GSource (weird that glib doesn't already provide this abstraction). Each net client needs to reimplement .bind_ctx() anyway, so I don't see much point in having NetClientSource.nsrc[]. We might as well let net clients have that field themselves and destroy the GSource in their destructor function. The only way to detach the GSource from GMainContext is g_source_destroy, so if we want to re-bind nc from threadA to threadB, we should destroy the old one and create a new. Is that meaningful? I guess that can be done. What I was really thinking when I suggested getting rid of nsrc[] is that it's a little ugly to have the array with 2 GSources. Different net clients have different numbers of GSources - 0 for NICs, 1 for most backends, 2 for ioeventfd for virtio-net data plane with separate rx/tx. So my thought was to leave the number of GSources in the layer that uses them - each specific net client. Stefan
Re: [Qemu-devel] [RFC PATCH v2 0/4] port network layer onto glib
On Tue, Apr 02, 2013 at 05:49:57PM +0800, liu ping fan wrote: On Thu, Mar 28, 2013 at 9:40 PM, Stefan Hajnoczi stefa...@gmail.com wrote: On Thu, Mar 28, 2013 at 09:42:47AM +0100, Paolo Bonzini wrote: Il 28/03/2013 08:55, Liu Ping Fan ha scritto: 3rd. block layer's AioContext will block other AioContexts on the same thread. I cannot understand this. The plan is for BlockDriverState to be bound to an AioContext. That means each thread is set up with one AioContext. BlockDriverStates that are used in that thread will first be bound to its AioContext. It's not very useful to have multiple AioContext in the same thread. But it can be the case that we detach and re-attach the different device( AioContext) to the same thread. I think that the design of io_flush is to sync, but for NetClientState, we need something else. So if we use AioContext, is it proper to extend readable/writeable interface for qemu_aio_set_fd_handler()? Devices don't have AioContexts, threads do. When you bind a device to an AioContext the AioContext already exists independent of the device. Unfortunately I don't understand your question about io_flush and readable/writeable qemu_aio_set_fd_handler(). Stefan
Re: [Qemu-devel] [PATCH 13/22] acpi_piix4: add infrastructure to send CPU hot-plug GPE to guest
On Mon, 08 Apr 2013 10:24:50 +0800
li guang lig.f...@cn.fujitsu.com wrote:
在 2013-04-05五的 16:37 +0200，Igor Mammedov写道：
* introduce processor status bitmask visible to guest at 0xaf00 addr,
where Seabios expects it
* set bit corresponding to APIC ID in processor status bitmask on
receiving CPU hot-plug notification
* trigger CPU hot-plug SCI, expected by Seabios on receiving CPU
hot-plug notification
expected by seabios?
IMHO, seems you are saying ACPI's asl code which
just wrapped in seabios.
Yep, that's what ACPI asl code there expects. With current effort to move
ACPI tables into it might be better to s/Seabios/ACPI/ here.
Signed-off-by: Igor Mammedov imamm...@redhat.com
---
v2:
* use CPUClass.get_firmware_id() to make code target independent
* bump up vmstate_acpi version
---
hw/acpi_piix4.c | 114
++-- 1 file changed,
111 insertions(+), 3 deletions(-)
diff --git a/hw/acpi_piix4.c b/hw/acpi_piix4.c
index 48a32b5..ccfc028 100644
--- a/hw/acpi_piix4.c
+++ b/hw/acpi_piix4.c
@@ -48,19 +48,28 @@
#define PCI_EJ_BASE 0xae08
#define PCI_RMV_BASE 0xae0c
+#define PROC_BASE 0xaf00
+#define PROC_LEN 32
+
#define PIIX4_PCI_HOTPLUG_STATUS 2
+#define PIIX4_CPU_HOTPLUG_STATUS 4
struct pci_status {
uint32_t up; /* deprecated, maintained for migration compatibility */
uint32_t down;
};
+struct cpu_status {
+uint8_t sts[PROC_LEN];
+};
+
typedef struct PIIX4PMState {
PCIDevice dev;
MemoryRegion io;
MemoryRegion io_gpe;
MemoryRegion io_pci;
+MemoryRegion io_cpu;
ACPIREGS ar;
APMState apm;
@@ -82,6 +91,9 @@ typedef struct PIIX4PMState {
uint8_t disable_s3;
uint8_t disable_s4;
uint8_t s4_val;
+
+struct cpu_status gpe_cpu;
+Notifier cpu_add_notifier;
seems you named cpu_added_notifier at [PATCH 10/22],
should the notifer's name be unified?
I'll fix it on next respin, thanks.
} PIIX4PMState;
static void piix4_acpi_system_hot_add_init(MemoryRegion *parent,
@@ -100,8 +112,8 @@ static void pm_update_sci(PIIX4PMState *s)
ACPI_BITMASK_POWER_BUTTON_ENABLE |
ACPI_BITMASK_GLOBAL_LOCK_ENABLE |
ACPI_BITMASK_TIMER_ENABLE)) != 0) ||
-(((s-ar.gpe.sts[0] s-ar.gpe.en[0])
- PIIX4_PCI_HOTPLUG_STATUS) != 0);
+(((s-ar.gpe.sts[0] s-ar.gpe.en[0])
+ (PIIX4_PCI_HOTPLUG_STATUS | PIIX4_CPU_HOTPLUG_STATUS)) != 0);
qemu_set_irq(s-irq, sci_level);
/* schedule a timer interruption if needed */
@@ -257,6 +269,17 @@ static int acpi_load_old(QEMUFile *f, void *opaque,
int version_id) return ret;
}
+#define VMSTATE_CPU_STATUS_ARRAY(_field,
_state) \
+
{
\
+ .name =
(stringify(_field)), \
+ .version_id =
0,\
+ .num=
PROC_LEN, \
+ .info =
vmstate_info_uint8, \
+ .size =
sizeof(uint8_t), \
+ .flags =
VMS_ARRAY,\
+ .offset = vmstate_offset_array(_state, _field, uint8_t,
PROC_LEN), \
+ }
+
/* qemu-kvm 1.2 uses version 3 but advertised as 2
* To support incoming qemu-kvm 1.2 migration, change version_id
* and minimum_version_id to 2 below (which breaks migration from
@@ -265,7 +288,7 @@ static int acpi_load_old(QEMUFile *f, void *opaque,
int version_id) */
static const VMStateDescription vmstate_acpi = {
.name = piix4_pm,
-.version_id = 3,
+.version_id = 4,
.minimum_version_id = 3,
.minimum_version_id_old = 1,
.load_state_old = acpi_load_old,
@@ -281,6 +304,7 @@ static const VMStateDescription vmstate_acpi = {
VMSTATE_STRUCT(ar.gpe, PIIX4PMState, 2, vmstate_gpe, ACPIGPE),
VMSTATE_STRUCT(pci0_status, PIIX4PMState, 2, vmstate_pci_status,
struct pci_status),
+VMSTATE_CPU_STATUS_ARRAY(gpe_cpu.sts, PIIX4PMState),
VMSTATE_END_OF_LIST()
}
};
@@ -585,6 +609,83 @@ static const MemoryRegionOps piix4_pci_ops = {
},
};
+static uint64_t cpu_status_read(void *opaque, hwaddr addr, unsigned
width) +{
+PIIX4PMState *s = opaque;
+struct cpu_status *cpus = s-gpe_cpu;
+uint64_t val = cpus-sts[addr];
+return val;
+}
+
+static void cpu_status_write(void *opaque, hwaddr addr, uint64_t data,
+ unsigned int size)
+{
+/* TODO: implement VCPU removal on guest signal that CPU
Re: [Qemu-devel] [RFC PATCH v2 0/4] port network layer onto glib
On Mon, Apr 01, 2013 at 04:15:06PM +0800, liu ping fan wrote: On Thu, Mar 28, 2013 at 10:55 PM, Stefan Hajnoczi stefa...@gmail.com wrote: On Thu, Mar 28, 2013 at 03:55:51PM +0800, Liu Ping Fan wrote: It seems the AioContext vs glib issue hasn't been settled yet. My take is that glib is preferrable *if* we don't need to write too many helpers/wrappers on top (then we're basically back to rolling our own, AioContext). I was surprised by the amount of code required to listen on a file descriptor. Are you sure there isn't a glib way of doing this that avoids rolling our own GSource? Will diving more into the code, as mdroth's suggestion. Currently the main issue is that glib seems no support for readalbe or writable. I mentioned this in another reply. I'm not sure what you mean by glib does not support readable or writeable. It has G_IO_IN and G_IO_OUT for readable/writeable events. In the next series, please drop the hub re-entrancy stuff and virtio-net data plane. Instead just focus on systematically moving existing net clients onto the event loop (net/*.c and NICs). The only controversial issue there is AioContext vs glib, and once that's settled we can merge the patches. What about the core (queue.c, net.c)? Need I send them out at the same time or after the backend(clients) convert finished? I think the core changes are necessary to build the converted net clients, so they should be part of the series. Stefan
Re: [Qemu-devel] [0/2] [vmxnet3] iPXE support and byte swapping fix
On Thu, Mar 28, 2013 at 10:53:28AM +0200, Dmitry Fleytman wrote: These patch set introduces 2 fixes: 1. Compatibility with iPXE vmxnet3 driver Reported-by: Stefan Hajnoczi stefa...@gmail.com 2. Duplicate byte swapping while parsing device features on big endian platforms Reported-by: Alexander Graf ag...@suse.de Dmitry Fleytman (2): [vmxnet3] iPXE compatibility fixes [vmxnet3] const_cpu_to_le64 wrapping for feature bits dropped hw/vmxnet3.c | 11 +++ hw/vmxnet3.h | 11 --- 2 files changed, 15 insertions(+), 7 deletions(-) -- 1.8.1.4 Thanks, applied to my net tree: https://github.com/stefanha/qemu/commits/net Stefan
Re: [Qemu-devel] A crash problem about loadvm
On Mon, Apr 01, 2013 at 07:56:33AM +, Liuji (Jeremy) wrote: I delete the dev-sin = NULL; in the last of spice_char_device_reset function. And the loadvm is OK. But I don't know whether this change will lead to other problems. Who can give me some advice? See the ./MAINTAINERS file to find out who is responsible for a QEMU subsystem. I have CCed Gerd Hoffmann, who is the maintainer. Stefan Best Regards, Jeremy Liu Hello, everyone I found a problem about loadvm, when I use Spice. Host OS: Fedora 17 Qemu: 1.4.0 Spice: 0.12.2 Quest OS: WinXP 1) Use the following command to start the VM: qemu-kvm -enable-kvm -name winxp -M pc-0.15 -m 1024 -smp 2 -boot c -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x5 -drive file=/home/test/winxp.qcow2,if=virtio,index=0,format=qcow2 -net nic,model=virtio,macaddr=52:54:00:05:11:12 -monitor stdio -chardev spicevmc,id=charchannel0,name=vdagent -device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=com.redhat.spice.0 -chardev pty,id=charchannel1 -device virtserialport,bus=virtio-serial0.0,nr=2,chardev=charchannel1,id=channel1,name=arbitrary.virtio.serial.port.name -device usb-tablet,id=input0 -spice port=3001,addr=186.100.8.131,disable-ticketing,plaintext-channel=main,plaintext-channel=playback,plaintext-channel=record,image-compression=auto_glz -vga qxl -global qxl-vga.vram_size=67108864 -device AC97,id=sound0,bus=pci.0,addr=0x4 2) Use spice client to connect the VM. 3) Exec the savevm command in the qemu monitor. 4) List snapshot information: info snapshots IDTAG VM SIZEDATE VM CLOCK 1 vm-20130330181626 224M 2013-03-30 18:16:26 00:00:17.294 5) Load the snapshot. But the process crashed: loadvm vm-20130330181626 red_dispatcher_loadvm_commands: Segmentation fault (core dumped) I use the GDB to analyze the core-dump file: #0 0x7f6cbdc37a15 in spice_char_device_write_to_device (dev=0x7f6cc5248320) at char_device.c:439 439 sif = SPICE_CONTAINEROF(dev-sin-base.sif, SpiceCharDeviceInterface, base); (gdb) p dev $1 = (SpiceCharDeviceState *) 0x7f6cc5248320 (gdb) p dev-sin $2 = (SpiceCharDeviceInstance *) 0x0 I have always found this problem after the commit(fc24f3bd2ed4c97c99ad40e747732ae46dff2009 spice: notify spice server on vm start/stop). Could you give me some advices to debug this problem? -- Best Regards, Jeremy Liu
Re: [Qemu-devel] After executing savevm, the QEMU process is hanging
On Mon, Apr 01, 2013 at 11:45:13AM +, Liuji (Jeremy) wrote: Hello, everyone After executing the savevm command, the QEMU process is hanging. But in the v1.4.0, it's no problem. Host OS: Fedora 17 x86_64 Qemu: the latest(2013-04-01) Quest OS: WinXP 1) Use the following command to start the VM: qemu-kvm -enable-kvm -name winxp -M pc-0.15 -m 1024 -smp 2 -boot c -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x5 -drive file=/home/test/winxp.qcow2,if=virtio,index=0,format=qcow2 -net nic,model=virtio,macaddr=52:54:00:05:11:12 -monitor stdio -chardev spicevmc,id=charchannel0,name=vdagent -device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=com.redhat.spice.0 -chardev pty,id=charchannel1 -device virtserialport,bus=virtio-serial0.0,nr=2,chardev=charchannel1,id=channel1,name=arbitrary.virtio.serial.port.name -device usb-tablet,id=input0 -spice port=3001,addr=186.100.8.131,disable-ticketing,plaintext-channel=main,plaintext-channel=playback,plaintext-channel=record,image-compression=auto_glz -vga qxl -global qxl-vga.vram_size=67108864 -device AC97,id=sound0,bus=pci.0,addr=0x4 2) Execute the savevm command in the qemu monitor. After a long time (20minute), the qemu process is still hanging. Who can give me some advice? Have you tried qemu.git/master? Once you find out which version works and which is broken, you can use git-bisect(1) to find the commit that broke savevm. Stefan
Re: [Qemu-devel] [PATCH] Document mcast+ipv6 (Was: Re: socket, mcast looping back frames - IPv6 broken)
Stefan Hajnoczi, le Mon 08 Apr 2013 13:13:19 +0200, a écrit : On Mon, Apr 01, 2013 at 02:12:51AM +0200, Samuel Thibault wrote: Stefan Hajnoczi, le Mon 11 Mar 2013 09:36:14 +0100, a écrit : Otherwise we may just document that one has to disable Duplicate Address Detection to get IPv6 working :/ Seems like this might be the only way for now. Here is a patch Let's check out the 2 socket patch first. If that doesn't work out I'll merge the documentation warning. Sure. Samuel
Re: [Qemu-devel] Ongoing big-endian vmxnet3 breakage
On Mon, Apr 01, 2013 at 09:18:55PM -0700, Richard Henderson wrote: The build has been broken for *far* too long. Can we please apply *any* of the patches that have been posted to fix it. Even if the patch is not 100% correct, a non-working driver is preferred to a compile error that affects unrelated development. I am sending a pull request with Dmitry's fix for the vmxnet3 big-endian warning. Stefan
Re: [Qemu-devel] [PATCH uq/master v2 1/2] kvm: reset state from the CPU's reset method
On Tue, Apr 02, 2013 at 04:29:32PM +0300, Gleb Natapov wrote:
static void kvm_sw_tlb_put(PowerPCCPU *cpu)
{
CPUPPCState *env = cpu-env;
diff --git a/target-s390x/cpu.c b/target-s390x/cpu.c
index 23fe51f..6321384 100644
--- a/target-s390x/cpu.c
+++ b/target-s390x/cpu.c
@@ -84,6 +84,10 @@ static void s390_cpu_reset(CPUState *s)
* after incrementing the cpu counter */
#if !defined(CONFIG_USER_ONLY)
s-halted = 1;
+
+if (kvm_enabled()) {
+kvm_arch_reset_vcpu(s);
Does this compile with kvm support disabled?
Well, it does not:
CCs390x-softmmu/target-s390x/cpu.o
/users/gleb/work/qemu/target-s390x/cpu.c: In function 's390_cpu_reset':
/users/gleb/work/qemu/target-s390x/cpu.c:89:9: error: implicit
declaration of function 'kvm_arch_reset_vcpu'
[-Werror=implicit-function-declaration]
/users/gleb/work/qemu/target-s390x/cpu.c:89:9: error: nested extern
declaration of 'kvm_arch_reset_vcpu' [-Werror=nested-externs]
cc1: all warnings being treated as errors
I wonder if it is portable between compilers to rely on code in if(0){} to
be dropped in all levels of optimizations.
--
Gleb.
Re: [Qemu-devel] SIGUSR1 handle within QEMU
On Fri, Apr 05, 2013 at 06:30:02AM +, Lal Nitesh-B44382 wrote: I was trying to figure out how SIGUSR1 is been handled by QEMU as I am getting multiple SIGUSR1 in my trace when I run the guest . If anyone could guide me on this, that would be of great help. Use grep: $ git grep SIGUSR1 include/qemu/main-loop.h:#define SIG_IPI SIGUSR1 $ git grep SIG_IPI cpus.c:sigaddset(waitset, SIG_IPI); cpus.c:} while (sigismember(chkset, SIG_IPI) || sigismember(chkset, SIGBUS)); cpus.c:sigaction(SIG_IPI, sigact, NULL); cpus.c:sigdelset(set, SIG_IPI); cpus.c:sigaction(SIG_IPI, sigact, NULL); cpus.c:sigaddset(set, SIG_IPI); cpus.c:sigaddset(waitset, SIG_IPI); cpus.c:err = pthread_kill(cpu-thread-thread, SIG_IPI); include/qemu/main-loop.h:#define SIG_IPI SIGUSR1 main-loop.c: * SIG_IPI must be blocked in the main thread and must not be caught main-loop.c:sigaddset(set, SIG_IPI); main-loop.c:sigdelset(set, SIG_IPI); SIGUSR1 is used to notify vcpu threads. If SIGUSR1 keeps stopping gdb: $ cat ~/.gdbinit handle SIGUSR1 noprint nostop pass Stefan
[Qemu-devel] reply: reply: qemu crashed when starting vm(kvm) with vnc connect
On Sun, Apr 07, 2013 at 04:58:07AM +, Zhanghaoyu (A) wrote: I start a kvm VM with vnc(using the zrle protocol) connect, sometimes qemu program crashed during starting period, received signal SIGABRT. Trying about 20 times, this crash may be reproduced. I guess the cause memory corruption or double free. Which version of QEMU are you running? Please try qemu.git/master. Stefan I used the QEMU download from qemu.git (http://git.qemu.org/git/qemu.git). Great, thanks! Can you please post a backtrace? The easiest way is: $ ulimit -c unlimited $ qemu-system-x86_64 -enable-kvm -m 1024 ... ...crash... $ gdb -c qemu-system-x86_64.core (gdb) bt Depending on how your system is configured the core file might have a different filename but there should be a file name *core* the current working directory after the crash. The backtrace will make it possible to find out where the crash occurred. Thanks, Stefan backtrace from core file is shown as below: Program received signal SIGABRT, Aborted. 0x7f32eda3dd95 in raise () from /lib64/libc.so.6 (gdb) bt #0 0x7f32eda3dd95 in raise () from /lib64/libc.so.6 #1 0x7f32eda3f2ab in abort () from /lib64/libc.so.6 #2 0x7f32eda77ece in __libc_message () from /lib64/libc.so.6 #3 0x7f32eda7dc06 in malloc_printerr () from /lib64/libc.so.6 #4 0x7f32eda7ecda in _int_free () from /lib64/libc.so.6 #5 0x7f32efd3452c in free_and_trace (mem=0x7f329cd0) at vl.c:2880 #6 0x7f32efd251a1 in buffer_free (buffer=0x7f32f0c82890) at ui/vnc.c:505 #7 0x7f32efd20c56 in vnc_zrle_clear (vs=0x7f32f0c762d0) at ui/vnc-enc-zrle.c:364 #8 0x7f32efd26d07 in vnc_disconnect_finish (vs=0x7f32f0c762d0) at ui/vnc.c:1050 #9 0x7f32efd275c5 in vnc_client_read (opaque=0x7f32f0c762d0) at ui/vnc.c:1349 #10 0x7f32efcb397c in qemu_iohandler_poll (readfds=0x7f32f074d020, writefds=0x7f32f074d0a0, xfds=0x7f32f074d120, ret=1) at iohandler.c:124 #11 0x7f32efcb46e8 in main_loop_wait (nonblocking=0) at main-loop.c:417 #12 0x7f32efd31159 in main_loop () at vl.c:2133 #13 0x7f32efd38070 in main (argc=46, argv=0x7fff7f5df178, envp=0x7fff7f5df2f0) at vl.c:4481 Zhang Haoyu
Re: [Qemu-devel] rpiqemuwindows bug
On Fri, Apr 05, 2013 at 11:58:09PM -0400, Gaston Gutierrez wrote: I installed rpiqemuwindows in a lenovo T420, 64bits, intel core i5 2.5GHz, 4GB RAM, win7 motebok. At running 2013-02-09-wheezy-raspbian.img, the boot process enters in a loop and throws INIT: Id 1 respawning too fast :: disabled for 5 minutes. This is a image bug or qemu is not full compatible with this lenovo machine? Seems like a problem with the raspbian image you are using, possibly due to how rpiqemuwindows or the VM is configured. Please note that qemu-devel is about upstream QEMU (http://qemu-project.org/). I don't know what rpiqemuwindows is and this mailing list is not a place for raspbian support. You can probably get better help if you ask the Raspbian community. Hope this helps, Stefan
[Qemu-devel] [PATCH 2/2] vmxnet3: const_cpu_to_le64 wrapping for feature bits dropped
From: Dmitry Fleytman dmi...@daynix.com
Byte swap is redundant because shared memory reading functions
already swap bytes when required
Signed-off-by: Dmitry Fleytman dmi...@daynix.com
Acked-by: Alexander Graf ag...@suse.de
Signed-off-by: Stefan Hajnoczi stefa...@redhat.com
---
hw/vmxnet3.h | 11 ---
1 file changed, 4 insertions(+), 7 deletions(-)
diff --git a/hw/vmxnet3.h b/hw/vmxnet3.h
index 7db0c8f..4eae7c7 100644
--- a/hw/vmxnet3.h
+++ b/hw/vmxnet3.h
@@ -37,10 +37,8 @@
#define __packed QEMU_PACKED
#if defined(HOST_WORDS_BIGENDIAN)
-#define const_cpu_to_le64(x) bswap_64(x)
#define __BIG_ENDIAN_BITFIELD
#else
-#define const_cpu_to_le64(x) (x)
#endif
/*
@@ -137,10 +135,10 @@ struct UPT1_RSSConf {
/* features */
enum {
-UPT1_F_RXCSUM= const_cpu_to_le64(0x0001), /* rx csum verification
*/
-UPT1_F_RSS= const_cpu_to_le64(0x0002),
-UPT1_F_RXVLAN= const_cpu_to_le64(0x0004), /* VLAN tag stripping */
-UPT1_F_LRO= const_cpu_to_le64(0x0008),
+UPT1_F_RXCSUM= 0x0001, /* rx csum verification */
+UPT1_F_RSS = 0x0002,
+UPT1_F_RXVLAN= 0x0004, /* VLAN tag stripping */
+UPT1_F_LRO = 0x0008,
};
/* all registers are 32 bit wide */
@@ -752,7 +750,6 @@ struct Vmxnet3_DriverShared {
#undef __le32
#undef __le64
#undef __packed
-#undef const_cpu_to_le64
#if defined(HOST_WORDS_BIGENDIAN)
#undef __BIG_ENDIAN_BITFIELD
#endif
--
1.8.1.4
[Qemu-devel] [PATCH 1/2] vmxnet3: iPXE compatibility fixes
From: Dmitry Fleytman dmi...@daynix.com
iPXE vmxnet3 driver makes a few assumptions regarding device operation
that were missed during testing with Linux and Windows drivers.
This patch adds following logic:
1. Additional GET commands processing added
2. Max number of RX chunks should be set to 1 when driver passes 0
via corresponding shared memory field
3. Enforecement for max chunks number added
Signed-off-by: Dmitry Fleytman dmi...@daynix.com
Signed-off-by: Stefan Hajnoczi stefa...@redhat.com
---
hw/vmxnet3.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/hw/vmxnet3.c b/hw/vmxnet3.c
index bdd256e..1e18168 100644
--- a/hw/vmxnet3.c
+++ b/hw/vmxnet3.c
@@ -1033,6 +1033,7 @@ vmxnet3_indicate_packet(VMXNET3State *s)
is_head = false;
ready_rxcd_pa = new_rxcd_pa;
new_rxcd_pa = 0;
+num_frags++;
}
if (0 != ready_rxcd_pa) {
@@ -1324,6 +1325,10 @@ static void vmxnet3_activate_device(VMXNET3State *s)
s-max_rx_frags =
VMXNET3_READ_DRV_SHARED16(s-drv_shmem, devRead.misc.maxNumRxSG);
+if (s-max_rx_frags == 0) {
+s-max_rx_frags = 1;
+}
+
VMW_CFPRN(Max RX fragments is %u, s-max_rx_frags);
s-event_int_idx =
@@ -1524,6 +1529,12 @@ static uint64_t vmxnet3_get_command_status(VMXNET3State
*s)
VMW_CFPRN(Device active: % PRIx64, ret);
break;
+case VMXNET3_CMD_RESET_DEV:
+case VMXNET3_CMD_QUIESCE_DEV:
+case VMXNET3_CMD_GET_QUEUE_STATUS:
+ret = 0;
+break;
+
case VMXNET3_CMD_GET_LINK:
ret = s-link_status_and_speed;
VMW_CFPRN(Link and speed: % PRIx64, ret);
--
1.8.1.4
[Qemu-devel] [PULL 0/2] Net patches
These vmxnet3 fixes solve big-endian host build failures and make iPXE's vmxnet3 driver work. Dmitry Fleytman (2): vmxnet3: iPXE compatibility fixes vmxnet3: const_cpu_to_le64 wrapping for feature bits dropped hw/vmxnet3.c | 11 +++ hw/vmxnet3.h | 11 --- 2 files changed, 15 insertions(+), 7 deletions(-) -- 1.8.1.4
Re: [Qemu-devel] [PATCH] sh7750: Fix crash when accessing PVR/PRR/CVR
On 26 March 2013 14:35, Andreas Färber afaer...@suse.de wrote: Am 26.03.2013 13:20, schrieb Peter Maydell: Commit b350ab75 causes segfaults on accesses to PVR/PRR/CVR because it tries to call SUPERH_CPU_GET_CLASS() on a pointer that isn't a QOM object. Fix this by getting the actual QOM CPU object first. Signed-off-by: Peter Maydell peter.mayd...@linaro.org --- Tested with the r2d image/instructions from https://oss.renesas.com/modules/document/?Getting%20Started%20with%20SH4%20and%20QEMU Oops, reproduces with the test image from the QEMU Wiki as well. Seems to be a result of cherry-picking this commit before the full SH7750 QOM'ification. Is this blocking any work of yours? Otherwise I would try rebasing my SH7750 patches so that s-cpu becomes a SuperHCPU as expected here. (Not sure if simply reverting my offending patch still works?) Ping -- were you planning to submit these patches soon or should we just commit this patch to fix the breakage for now? thanks -- PMM
Re: [Qemu-devel] [PATCH v4] block: Add support for Secure Shell (ssh) block device.
On Mon, Apr 08, 2013 at 01:37:28PM +0200, Stefan Hajnoczi wrote: Just ./check -nbd and ./check -ssh should work. Both work 100% for me (with patch v7). Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming blog: http://rwmj.wordpress.com Fedora now supports 80 OCaml packages (the OPEN alternative to F#)
Re: [Qemu-devel] question about performance of dataplane
-Original Message- From: Stefan Hajnoczi [mailto:stefa...@gmail.com] Sent: Monday, April 08, 2013 7:09 PM On Sun, Apr 07, 2013 at 09:05:47AM -0500, Anthony Liguori wrote: Zhangleiqiang zhangleiqi...@huawei.com writes: 1. Environment: a). Qemu 1.4 master branch b). kernel: 3.5.0-2.fc17.x86_64 c). virtual disks location: the same local SATA harddisk with ext4 fs I doubt you'll see any performance difference with a single SATA drive. There's no real parallelism possible as you have exactly one spindle available. Sorry for the delay, catching up on emails after my Easter vacation. I agree with Anthony here. It seems your benchmark configuration is bottlenecked below the point where data plane makes a difference. I'm not understand what the no real parallelism possible as you have exactly one spindle means. Dose it means I should put os vdisk onto a different harddisk from the data vdisks? Or it means I should put data vdisk on different harddisks? But under the benchmark scenario mentioned above, even the os vdisk and data vdisks was on the same harddisk, the IOMeter only generated IO to data vdisks; Besides, the benchmark of dataplane disk and non-dataplane disk was did continuously other than simultaneously. I have finished some benchmarks these days, and the results have already been sent to the mail list. It seems the dataplane has advantage when there is IO competition. I guess maybe the non-dataplane already reached the physical disk's IOPS upper limit in the scenario above so that data plane didn't make a difference? -- Leiqzhang Best Regards
[Qemu-devel] [PATCH] qemu-char: really fix behavior on can_read = 0
I misread the glib manual, g_source_remove does not let you re-attach
the source later. This behavior (called blocking the source in glib)
is present in glib's source code, but private and not available outside
glib; hence, we have to resort to re-creating the source every time.
In fact, g_source_remove and g_source_destroy are the same thing,
except g_source_destroy is O(1) while g_source_remove scans a potentially
very long list of GSources in the current main loop. Ugh. Better
use g_source_destroy explicitly, and leave tags to those dummies who
cannot track their pointers' lifetimes.
Signed-off-by: Paolo Bonzini pbonz...@redhat.com
---
qemu-char.c | 17 +
1 file changed, 13 insertions(+), 4 deletions(-)
diff --git a/qemu-char.c b/qemu-char.c
index dd410ce..eae17fc 100644
--- a/qemu-char.c
+++ b/qemu-char.c
@@ -596,9 +596,11 @@ typedef struct IOWatchPoll
{
GSource parent;
+GIOChannel *channel;
GSource *src;
IOCanReadHandler *fd_can_read;
+GSourceFunc fd_read;
void *opaque;
} IOWatchPoll;
@@ -611,15 +613,19 @@ static gboolean io_watch_poll_prepare(GSource *source,
gint *timeout_)
{
IOWatchPoll *iwp = io_watch_poll_from_source(source);
bool now_active = iwp-fd_can_read(iwp-opaque) 0;
-bool was_active = g_source_get_context(iwp-src) != NULL;
+bool was_active = iwp-src != NULL;
if (was_active == now_active) {
return FALSE;
}
if (now_active) {
+iwp-src = g_io_create_watch(iwp-channel, G_IO_IN | G_IO_ERR |
G_IO_HUP);
+g_source_set_callback(iwp-src, iwp-fd_read, iwp-opaque, NULL);
g_source_attach(iwp-src, NULL);
} else {
-g_source_remove(g_source_get_id(iwp-src));
+g_source_destroy(iwp-src);
+g_source_unref(iwp-src);
+iwp-src = NULL;
}
return FALSE;
}
@@ -638,7 +644,9 @@ static gboolean io_watch_poll_dispatch(GSource *source,
GSourceFunc callback,
static void io_watch_poll_finalize(GSource *source)
{
IOWatchPoll *iwp = io_watch_poll_from_source(source);
+g_source_destroy(iwp-src);
g_source_unref(iwp-src);
+iwp-src = NULL;
}
static GSourceFuncs io_watch_poll_funcs = {
@@ -659,8 +667,9 @@ static guint io_add_watch_poll(GIOChannel *channel,
iwp = (IOWatchPoll *) g_source_new(io_watch_poll_funcs,
sizeof(IOWatchPoll));
iwp-fd_can_read = fd_can_read;
iwp-opaque = user_data;
-iwp-src = g_io_create_watch(channel, G_IO_IN | G_IO_ERR | G_IO_HUP);
-g_source_set_callback(iwp-src, (GSourceFunc)fd_read, user_data, NULL);
+iwp-channel = channel;
+iwp-fd_read = (GSourceFunc) fd_read;
+iwp-src = NULL;
return g_source_attach(iwp-parent, NULL);
}
--
1.8.1.4
Re: [Qemu-devel] [PATCH v4] block: Add support for Secure Shell (ssh) block device.
More specifically, here's the output on my machine: rjones@choo:~/d/qemu/tests/qemu-iotests$ QEMU_PROG=~/d/qemu/x86_64-softmmu/qemu-system-x86_64 PATH=~/d/qemu:$PATH ./check -ssh QEMU -- /home/rjones/d/qemu/x86_64-softmmu/qemu-system-x86_64 QEMU_IMG -- /home/rjones/d/qemu/qemu-img QEMU_IO -- /home/rjones/d/qemu/qemu-io IMGFMT-- raw IMGPROTO -- ssh PLATFORM -- Linux/x86_64 choo 3.7.2-204.fc18.x86_64 001 7s ... 002 11s ... 003 11s ... 004 19s ... 005 4s ... 006 [not run] not suitable for this image format: raw 007 18s ... [not run] not suitable for this image format: raw 008 8s ... 009 3s ... 010 4s ... 011 17s ... 012 [not run] not suitable for this image protocol: ssh 013 [not run] not suitable for this image format: raw 014[not run] not suitable for this image format: raw 015 53s ... [not run] not suitable for this image format: raw 016 [not run] not suitable for this image protocol: ssh 017 [not run] not suitable for this image format: raw 018[not run] not suitable for this image format: raw 019 [not run] not suitable for this image format: raw 020 [not run] not suitable for this image format: raw 021 48s ... 022 37s ... [not run] not suitable for this image format: raw 023 [not run] not suitable for this image format: raw 024 [not run] not suitable for this image format: raw 025[not run] not suitable for this image protocol: ssh 026 [not run] not suitable for this image format: raw 027 7s ... [not run] not suitable for this image format: raw 028 [not run] not suitable for this image format: raw 029 10s ... [not run] not suitable for this image format: raw 030 [not run] not suitable for this image format: raw 031 [not run] not suitable for this image format: raw 032 5s ... 033 14s ... 034 [not run] not suitable for this image format: raw 035 3s ... [not run] not suitable for this image format: raw 036 [not run] not suitable for this image format: raw 037 [not run] not suitable for this image format: raw 038[not run] not suitable for this image format: raw 039 [not run] not suitable for this image format: raw 040 10s ... [not run] not suitable for this image format: raw 041 20s ... [not run] not suitable for this image format: raw 042 [not run] not suitable for this image format: raw 043 [not run] not suitable for this image format: raw 044 29s ... [not run] not suitable for this image format: raw 045 1s ... 046 [not run] not suitable for this image format: raw 047 2s ... [not run] not suitable for this image format: raw 048 [not run] not suitable for this image protocol: ssh 049 [not run] not suitable for this image format: raw 050[not run] not suitable for this image format: raw 052 13s ... Not run: 006 007 012 013 014 015 016 017 018 019 020 022 023 024 025 026 027 028 029 030 031 034 035 036 037 038 039 040 041 042 043 044 046 047 048 049 050 Passed all 14 tests Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming blog: http://rwmj.wordpress.com Fedora now supports 80 OCaml packages (the OPEN alternative to F#)
[Qemu-devel] Support for VNC LED state extension proposal
Hi, This proposal aims to add support for VNC LED state extension to Qemu VNC server. It also contains the proposal of this VNC extension, althrough it should be sent to some other mailing, but we'd like to send to Qemu mailing list first to have your suggestion. Please let me know your ideas and thoughts. When access a guest by console through VNC, there might be mismatch between the lock keys notification LED on the computer running the VNC client session and the current status of the lock keys on the guest machine. This happens because the VNC protocol does not have any support to deal with setting led state. To solve this, we plan to: 1) Add LED state extension to VNC proposal (As the description in 'Proposal for adding LED state extensions to VNC protocol'). 2) Support VNC LED state extension in Qemu. The general flow is: 1) A client that supports the LED state extension starts by requesting the led flags Psuedo-encoding. 2) Server then send a message to the client with the current LED state if this extension is supported. 3) Clinet receive this message and sync with server by setting the local LED state. 4) Everytime the LED state is changed, server will send an update of the current LED state to client, and client will resync with server. For instance, if the change of LED state is requested from remote client through VNC, client will send scancode to VNC server (This is base on the extension 'QEMU Extended Key Event Message' Anthony have already added to VNC protocol as reference link below), server pass the scancode to OS/X11 and then OS/X11 handle the setting of keyboard LED. After the setting job, server receive the LED state event from OS/X11, will send current LED state message to client. Then, client will resync the LED state with server based on this message by setting the local LED state. http://tigervnc.svn.sourceforge.net/viewvc/tigervnc/rfbproto/rfbproto.rst?content-type=text/plain -- Proposal for adding LED state extensions to VNC protocol QEMU LED state extension Psuedo-encoding A client that supports the LED extension starts by requesting the led flags pseudo-encoding declaring that it is capable of accepting the `QEMU LED state extensions Server Message`_. The server, in turn, will send the current led flags in an update `FrameBufferUpdate`_ with the matching psuedo-encoding and the *num-rectangles* field set to 1, however, no rectangles will actually be sent. After sending this notification, server will update the led flags everytime the led state is changed in the update, client could resync the led state with the server by setting the local led state accordingly. === === === No. of bytesTypeDescription === === === 1 ``U8`` *led-flags* === === === The example psuedo-encodings for *led-flags* defined as following: === === CodeDescription === === 100 CapsLock is set 010 NumLock is set 001 ScrollLock is set 110 CapsLock and NumLock are set 111 CapsLock, NumLock and ScrollLock are set === === QEMU LED state extensions Server Message This submessage allows the server to send the current led state for the lock keys (CapsLock, NumLock and ScrollLock) to client. === == === No. of bytesType [Value]Description === == === 1 ``U8`` 255*message-type* 1 ``U8`` 2 *submessage-type* 1 ``U8`` *led-flags* === == === The *led-flags* fields take the same values as described for the 'QEMU LEDs state extension Psuedo-encoding'_.
[Qemu-devel] [qemu PATCH 3/5] hw/acpi: export default ACPI headers using the type just introduced
This enables reuse when preparing per-table fw_cfg blobs later.
Signed-off-by: Laszlo Ersek ler...@redhat.com
---
hw/acpi.h |2 ++
hw/acpi.c | 39 ---
2 files changed, 26 insertions(+), 15 deletions(-)
diff --git a/hw/acpi.h b/hw/acpi.h
index d69b6ef..e3e17e9 100644
--- a/hw/acpi.h
+++ b/hw/acpi.h
@@ -165,4 +165,6 @@ typedef struct acpi_table_std_header {
char asl_compiler_id[4]; /* ASL compiler vendor ID */
uint32_t asl_compiler_revision; /* ASL compiler revision number */
} QEMU_PACKED AcpiTableStdHdr;
+
+extern const AcpiTableStdHdr acpi_dfl_hdr;
#endif /* !QEMU_HW_ACPI_H */
diff --git a/hw/acpi.c b/hw/acpi.c
index 73af4bd..f24be53 100644
--- a/hw/acpi.c
+++ b/hw/acpi.c
@@ -37,11 +37,20 @@ struct acpi_table_header {
/* size of the extra prefix */
#define ACPI_TABLE_PFX_SIZE offsetof(struct acpi_table_header, std)
-static const char unsigned dfl_hdr[sizeof(AcpiTableStdHdr)] =
-QEMU\0\0\0\0\1\0 /* sig (4), len(4), revno (1), csum (1) */
-QEMUQEQEMUQEMU\1\0\0\0 /* OEM id (6), table (8), revno (4) */
-QEMU\1\0\0\0 /* ASL compiler ID (4), version (4) */
-;
+const AcpiTableStdHdr acpi_dfl_hdr = {
+.sig = QEMU,
+.revision = 1,
+.oem_id = QEMUQE,
+.oem_table_id = QEMUQEMU,
+.asl_compiler_id = QEMU,
+#ifdef HOST_WORDS_BIGENDIAN
+.oem_revision = 0x0100,
+.asl_compiler_revision = 0x0100
+#else
+.oem_revision = 1,
+.asl_compiler_revision = 1
+#endif
+};
char unsigned *acpi_tables;
size_t acpi_tables_len;
@@ -74,8 +83,8 @@ static int acpi_checksum(const uint8_t *data, int len)
/* Install a copy of the ACPI table specified in @blob.
*
* If @has_header is set, @blob starts with the System Description Table Header
- * structure. Otherwise, dfl_hdr is prepended. In any case, each header field
- * is optionally overwritten from @hdrs.
+ * structure. Otherwise, acpi_dfl_hdr is prepended. In any case, each header
+ * field is optionally overwritten from @hdrs.
*
* It is valid to call this function with
* (@blob == NULL bloblen == 0 !has_header).
@@ -105,13 +114,13 @@ static void acpi_table_install(const char unsigned *blob,
size_t bloblen,
if (has_header) {
/* _length | ACPI header in blob | blob body
* ^^^ ^^^ ^
- * ACPI_TABLE_PFX_SIZE sizeof dfl_hdr body_size
+ * ACPI_TABLE_PFX_SIZE sizeof acpi_dfl_hdr body_size
* == body_start
*
* ^^^
* acpi_payload_size == bloblen
*/
-body_start = sizeof dfl_hdr;
+body_start = sizeof acpi_dfl_hdr;
if (bloblen body_start) {
error_setg(errp, ACPI table claiming to have header is too
@@ -123,17 +132,17 @@ static void acpi_table_install(const char unsigned *blob,
size_t bloblen,
} else {
/* _length | ACPI header in template | blob body
* ^^^ ^^^ ^^
- * ACPI_TABLE_PFX_SIZE sizeof dfl_hdrbody_size
+ * ACPI_TABLE_PFX_SIZE sizeof acpi_dfl_hdr body_size
* == bloblen
*
*
* acpi_payload_size
*/
body_start = 0;
-hdr_src = dfl_hdr;
+hdr_src = (const char unsigned *)acpi_dfl_hdr;
}
body_size = bloblen - body_start;
-acpi_payload_size = sizeof dfl_hdr + body_size;
+acpi_payload_size = sizeof acpi_dfl_hdr + body_size;
if (acpi_payload_size UINT16_MAX) {
error_setg(errp, ACPI table too big, requested: %zu, max: %u,
@@ -149,13 +158,13 @@ static void acpi_table_install(const char unsigned *blob,
size_t bloblen,
acpi_tables = g_realloc(acpi_tables, acpi_tables_len +
ACPI_TABLE_PFX_SIZE +
- sizeof dfl_hdr + body_size);
+ sizeof acpi_dfl_hdr + body_size);
ext_hdr = (struct acpi_table_header *)(acpi_tables + acpi_tables_len);
acpi_tables_len += ACPI_TABLE_PFX_SIZE;
-memcpy(acpi_tables + acpi_tables_len, hdr_src, sizeof dfl_hdr);
-acpi_tables_len += sizeof dfl_hdr;
+memcpy(acpi_tables + acpi_tables_len, hdr_src, sizeof acpi_dfl_hdr);
+acpi_tables_len += sizeof acpi_dfl_hdr;
if (blob != NULL) {
memcpy(acpi_tables + acpi_tables_len, blob + body_start, body_size);
--
1.7.1
[Qemu-devel] [qemu PATCH 2/5] hw/acpi: extract standard table headers as a standalone structure
This enables reuse when preparing per-table fw_cfg blobs later.
Signed-off-by: Laszlo Ersek ler...@redhat.com
---
hw/acpi.h | 11 +++
hw/acpi.c | 48 +---
2 files changed, 32 insertions(+), 27 deletions(-)
diff --git a/hw/acpi.h b/hw/acpi.h
index e18ef28..d69b6ef 100644
--- a/hw/acpi.h
+++ b/hw/acpi.h
@@ -154,4 +154,15 @@ void acpi_gpe_reset(ACPIREGS *ar);
void acpi_gpe_ioport_writeb(ACPIREGS *ar, uint32_t addr, uint32_t val);
uint32_t acpi_gpe_ioport_readb(ACPIREGS *ar, uint32_t addr);
+typedef struct acpi_table_std_header {
+char sig[4]; /* ACPI signature (4 ASCII characters) */
+uint32_t length; /* Length of table, in bytes, including header */
+uint8_t revision; /* ACPI Specification minor version # */
+uint8_t checksum; /* To make sum of entire table == 0 */
+char oem_id[6]; /* OEM identification */
+char oem_table_id[8]; /* OEM table identification */
+uint32_t oem_revision;/* OEM revision number */
+char asl_compiler_id[4]; /* ASL compiler vendor ID */
+uint32_t asl_compiler_revision; /* ASL compiler revision number */
+} QEMU_PACKED AcpiTableStdHdr;
#endif /* !QEMU_HW_ACPI_H */
diff --git a/hw/acpi.c b/hw/acpi.c
index 856da81..73af4bd 100644
--- a/hw/acpi.c
+++ b/hw/acpi.c
@@ -31,21 +31,13 @@
struct acpi_table_header {
uint16_t _length; /* our length, not actual part of the hdr */
/* allows easier parsing for fw_cfg clients */
-char sig[4]; /* ACPI signature (4 ASCII characters) */
-uint32_t length; /* Length of table, in bytes, including header */
-uint8_t revision; /* ACPI Specification minor version # */
-uint8_t checksum; /* To make sum of entire table == 0 */
-char oem_id[6]; /* OEM identification */
-char oem_table_id[8]; /* OEM table identification */
-uint32_t oem_revision;/* OEM revision number */
-char asl_compiler_id[4]; /* ASL compiler vendor ID */
-uint32_t asl_compiler_revision; /* ASL compiler revision number */
+AcpiTableStdHdr std;
} QEMU_PACKED;
-#define ACPI_TABLE_HDR_SIZE sizeof(struct acpi_table_header)
-#define ACPI_TABLE_PFX_SIZE sizeof(uint16_t) /* size of the extra prefix */
+/* size of the extra prefix */
+#define ACPI_TABLE_PFX_SIZE offsetof(struct acpi_table_header, std)
-static const char unsigned dfl_hdr[ACPI_TABLE_HDR_SIZE - ACPI_TABLE_PFX_SIZE] =
+static const char unsigned dfl_hdr[sizeof(AcpiTableStdHdr)] =
QEMU\0\0\0\0\1\0 /* sig (4), len(4), revno (1), csum (1) */
QEMUQEQEMUQEMU\1\0\0\0 /* OEM id (6), table (8), revno (4) */
QEMU\1\0\0\0 /* ASL compiler ID (4), version (4) */
@@ -105,6 +97,7 @@ static void acpi_table_install(const char unsigned *blob,
size_t bloblen,
size_t body_size, acpi_payload_size;
struct acpi_table_header *ext_hdr;
unsigned changed_fields;
+AcpiTableStdHdr *std;
/* Calculate where the ACPI table body starts within the blob, plus where
* to copy the ACPI table header from.
@@ -177,46 +170,47 @@ static void acpi_table_install(const char unsigned *blob,
size_t bloblen,
changed_fields = 0;
ext_hdr-_length = cpu_to_le16(acpi_payload_size);
+std = ext_hdr-std;
if (hdrs-has_sig) {
-strncpy(ext_hdr-sig, hdrs-sig, sizeof ext_hdr-sig);
+strncpy(std-sig, hdrs-sig, sizeof std-sig);
++changed_fields;
}
-if (has_header le32_to_cpu(ext_hdr-length) != acpi_payload_size) {
+if (has_header le32_to_cpu(std-length) != acpi_payload_size) {
fprintf(stderr,
warning: ACPI table has wrong length, header says
% PRIu32 , actual size %zu bytes\n,
-le32_to_cpu(ext_hdr-length), acpi_payload_size);
+le32_to_cpu(std-length), acpi_payload_size);
}
-ext_hdr-length = cpu_to_le32(acpi_payload_size);
+std-length = cpu_to_le32(acpi_payload_size);
if (hdrs-has_rev) {
-ext_hdr-revision = hdrs-rev;
+std-revision = hdrs-rev;
++changed_fields;
}
-ext_hdr-checksum = 0;
+std-checksum = 0;
if (hdrs-has_oem_id) {
-strncpy(ext_hdr-oem_id, hdrs-oem_id, sizeof ext_hdr-oem_id);
+strncpy(std-oem_id, hdrs-oem_id, sizeof std-oem_id);
++changed_fields;
}
if (hdrs-has_oem_table_id) {
-strncpy(ext_hdr-oem_table_id, hdrs-oem_table_id,
-sizeof ext_hdr-oem_table_id);
+strncpy(std-oem_table_id, hdrs-oem_table_id,
+sizeof std-oem_table_id);
++changed_fields;
}
if (hdrs-has_oem_rev) {
-ext_hdr-oem_revision = cpu_to_le32(hdrs-oem_rev);
+std-oem_revision = cpu_to_le32(hdrs-oem_rev);
++changed_fields;
}
if (hdrs-has_asl_compiler_id) {
-strncpy(ext_hdr-asl_compiler_id, hdrs-asl_compiler_id,
-
[Qemu-devel] [qemu PATCH 4/5] hw/acpi: export acpi_checksum()
Again, this enables reuse when preparing per-table fw_cfg blobs later.
Signed-off-by: Laszlo Ersek ler...@redhat.com
---
hw/acpi.h |2 ++
hw/acpi.c |2 +-
2 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/hw/acpi.h b/hw/acpi.h
index e3e17e9..2c89e59 100644
--- a/hw/acpi.h
+++ b/hw/acpi.h
@@ -167,4 +167,6 @@ typedef struct acpi_table_std_header {
} QEMU_PACKED AcpiTableStdHdr;
extern const AcpiTableStdHdr acpi_dfl_hdr;
+
+int acpi_checksum(const uint8_t *data, int len);
#endif /* !QEMU_HW_ACPI_H */
diff --git a/hw/acpi.c b/hw/acpi.c
index f24be53..07634e1 100644
--- a/hw/acpi.c
+++ b/hw/acpi.c
@@ -69,7 +69,7 @@ static void acpi_register_config(void)
machine_init(acpi_register_config);
-static int acpi_checksum(const uint8_t *data, int len)
+int acpi_checksum(const uint8_t *data, int len)
{
int sum, i;
sum = 0;
--
1.7.1
[Qemu-devel] [qemu PATCH 1/5] refer to FWCfgState explicitly
Soon we'll declare a function in hw/pc.h that takes a
pointer-to-FWCfgState. That would be inconsistent with current usage --
some places use pointer-to-void now even though they mean
pointer-to-FWCfgState. Clean them up.
Signed-off-by: Laszlo Ersek ler...@redhat.com
---
hw/loader.h |3 ++-
hw/multiboot.h |4 +++-
hw/pc.h | 19 ++-
hw/acpi_piix4.c |2 +-
hw/i386/multiboot.c |2 +-
hw/i386/pc.c| 24
hw/i386/pc_piix.c |2 +-
hw/loader.c |2 +-
hw/sparc/sun4m.c|6 +++---
hw/sparc64/sun4u.c |2 +-
10 files changed, 35 insertions(+), 31 deletions(-)
diff --git a/hw/loader.h b/hw/loader.h
index 0958f06..6b8b1e1 100644
--- a/hw/loader.h
+++ b/hw/loader.h
@@ -1,6 +1,7 @@
#ifndef LOADER_H
#define LOADER_H
#include qapi/qmp/qdict.h
+#include hw/fw_cfg.h
/* loader.c */
int get_image_size(const char *filename);
@@ -30,7 +31,7 @@ int rom_add_blob(const char *name, const void *blob, size_t
len,
int rom_add_elf_program(const char *name, void *data, size_t datasize,
size_t romsize, hwaddr addr);
int rom_load_all(void);
-void rom_set_fw(void *f);
+void rom_set_fw(FWCfgState *f);
int rom_copy(uint8_t *dest, hwaddr addr, size_t size);
void *rom_ptr(hwaddr addr);
void do_info_roms(Monitor *mon, const QDict *qdict);
diff --git a/hw/multiboot.h b/hw/multiboot.h
index 98fb1b7..25589e3 100644
--- a/hw/multiboot.h
+++ b/hw/multiboot.h
@@ -1,7 +1,9 @@
#ifndef QEMU_MULTIBOOT_H
#define QEMU_MULTIBOOT_H
-int load_multiboot(void *fw_cfg,
+#include hw/fw_cfg.h
+
+int load_multiboot(FWCfgState *fw_cfg,
FILE *f,
const char *kernel_filename,
const char *initrd_filename,
diff --git a/hw/pc.h b/hw/pc.h
index 55964ce..5e5dd3d 100644
--- a/hw/pc.h
+++ b/hw/pc.h
@@ -9,6 +9,7 @@
#include net/net.h
#include exec/memory.h
#include hw/ioapic.h
+#include hw/fw_cfg.h
/* PC-style peripherals (also used by other machines). */
@@ -80,14 +81,14 @@ void pc_acpi_smi_interrupt(void *opaque, int irq, int
level);
void pc_cpus_init(const char *cpu_model);
void pc_acpi_init(const char *default_dsdt);
-void *pc_memory_init(MemoryRegion *system_memory,
-const char *kernel_filename,
-const char *kernel_cmdline,
-const char *initrd_filename,
-ram_addr_t below_4g_mem_size,
-ram_addr_t above_4g_mem_size,
-MemoryRegion *rom_memory,
-MemoryRegion **ram_memory);
+FWCfgState *pc_memory_init(MemoryRegion *system_memory,
+ const char *kernel_filename,
+ const char *kernel_cmdline,
+ const char *initrd_filename,
+ ram_addr_t below_4g_mem_size,
+ ram_addr_t above_4g_mem_size,
+ MemoryRegion *rom_memory,
+ MemoryRegion **ram_memory);
qemu_irq *pc_allocate_cpu_irq(void);
DeviceState *pc_vga_init(ISABus *isa_bus, PCIBus *pci_bus);
void pc_basic_device_init(ISABus *isa_bus, qemu_irq *gsi,
@@ -119,7 +120,7 @@ void acpi_table_add(const QemuOpts *opts, Error **errp);
i2c_bus *piix4_pm_init(PCIBus *bus, int devfn, uint32_t smb_io_base,
qemu_irq sci_irq, qemu_irq smi_irq,
- int kvm_enabled, void *fw_cfg);
+ int kvm_enabled, FWCfgState *fw_cfg);
void piix4_smbus_register_device(SMBusDevice *dev, uint8_t addr);
/* hpet.c */
diff --git a/hw/acpi_piix4.c b/hw/acpi_piix4.c
index 48a32b5..e168d0d 100644
--- a/hw/acpi_piix4.c
+++ b/hw/acpi_piix4.c
@@ -435,7 +435,7 @@ static int piix4_pm_initfn(PCIDevice *dev)
i2c_bus *piix4_pm_init(PCIBus *bus, int devfn, uint32_t smb_io_base,
qemu_irq sci_irq, qemu_irq smi_irq,
- int kvm_enabled, void *fw_cfg)
+ int kvm_enabled, FWCfgState *fw_cfg)
{
PCIDevice *dev;
PIIX4PMState *s;
diff --git a/hw/i386/multiboot.c b/hw/i386/multiboot.c
index 3cb228f..b4ce1fc 100644
--- a/hw/i386/multiboot.c
+++ b/hw/i386/multiboot.c
@@ -124,7 +124,7 @@ static void mb_add_mod(MultibootState *s,
s-mb_mods_count++;
}
-int load_multiboot(void *fw_cfg,
+int load_multiboot(FWCfgState *fw_cfg,
FILE *f,
const char *kernel_filename,
const char *initrd_filename,
diff --git a/hw/i386/pc.c b/hw/i386/pc.c
index ebbf059..e7c88c4 100644
--- a/hw/i386/pc.c
+++ b/hw/i386/pc.c
@@ -568,9 +568,9 @@ static unsigned int pc_apic_id_limit(unsigned int max_cpus)
return x86_cpu_apic_id_from_index(max_cpus - 1) + 1;
}
-static void *bochs_bios_init(void)
+static FWCfgState *bochs_bios_init(void)
{
-void *fw_cfg;
+FWCfgState *fw_cfg;
uint8_t *smbios_table;
size_t smbios_len;
uint64_t
[Qemu-devel] [qemu PATCH 0/5] publish etc/acpi/APIC in fw_cfg
This series exports the MADT (APIC) ACPI table under the new
etc/acpi/APIC fw_cfg file. I sought to follow the requirements set
forth in [1], the new table is only visible in the patched/patched case.
I cross-tested { master, patched } qemu with { master, patched } seabios
(the APIC, DSDT and RSDT tables) using guest acpidump and dmesg.
The -acpitable command line option is purposely ignored based on the
last paragraph of [2]; the user isn't supposed to pass APIC with that
option.
checkpatch.pl complains a little but (as last time) it's a false alarm.
The series is bisectable.
[1] http://thread.gmane.org/gmane.comp.emulators.qemu/202005/focus=202072
[2] http://thread.gmane.org/gmane.comp.bios.coreboot.seabios/5960/focus=6008
Laszlo Ersek (5):
refer to FWCfgState explicitly
hw/acpi: extract standard table headers as a standalone structure
hw/acpi: export default ACPI headers using the type just introduced
hw/acpi: export acpi_checksum()
i386/pc: build ACPI MADT (APIC) for fw_cfg clients
hw/acpi.h | 15 +
hw/loader.h |3 +-
hw/multiboot.h |4 +-
hw/pc.h | 20 ---
hw/acpi.c | 89 ++-
hw/acpi_piix4.c |2 +-
hw/i386/multiboot.c |2 +-
hw/i386/pc.c| 166 +++
hw/i386/pc_piix.c |4 +-
hw/i386/pc_q35.c| 10 ++-
hw/loader.c |2 +-
hw/sparc/sun4m.c|6 +-
hw/sparc64/sun4u.c |2 +-
13 files changed, 248 insertions(+), 77 deletions(-)
Re: [Qemu-devel] [PATCH V11 09/17] qmp: add interface query-snapshots
On Tue, Apr 02, 2013 at 07:47:22PM +0800, Wenchao Xia wrote: diff --git a/qmp-commands.hx b/qmp-commands.hx index 1e0e11e..6b20684 100644 --- a/qmp-commands.hx +++ b/qmp-commands.hx @@ -1765,6 +1765,61 @@ EQMP }, SQMP +query-snapshots +--- + +Show the internal consistent snapshot information + +Each snapshot is represented by a json-object. The returned value +is a json-array of all snapshots I think the consistent snapshot term is not defined. Please add something like: Consistent snapshots are snapshots that exist in all writeable block devices. When 'savevm' takes a snapshot it uses the same ID across all writeable block devices. If a snapshot ID only exists in one block device then it is not a consistent snapshot. Stefan
Re: [Qemu-devel] [PATCH V11 11/17] qmp: add ImageInfo in BlockDeviceInfo used by query-block
On Tue, Apr 02, 2013 at 07:47:24PM +0800, Wenchao Xia wrote: diff --git a/qmp-commands.hx b/qmp-commands.hx index 6b20684..b856be7 100644 --- a/qmp-commands.hx +++ b/qmp-commands.hx @@ -1703,6 +1703,47 @@ Each json-object contain the following: - iops: limit total I/O operations per second (json-int) - iops_rd: limit read operations per second (json-int) - iops_wr: limit write operations per second (json-int) + - image: the detail of the image, it is a json-object containing +the following: + - filename: image file name (json-string) + - format: image format (json-string) + - virtual-size: image capacity in bytes (json-int) + - dirty-flag: true if image is not cleanly closed, not present + means clean (json-bool, optional) + - actual-size: actual size on disk in bytes of the image, not + present when image does not support thin + provision (json-int, optional) + - cluster-size: size of a cluster in bytes, not present if image + format does not support it (json-int, optional) + - encrypted: true if the image is encrypted, not present means +false or the image format does not support +encryption (json-bool, optional) + - backing_file: backing file name, not present means no backing + file is used or the image format does not + support backing file chain + (json-string, optional) + - full-backing-filename: full path of the backing file, not +present if it equals backing_file or no +backing file is used +(json-string, optional) + - backing-filename-format: the format of the backing file, not + present means unknown or no backing + file (json-string, optional) + - snapshots: the internal snapshot info, it is an optional list +of json-object containing the following: + - id: unique snapshot id (json-string) + - name: snapshot name (json-string) + - vm-state-size: size of the VM state in bytes (json-int) + - date-sec: UTC date of the snapshot in seconds (json-int) + - date-nsec: fractional part in nanoseconds to be used with +date-sec(json-int) + - vm-clock-sec: VM clock relative to boot in seconds + (json-int) + - vm-clock-nsec: fractional part in nanoseconds to be used +with vm-clock-sec (json-int) + - backing-image: the detail of the backing image, it is an +optional json-object only present when a +backing image present for this image Please don't duplicate the ImageInfo documentation from qapi-schema.json. I'm not sure how the documentation gets generated but we need to avoid this, otherwise it will quickly get out of sync. Stefan
Re: [Qemu-devel] [PATCH V11 13/17] block: dump to buffer for bdrv_snapshot_dump() and bdrv_image_info_dump()
On Tue, Apr 02, 2013 at 07:47:26PM +0800, Wenchao Xia wrote:
diff --git a/qemu-img.c b/qemu-img.c
index 5b229a9..032f68c 100644
--- a/qemu-img.c
+++ b/qemu-img.c
@@ -1558,18 +1558,24 @@ static void dump_snapshots(BlockDriverState *bs)
{
QEMUSnapshotInfo *sn_tab, *sn;
int nb_sns, i;
-char buf[256];
+GString *buf = g_string_new(NULL);
nb_sns = bdrv_snapshot_list(bs, sn_tab);
if (nb_sns = 0)
return;
Leaks buf.
diff --git a/savevm.c b/savevm.c
index e4e0008..ce0bbe1 100644
--- a/savevm.c
+++ b/savevm.c
@@ -2466,7 +2466,7 @@ void do_info_snapshots(Monitor *mon, const QDict *qdict)
int nb_sns, i, ret, available;
int total;
int *available_snapshots;
-char buf[256];
+GString *buf = NULL;
bs = bdrv_snapshots();
if (!bs) {
@@ -2509,11 +2509,16 @@ void do_info_snapshots(Monitor *mon, const QDict
*qdict)
}
if (total 0) {
Please declare buf here since it is only used in this scope.
[Qemu-devel] [seabios PATCH] install the MADT from the etc/acpi/APIC fw_cfg file if it's available
Signed-off-by: Laszlo Ersek ler...@redhat.com
---
src/acpi.c | 29 -
1 files changed, 28 insertions(+), 1 deletions(-)
diff --git a/src/acpi.c b/src/acpi.c
index bc4d8ea..9e128b2 100644
--- a/src/acpi.c
+++ b/src/acpi.c
@@ -393,6 +393,33 @@ build_madt(void)
return madt;
}
+static void*
+find_table(const char *sig, void *(*buildfn)(void))
+{
+char buf[] = etc/acpi/QUUX;
+struct romfile_s *file;
+
+snprintf(buf + (sizeof buf - 1 - 4), 4 + 1, %s, sig);
+file = romfile_find(buf);
+if (file != NULL file-size = sizeof(struct acpi_table_header)) {
+void *table;
+
+table = malloc_high(file-size);
+if (table == NULL)
+warn_noalloc();
+else {
+if ((*file-copy)(file, table, file-size) == file-size) {
+dprintf(4, ACPI %s: using fw_cfg %s\n, sig, buf);
+return table;
+}
+free(table);
+}
+}
+
+dprintf(4, ACPI %s: building default\n, sig);
+return (*buildfn)();
+}
+
// Encode a hex value
static inline char getHex(u32 val) {
val = 0x0f;
@@ -792,7 +819,7 @@ acpi_setup(void)
struct fadt_descriptor_rev1 *fadt = build_fadt(pci);
ACPI_INIT_TABLE(fadt);
ACPI_INIT_TABLE(build_ssdt());
-ACPI_INIT_TABLE(build_madt());
+ACPI_INIT_TABLE(find_table(APIC, build_madt));
ACPI_INIT_TABLE(build_hpet());
ACPI_INIT_TABLE(build_srat());
if (pci-device == PCI_DEVICE_ID_INTEL_ICH9_LPC)
--
1.7.1
Re: [Qemu-devel] After executing savevm, the QEMU process is hanging
Hi, Stefan Thanks for your reply. I have test the latest version of qemu.git/master(commit:9196dd411d580c27f85daa209ff9a501d719ebc0,2013-04-06). But, this problem still exists. This problem appears after the commit(500f0061d628b52220038939728f0d7aee634468, Use qemu_put_buffer_async for guest memory pages). But I'm not sure why this commit cause this problem. I simplified the qemu-kvm command to the below: qemu-system-x86_64 --enable-kvm -m 1024 -smp 2 -boot c -drive file=/home/test/winxp.qcow2, if=virtio,index=0,format=qcow2 -monitor stdio -vnc 186.100.8.131:1 Best Regards, Jeremy Liu Re: [Qemu-devel] After executing savevm, the QEMU process is hanging On Mon, Apr 01, 2013 at 11:45:13AM +, Liuji (Jeremy) wrote: Hello, everyone After executing the savevm command, the QEMU process is hanging. But in the v1.4.0, it's no problem. Host OS: Fedora 17 x86_64 Qemu: the latest(2013-04-01) Quest OS: WinXP 1) Use the following command to start the VM: qemu-kvm -enable-kvm -name winxp -M pc-0.15 -m 1024 -smp 2 -boot c -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x5 -drive file=/home/test/winxp.qcow2,if=virtio,index=0,format=qcow2 -net nic,model=virtio,macaddr=52:54:00:05:11:12 -monitor stdio -chardev spicevmc,id=charchannel0,name=vdagent -device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,na me=com.redhat.spice.0 -chardev pty,id=charchannel1 -device virtserialport,bus=virtio-serial0.0,nr=2,chardev=charchannel1,id=channel1,na me=arbitrary.virtio.serial.port.name -device usb-tablet,id=input0 -spice port=3001,addr=186.100.8.131,disable-ticketing,plaintext-channel=main,plaint ext-channel=playback,plaintext-channel=record,image-compression=auto_glz -vga qxl -global qxl-vga.vram_size=67108864 -device AC97,id=sound0,bus=pci.0,addr=0x4 2) Execute the savevm command in the qemu monitor. After a long time (20minute), the qemu process is still hanging. Who can give me some advice? Have you tried qemu.git/master? Once you find out which version works and which is broken, you can use git-bisect(1) to find the commit that broke savevm. Stefan
Re: [Qemu-devel] [PATCH V11 00/17] qmp/hmp interfaces for internal snapshot info
On Tue, Apr 02, 2013 at 07:47:13PM +0800, Wenchao Xia wrote: In the use of snapshot a way to retrieve related info at runtime is needed, so this serial of patches will merge some code for qemu and qemu-img, and add or enchance following interfaces for qemu: Looks pretty good, I commented on a few small things. Stefan
Re: [Qemu-devel] [PATCH uq/master v2 1/2] kvm: reset state from the CPU's reset method
Il 08/04/2013 14:19, Gleb Natapov ha scritto:
Does this compile with kvm support disabled?
Oops, sorry, I thought I had replied to this email (with hmm, let me
check).
Well, it does not:
CCs390x-softmmu/target-s390x/cpu.o
/users/gleb/work/qemu/target-s390x/cpu.c: In function 's390_cpu_reset':
/users/gleb/work/qemu/target-s390x/cpu.c:89:9: error: implicit
declaration of function 'kvm_arch_reset_vcpu'
[-Werror=implicit-function-declaration]
/users/gleb/work/qemu/target-s390x/cpu.c:89:9: error: nested extern
declaration of 'kvm_arch_reset_vcpu' [-Werror=nested-externs]
cc1: all warnings being treated as errors
I wonder if it is portable between compilers to rely on code in if(0){} to
be dropped in all levels of optimizations.
It generally is okay to assume it (I think early GCC 3.x releases had no
-O0 dead-code optimization, but it was a long time ago). However:
* in QEMU only some files have kvm_enabled() as 0 when KVM is disabled.
Files that are shared among multiple targets have it defined to
kvm_allowed. This is not the problem here.
* you still need to define the prototypes for anything you call, of course.
Paolo
[Qemu-devel] KVM call agenda for 2013-04-09
Hi Please send in any agenda topics you are interested in. Later, Juan.
[Qemu-devel] [PATCH] ehci_free_packet: Discard finished packets when the queue is halted
With pipelining it is possible to encounter a finished packet when cleaning
the queue due to a halt. This happens when a non stall error happens while
talking to a real device. In this case the queue on the usb-host side will
continue processing packets, and we can have completed packets waiting in
the queue after an error condition packet causing a halt.
There are 2 reasons to discard the completed packets at this point, rather
then trying to writing them back to the guest:
1) The guest expect to be able to cancel and/or change packets after the
packet with the error without doing an unlink, so writing them back may
confuse the guest.
2) Since the queue does not advance when halted, the writing back of these
packets will fail anyways since p-qtdaddr != q-qtdaddr, so the
ehci_verify_qtd call in ehci_writeback_async_complete_packet will fail.
Note that 2) means that then only functional change this patch introduces
is the printing of a warning when this scenario happens.
Note that discarding these packets means that the guest driver and the device
will get out of sync! This is unfortunate, but should not be a problem since
with a non stall error (iow an io-error) the 2 are out of sync already anyways.
Still this patch adds a warning to signal this happening.
Note that sofar this has only been seen with a DVB-T receiver, which gives
of a MPEG-2 stream, which allows for recovering from lost packets, see:
https://bugzilla.redhat.com/show_bug.cgi?id=890320
Signed-off-by: Hans de Goede hdego...@redhat.com
---
hw/usb/hcd-ehci.c | 16 +++-
1 file changed, 11 insertions(+), 5 deletions(-)
diff --git a/hw/usb/hcd-ehci.c b/hw/usb/hcd-ehci.c
index 5176251..626a4c5 100644
--- a/hw/usb/hcd-ehci.c
+++ b/hw/usb/hcd-ehci.c
@@ -586,17 +586,23 @@ static EHCIPacket *ehci_alloc_packet(EHCIQueue *q)
static void ehci_free_packet(EHCIPacket *p)
{
-if (p-async == EHCI_ASYNC_FINISHED) {
+if (p-async == EHCI_ASYNC_FINISHED
+!(p-queue-qh.token QTD_TOKEN_HALT)) {
ehci_writeback_async_complete_packet(p);
return;
}
trace_usb_ehci_packet_action(p-queue, p, free);
-if (p-async == EHCI_ASYNC_INITIALIZED) {
-usb_packet_unmap(p-packet, p-sgl);
-qemu_sglist_destroy(p-sgl);
-}
if (p-async == EHCI_ASYNC_INFLIGHT) {
usb_cancel_packet(p-packet);
+}
+if (p-async == EHCI_ASYNC_FINISHED) {
+fprintf(stderr,
+EHCI: Dropping completed packet from halted %s ep %02X\n,
+(p-pid == USB_TOKEN_IN) ? in : out,
+get_field(p-queue-qh.epchar, QH_EPCHAR_EP));
+
+}
+if (p-async != EHCI_ASYNC_NONE) {
usb_packet_unmap(p-packet, p-sgl);
qemu_sglist_destroy(p-sgl);
}
--
1.8.2
[Qemu-devel] [qemu PATCH 5/5] i386/pc: build ACPI MADT (APIC) for fw_cfg clients
The set of per-table fw_cfg files is installed with the new function
pc_acpi_fw_cfg_init().
This function is called at the end of pc_init1() and pc_q35_init():
pc_init1() or pc_q35_init()
pc_acpi_init() very early
/* bunch of setup code */
pc_acpi_fw_cfg_init() added now
rather than from within pc_acpi_init() for two reasons:
(1) In general, calculation of ACPI tables could logically depend on
machine data set up by pc_init1() / pc_q35_init() *after* their respective
calls to pc_acpi_init().
(2) pc_acpi_fw_cfg_init() obviously depends on the FWCfgState object,
which is not available when pc_acpi_init() is called:
pc_init1() and pc_q35_init()
pc_acpi_init()
...
pc_memory_init()
bochs_bios_init()
fw_cfg_init() FWCfgState object set up here
sysbus_mmio_map()
fw_cfg_add_bytes(..., acpi_tables, ...);
...
pc_acpi_fw_cfg_init() added now, depends on FWCfgState
The following movements have been considered and rejected:
(2a) Pushing pc_acpi_init() below pc_memory_init(), and sinking the call
to the new function pc_acpi_fw_cfg_init() into pc_acpi_init():
pc_init1() and pc_q35_init()
...
pc_memory_init()
bochs_bios_init()
fw_cfg_init()
sysbus_mmio_map()
fw_cfg_add_bytes(..., acpi_tables, ...);
...
pc_acpi_init() ordered after rest of setup code
pc_acpi_fw_cfg_init() added now
Unfortunately, acpi_tables is modified by pc_acpi_init(), hence this
move would violate a data dependency in pc_memory_init().
(2b) Alternatively, based on (2), hoisting the fw_cfg_init() call to just
before pc_acpi_init(), and again sinking the call to the new function
pc_acpi_fw_cfg_init() into pc_acpi_init():
pc_init1() and pc_q35_init()
fw_cfg_init() pulled up from bochs_bios_init()
sysbus_mmio_map()
pc_acpi_init()
pc_acpi_fw_cfg_init() added now
...
pc_memory_init()
bochs_bios_init()
fw_cfg_add_bytes(..., acpi_tables, ...);
Alas, sysbus_mmio_map() in fw_cfg_init() depends on the memory layout
prepared by pc_memory_init().
Ultimately we have the following dependencies:
- pc_acpi_fw_cfg_init() depends on fw_cfg_init() [2],
- fw_cfg_init() depends on pc_memory_init() [2b],
- pc_memory_init() depends on pc_acpi_init() [2a]
This yields the total ordering visible in the patch.
Signed-off-by: Laszlo Ersek ler...@redhat.com
---
hw/pc.h |1 +
hw/i386/pc.c | 142 +
hw/i386/pc_piix.c |2 +
hw/i386/pc_q35.c | 10 +++-
4 files changed, 152 insertions(+), 3 deletions(-)
diff --git a/hw/pc.h b/hw/pc.h
index 5e5dd3d..0718d8f 100644
--- a/hw/pc.h
+++ b/hw/pc.h
@@ -107,6 +107,7 @@ typedef void (*cpu_set_smm_t)(int smm, void *arg);
void cpu_smm_register(cpu_set_smm_t callback, void *arg);
void ioapic_init_gsi(GSIState *gsi_state, const char *parent_name);
+void pc_acpi_fw_cfg_init(FWCfgState *fw_cfg);
/* acpi.c */
extern int acpi_enabled;
diff --git a/hw/i386/pc.c b/hw/i386/pc.c
index e7c88c4..7dd9c60 100644
--- a/hw/i386/pc.c
+++ b/hw/i386/pc.c
@@ -52,6 +52,7 @@
#include sysemu/arch_init.h
#include qemu/bitmap.h
#include qemu/config-file.h
+#include hw/acpi.h
/* debug PC/ISA interrupts */
//#define DEBUG_IRQ
@@ -1178,3 +1179,144 @@ void ioapic_init_gsi(GSIState *gsi_state, const char
*parent_name)
gsi_state-ioapic_irq[i] = qdev_get_gpio_in(dev, i);
}
}
+
+static void pc_acpi_install(FWCfgState *fw_cfg, AcpiTableStdHdr *std_hdr,
+size_t blob_size, const char *sig)
+{
+char *pathname;
+
+g_assert(blob_size = sizeof *std_hdr);
+
+*std_hdr = acpi_dfl_hdr;
+strncpy(std_hdr-sig, sig, sizeof std_hdr-sig);
+strncpy(std_hdr-oem_id, QEMU , sizeof std_hdr-oem_id);
+strncpy(std_hdr-oem_table_id + 4, sig, sizeof std_hdr-oem_table_id - 4);
+std_hdr-length = cpu_to_le32(blob_size);
+std_hdr-checksum = acpi_checksum((uint8_t *)std_hdr, blob_size);
+
+pathname = g_strdup_printf(etc/acpi/%s, sig);
+fw_cfg_add_file(fw_cfg, pathname, std_hdr, blob_size);
+g_free(pathname);
+}
+
+static void pc_acpi_madt(FWCfgState *fw_cfg)
+{
+typedef struct {
+uint8_ttype;
+uint8_tlength;
+} QEMU_PACKED AcpiSubHdr;
+
+AcpiTableStdHdr *std_hdr;
+struct {
+uint32_t lapic_addr; /* Local Interrupt Controller Address */
+uint32_t flags; /* Multiple APIC flags */
+} QEMU_PACKED *madt;
+struct {
+AcpiSubHdr hdr;
+uint8_tprocessor_id; /* ACPI Processor ID */
+uint8_tapic_id; /* APIC ID */
+uint32_t flags;/* LOcal APIC flags */
+} QEMU_PACKED *lapic;
+struct {
+AcpiSubHdr hdr;
+uint8_tio_apic_id; /* The I/O APIC's ID */
+uint8_treserved; /* constant zero */
+
Re: [Qemu-devel] [PATCH] qemu-char: really fix behavior on can_read = 0
Paolo Bonzini pbonz...@redhat.com writes:
I misread the glib manual, g_source_remove does not let you re-attach
the source later. This behavior (called blocking the source in glib)
is present in glib's source code, but private and not available outside
glib; hence, we have to resort to re-creating the source every time.
In fact, g_source_remove and g_source_destroy are the same thing,
except g_source_destroy is O(1) while g_source_remove scans a potentially
very long list of GSources in the current main loop. Ugh. Better
use g_source_destroy explicitly, and leave tags to those dummies who
cannot track their pointers' lifetimes.
Signed-off-by: Paolo Bonzini pbonz...@redhat.com
Tested-by: Anthony Liguori aligu...@us.ibm.com
Regards,
Anthony Liguori
---
qemu-char.c | 17 +
1 file changed, 13 insertions(+), 4 deletions(-)
diff --git a/qemu-char.c b/qemu-char.c
index dd410ce..eae17fc 100644
--- a/qemu-char.c
+++ b/qemu-char.c
@@ -596,9 +596,11 @@ typedef struct IOWatchPoll
{
GSource parent;
+GIOChannel *channel;
GSource *src;
IOCanReadHandler *fd_can_read;
+GSourceFunc fd_read;
void *opaque;
} IOWatchPoll;
@@ -611,15 +613,19 @@ static gboolean io_watch_poll_prepare(GSource *source,
gint *timeout_)
{
IOWatchPoll *iwp = io_watch_poll_from_source(source);
bool now_active = iwp-fd_can_read(iwp-opaque) 0;
-bool was_active = g_source_get_context(iwp-src) != NULL;
+bool was_active = iwp-src != NULL;
if (was_active == now_active) {
return FALSE;
}
if (now_active) {
+iwp-src = g_io_create_watch(iwp-channel, G_IO_IN | G_IO_ERR |
G_IO_HUP);
+g_source_set_callback(iwp-src, iwp-fd_read, iwp-opaque, NULL);
g_source_attach(iwp-src, NULL);
} else {
-g_source_remove(g_source_get_id(iwp-src));
+g_source_destroy(iwp-src);
+g_source_unref(iwp-src);
+iwp-src = NULL;
}
return FALSE;
}
@@ -638,7 +644,9 @@ static gboolean io_watch_poll_dispatch(GSource *source,
GSourceFunc callback,
static void io_watch_poll_finalize(GSource *source)
{
IOWatchPoll *iwp = io_watch_poll_from_source(source);
+g_source_destroy(iwp-src);
g_source_unref(iwp-src);
+iwp-src = NULL;
}
static GSourceFuncs io_watch_poll_funcs = {
@@ -659,8 +667,9 @@ static guint io_add_watch_poll(GIOChannel *channel,
iwp = (IOWatchPoll *) g_source_new(io_watch_poll_funcs,
sizeof(IOWatchPoll));
iwp-fd_can_read = fd_can_read;
iwp-opaque = user_data;
-iwp-src = g_io_create_watch(channel, G_IO_IN | G_IO_ERR | G_IO_HUP);
-g_source_set_callback(iwp-src, (GSourceFunc)fd_read, user_data, NULL);
+iwp-channel = channel;
+iwp-fd_read = (GSourceFunc) fd_read;
+iwp-src = NULL;
return g_source_attach(iwp-parent, NULL);
}
--
1.8.1.4
Re: [Qemu-devel] [PATCH] New cpu-max field in query-machines QMP command output
On Mon, 8 Apr 2013 12:00:35 +0200
Michal Novotny minov...@redhat.com wrote:
This alters the query-machines QMP command to output information
about maximum number of CPUs for each machine type with default
value 1 in case the number of max_cpus is not set.
Signed-off-by: Michal Novotny minov...@redhat.com
---
qapi-schema.json | 2 +-
vl.c | 1 +
2 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/qapi-schema.json b/qapi-schema.json
index db542f6..39cae4b 100644
--- a/qapi-schema.json
+++ b/qapi-schema.json
@@ -2865,7 +2865,7 @@
##
{ 'type': 'MachineInfo',
'data': { 'name': 'str', '*alias': 'str',
-'*is-default': 'bool' } }
+'*is-default': 'bool', 'cpu-max': 'int' } }
Please, document the new field.
Also, how is this affected by the CPU hotplug support?
##
# @query-machines:
diff --git a/vl.c b/vl.c
index a8bba04..c05b3d3 100644
--- a/vl.c
+++ b/vl.c
@@ -1617,6 +1617,7 @@ MachineInfoList *qmp_query_machines(Error **errp)
}
info-name = g_strdup(m-name);
+info-cpu_max = !m-max_cpus ? 1 : m-max_cpus;
entry = g_malloc0(sizeof(*entry));
entry-value = info;
Re: [Qemu-devel] [PATCH] qemu-char: really fix behavior on can_read = 0
Paolo Bonzini pbonz...@redhat.com writes: I misread the glib manual, g_source_remove does not let you re-attach the source later. This behavior (called blocking the source in glib) is present in glib's source code, but private and not available outside glib; Hmm, have you filed a bug upstream asking them to make this available outside of glib? Would be useful to have... Regards, hans
Re: [Qemu-devel] After executing savevm, the QEMU process is hanging
Hi, Paolo send a patch series today fixing a problem with savevm http://www.mail-archive.com/qemu-devel@nongnu.org/msg165135.html Can you check if it solves the issue? Regards, Orit On 04/08/2013 04:39 PM, Liuji (Jeremy) wrote: Hi, Stefan Thanks for your reply. I have test the latest version of qemu.git/master(commit:9196dd411d580c27f85daa209ff9a501d719ebc0,2013-04-06). But, this problem still exists. This problem appears after the commit(500f0061d628b52220038939728f0d7aee634468, Use qemu_put_buffer_async for guest memory pages). But I'm not sure why this commit cause this problem. I simplified the qemu-kvm command to the below: qemu-system-x86_64 --enable-kvm -m 1024 -smp 2 -boot c -drive file=/home/test/winxp.qcow2, if=virtio,index=0,format=qcow2 -monitor stdio -vnc 186.100.8.131:1 Best Regards, Jeremy Liu Re: [Qemu-devel] After executing savevm, the QEMU process is hanging On Mon, Apr 01, 2013 at 11:45:13AM +, Liuji (Jeremy) wrote: Hello, everyone After executing the savevm command, the QEMU process is hanging. But in the v1.4.0, it's no problem. Host OS: Fedora 17 x86_64 Qemu: the latest(2013-04-01) Quest OS: WinXP 1) Use the following command to start the VM: qemu-kvm -enable-kvm -name winxp -M pc-0.15 -m 1024 -smp 2 -boot c -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x5 -drive file=/home/test/winxp.qcow2,if=virtio,index=0,format=qcow2 -net nic,model=virtio,macaddr=52:54:00:05:11:12 -monitor stdio -chardev spicevmc,id=charchannel0,name=vdagent -device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,na me=com.redhat.spice.0 -chardev pty,id=charchannel1 -device virtserialport,bus=virtio-serial0.0,nr=2,chardev=charchannel1,id=channel1,na me=arbitrary.virtio.serial.port.name -device usb-tablet,id=input0 -spice port=3001,addr=186.100.8.131,disable-ticketing,plaintext-channel=main,plaint ext-channel=playback,plaintext-channel=record,image-compression=auto_glz -vga qxl -global qxl-vga.vram_size=67108864 -device AC97,id=sound0,bus=pci.0,addr=0x4 2) Execute the savevm command in the qemu monitor. After a long time (20minute), the qemu process is still hanging. Who can give me some advice? Have you tried qemu.git/master? Once you find out which version works and which is broken, you can use git-bisect(1) to find the commit that broke savevm. Stefan
Re: [Qemu-devel] [PATCH] qemu-char: really fix behavior on can_read = 0
Il 08/04/2013 16:08, Hans de Goede ha scritto: I misread the glib manual, g_source_remove does not let you re-attach the source later. This behavior (called blocking the source in glib) is present in glib's source code, but private and not available outside glib; Hmm, have you filed a bug upstream asking them to make this available outside of glib? Would be useful to have... No, I never had much success asking for new glib APIs. Paolo
Re: [Qemu-devel] [PATCH 1/2] trace: Add ftrace tracing backend
On Wed, Apr 03, 2013 at 03:30:58PM +0900, Eiichi Tsukata wrote:
diff --git a/scripts/tracetool/backend/ftrace.py
b/scripts/tracetool/backend/ftrace.py
new file mode 100644
index 000..e02f0ca
--- /dev/null
+++ b/scripts/tracetool/backend/ftrace.py
@@ -0,0 +1,53 @@
+#!/usr/bin/env python
+# -*- coding: utf-8 -*-
+
+
+Ftrace built-in backend.
+
+
+__author__ = Eiichi Tsukata eiichi.tsukata...@hitachi.com
+__copyright__ = Copyright (C) 2013 Hitachi, Ltd.
+__license__= GPL version 2 or (at your option) any later version
+
+__maintainer__ = Stefan Hajnoczi
+__email__ = stefa...@linux.vnet.ibm.com
My email is now stefa...@redhat.com. I can fix this up when merging the
patch.
+out('static inline void trace_%(name)s(%(args)s)',
+'{',
+'char ftrace_buf[MAX_TRACE_STRLEN];',
+'int unused __attribute__ ((unused));'
+'bool _state = trace_event_get_state(%(event_id)s);',
+'if (_state) {',
+'snprintf(ftrace_buf, MAX_TRACE_STRLEN,',
+' %(name)s %(fmt)s \\n %(argnames)s);',
+'unused = write(trace_marker_fd, ftrace_buf,',
+' MAX_TRACE_STRLEN);',
Looking at kernel/trace/trace.c:tracing_mark_write() the kernel will
memcpy() the full number of bytes we give.
You could use the snprintf(3) return value (number of characters
written, excluding NUL byte).
I think that would waste less trace buffer space.
Stefan
Re: [Qemu-devel] [PATCH 0/2] New trace backend: ftrace
On Wed, Apr 03, 2013 at 03:30:57PM +0900, Eiichi Tsukata wrote: This patchset introduces a new tracing backend ftrace. Currently, QEMU tracing backends do not support userspace tracing with ftrace. Collecting QEMU trace data and kernel trace data simultaniouly is useful for latency analysis and debugging especially when using KVM. With ftrace backend, you can easily collect QEMU-kernel merged trace data using existing ftrace event-based tracer. If you use KVM, you can effectively compare VM_EXIT and QEMU userspace handler. To try it out, compile QEMU with tracing backend ftrace, then enable KVM events in ftrace: # echo 1 /sys/kernel/debug/tracing/events/kvm/enable After running qemu by root user, you can get the trace: # cat /sys/kernel/debug/tracing/trace Example: # tracer: nop # # entries-in-buffer/entries-written: 8434/345512 #P:4 # # _-= irqs-off # / _= need-resched #| / _---= hardirq/softirq #|| / _--= preempt-depth #||| / delay # TASK-PID CPU# TIMESTAMP FUNCTION # | | | | | snip qemu-system-x86-31930 [000] d... 23580.595951: kvm_exit: reason IO_INSTRUCTION rip 0xc45d info 710048 0 qemu-system-x86-31930 [000] 23580.595954: kvm_emulate_insn: f:c45d:e4 71 (real) qemu-system-x86-31930 [000] 23580.595955: kvm_pio: pio_read at 0x71 size 1 count 1 qemu-system-x86-31930 [000] 23580.595956: kvm_userspace_exit: reason KVM_EXIT_IO (2) qemu-system-x86-31930 [000] ...1 23580.595959: tracing_mark_write: cpu_set_apic_base fee00900 qemu-system-x86-31930 [000] ...1 23580.595961: tracing_mark_write: cpu_in addr 0x71 value 0 qemu-system-x86-31930 [000] d... 23580.595964: kvm_entry: vcpu 0 snip tracing_mark_write: cpu_set_apic_base fee00900 and tracing_mark_write: cpu_in addr 0x71 value 0 are QEMU trace data. Others are Kernel trace data. Furthermore, the ftrace backend overhead is smaller than uprobe-based event tracer or SystemTap. My microbenchmark shows that ftrace tracing backend overhead is about 0.8us per tracepoint, whereas uprobe-based event tracer or SystemTap overhead is about 2.0us. Eiichi Tsukata (2): trace: Add ftrace tracing backend trace: document frace backend configure | 8 +++ docs/tracing.txt| 16 ++ scripts/tracetool/backend/ftrace.py | 53 +++ trace/Makefile.objs | 1 + trace/ftrace.c | 102 trace/ftrace.h | 10 6 files changed, 190 insertions(+) create mode 100644 scripts/tracetool/backend/ftrace.py create mode 100644 trace/ftrace.c create mode 100644 trace/ftrace.h Looks nice. I posted two comments. Stefan
Re: [Qemu-devel] [PATCH] New cpu-max field in query-machines QMP command output
Just for clarification why I did this: Some of the libvirt guys would
like the functionality to know number of CPUs supported per machine
type. This usually doesn't matter on x86 architectures however it
matters on ARM, for example, because highbank machine type supports up
to 4 CPUs however integratorcp (default) supports only one.
The migration between qemu and qemu with this patch was working fine
with no regression so basically I need just the statement about CPU
hotplug and I'm ready to send v2 of the patch (just having new field
commented).
Michal
On 04/08/2013 04:02 PM, Luiz Capitulino wrote:
On Mon, 8 Apr 2013 12:00:35 +0200
Michal Novotny minov...@redhat.com wrote:
This alters the query-machines QMP command to output information
about maximum number of CPUs for each machine type with default
value 1 in case the number of max_cpus is not set.
Signed-off-by: Michal Novotny minov...@redhat.com
---
qapi-schema.json | 2 +-
vl.c | 1 +
2 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/qapi-schema.json b/qapi-schema.json
index db542f6..39cae4b 100644
--- a/qapi-schema.json
+++ b/qapi-schema.json
@@ -2865,7 +2865,7 @@
##
{ 'type': 'MachineInfo',
'data': { 'name': 'str', '*alias': 'str',
-'*is-default': 'bool' } }
+'*is-default': 'bool', 'cpu-max': 'int' } }
Please, document the new field.
Also, how is this affected by the CPU hotplug support?
##
# @query-machines:
diff --git a/vl.c b/vl.c
index a8bba04..c05b3d3 100644
--- a/vl.c
+++ b/vl.c
@@ -1617,6 +1617,7 @@ MachineInfoList *qmp_query_machines(Error **errp)
}
info-name = g_strdup(m-name);
+info-cpu_max = !m-max_cpus ? 1 : m-max_cpus;
entry = g_malloc0(sizeof(*entry));
entry-value = info;
--
Michal Novotny minov...@redhat.com, RHCE, Red Hat
Virtualization | libvirt-php bindings | php-virt-control.org
Re: [Qemu-devel] [PATCH] vga.c: move debug printfs to trace events
On Wed, Apr 03, 2013 at 12:25:03PM +0300, Alex DAMIAN wrote: @@ -390,9 +386,7 @@ uint32_t vga_ioport_read(void *opaque, uint32_t addr) break; case VGA_SEQ_D: val = s-sr[s-sr_index]; -#ifdef DEBUG_VGA_REG -printf(vga: read SR%x = 0x%02x\n, s-sr_index, val); -#endif + trace_vga_register_read(SR, s-sr_index, val); A tab crept in here. Please use 4 spaces for indentation. Looks good otherwise. Stefan
Re: [Qemu-devel] [PATCH] qemu-iotests: Add test for -drive options
On Wed, Apr 03, 2013 at 05:25:06PM +0200, Kevin Wolf wrote: Signed-off-by: Kevin Wolf kw...@redhat.com --- tests/qemu-iotests/051 | 143 +++ tests/qemu-iotests/051.out | 162 + tests/qemu-iotests/group | 1 + 3 files changed, 306 insertions(+) create mode 100755 tests/qemu-iotests/051 create mode 100644 tests/qemu-iotests/051.out Thanks, applied to my block tree: https://github.com/stefanha/qemu/commits/block Stefan
Re: [Qemu-devel] [PATCH uq/master v2 1/2] kvm: reset state from the CPU's reset method
Am 08.04.2013 14:19, schrieb Gleb Natapov:
On Tue, Apr 02, 2013 at 04:29:32PM +0300, Gleb Natapov wrote:
static void kvm_sw_tlb_put(PowerPCCPU *cpu)
{
CPUPPCState *env = cpu-env;
diff --git a/target-s390x/cpu.c b/target-s390x/cpu.c
index 23fe51f..6321384 100644
--- a/target-s390x/cpu.c
+++ b/target-s390x/cpu.c
@@ -84,6 +84,10 @@ static void s390_cpu_reset(CPUState *s)
* after incrementing the cpu counter */
#if !defined(CONFIG_USER_ONLY)
s-halted = 1;
+
+if (kvm_enabled()) {
+kvm_arch_reset_vcpu(s);
Does this compile with kvm support disabled?
Well, it does not:
CCs390x-softmmu/target-s390x/cpu.o
/users/gleb/work/qemu/target-s390x/cpu.c: In function 's390_cpu_reset':
/users/gleb/work/qemu/target-s390x/cpu.c:89:9: error: implicit
declaration of function 'kvm_arch_reset_vcpu'
[-Werror=implicit-function-declaration]
/users/gleb/work/qemu/target-s390x/cpu.c:89:9: error: nested extern
declaration of 'kvm_arch_reset_vcpu' [-Werror=nested-externs]
cc1: all warnings being treated as errors
I wonder if it is portable between compilers to rely on code in if(0){} to
be dropped in all levels of optimizations.
No, we had a previous case where --enable-debug broke if (kvm_enabled())
{...} but regular builds worked.
Andreas
--
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
Re: [Qemu-devel] [PATCH v7 1/2] block: Add support for Secure Shell (ssh) block device.
On Fri, Apr 05, 2013 at 02:07:52PM +0100, Richard W.M. Jones wrote:
+/* DEBUG_SSH=1 enables the DPRINTF (debugging printf) statements in
+ * this block driver code.
+ *
+ * TRACE_LIBSSH2=bitmask enables tracing in libssh2 itself. Note
+ * that this requires that libssh2 was specially compiled with the
+ * `./configure --enable-debug' option, so most likely you will have
+ * to compile it yourself. The meaning of bitmask is described
+ * here: http://www.libssh2.org/libssh2_trace.html
+ */
+#define DEBUG_SSH 0
+#define TRACE_LIBSSH2 0 /* or try: LIBSSH2_TRACE_SFTP */
+
+#if DEBUG_SSH
+#define DPRINTF(fmt,...)\
+do {\
+fprintf(stderr, ssh: %-15s fmt \n, __func__, ##__VA_ARGS__); \
+} while (0)
+#else
+#define DPRINTF(fmt,...) /* nothing */
+#endif
The following approach keeps syntax and format string error checking
even when DEBUG_SSH if 0:
#define DPRINTF(fmt, ...) \
do { \
if (DEBUG_SSH) { \
fprintf(stderr, ssh: %-15s fmt \n, \
__func__, ##__VA_ARGS__); \
} \
} while (0)
It avoids DPRINTF() bitrot.
+#define LOCK(s) do {\
+DPRINTF(acquiring the lock); \
+qemu_co_mutex_lock(s-lock); \
+DPRINTF(acquired the lock); \
+} while (0)
+
+#define UNLOCK(s) do {\
+qemu_co_mutex_unlock(s-lock); \
+DPRINTF(released the lock); \
+} while (0)
See ./trace-events:
qemu_co_mutex_lock_entry(void *mutex, void *self) mutex %p self %p
qemu_co_mutex_lock_return(void *mutex, void *self) mutex %p self %p
qemu_co_mutex_unlock_entry(void *mutex, void *self) mutex %p self %p
qemu_co_mutex_unlock_return(void *mutex, void *self) mutex %p self %p
This means you can get these printfs like this:
$ ./configure --enable-trace-backend=stderr
$ echo qemu_co_mutex_lock_entry my-events
$ echo qemu_co_mutex_lock_return my-events
$ echo qemu_co_mutex_unlock_entry my-events
$ echo qemu_co_mutex_unlock_return my-events
$ x86_64-softmmu/qemu-system-x86_64 -trace events=my-events ...
If you want you can keep the macros but really we already have these
printfs.
[Qemu-devel] [PATCH 0/3] target-arm: convert to VMState, fix bugs
This patch series converts target-arm to doing migration via a VMState structure, and fixes some minor bugs in migration of the CPU as well. The bulk of it is a patch Juan sent out back in the middle of last year https://lists.gnu.org/archive/html/qemu-devel/2012-05/msg00550.html which I have rebased and messed about with somewhat: * rebased and fixed conflicts * updated to use cpu_class_set_vmsd() * updated with new/removed fields since original patch * corrected subsection names so vmload doesn't fail * changed to use custom VMStateInfo for cpsr rather than presave/postload hooks The last of these was the subject of some discussion when Juan posted the patch (see URL above for the thread). The fundamental problem that has to be solved is how do you deal with cases where the representation in the in memory struct is not the same as the on the wire representation?: (a) Juan's original patch does write wire format to random dummy field in the struct and then clean things up in presave/postload hooks. (b) My patch follows what Alpha, i386 and some devices do: define a custom VMStateInfo which reads/writes the wire format and does the conversion to/from the struct. (c) There was a mooted third approach of defining new vmstate macros and functionality so you could specify conversion functions for a field but leave actual reading and writing of the wire format to the core savevm code. The argument against (b) was that it makes introducing a new migration wire format harder, but on the other hand it's a year later and nobody has, and we already have examples of this in tree so another user is no big deal. So it doesn't seem to me to merit the effort of actually implementing (c). I've gone for (b) because I think it's better than (a). Overall I think the whole series is an improvement over the separate save/load fields; I'd also like to get this changeover done before we start having to worry about freezing the ARM migration format. Juan Quintela (1): target-arm: port ARM CPU save/load to use VMState Peter Maydell (2): target-arm: Add some missing CPU state fields to VMState target-arm: Correctly restore FPSCR target-arm/cpu-qom.h |4 + target-arm/cpu.c |1 + target-arm/cpu.h |2 - target-arm/machine.c | 430 +- 4 files changed, 221 insertions(+), 216 deletions(-) -- 1.7.9.5
Re: [Qemu-devel] [PATCH] migration: initialize RAM to zero
Am 08.04.2013 um 12:47 schrieb Paolo Bonzini pbonz...@redhat.com:
Using qemu_memalign only leaves the RAM zero by chance, because libc
will usually use mmap to satisfy our huge requests. But memory will
not be zero when using MALLOC_PERTURB_ with a nonzero value. In the
case of incoming migration, this breaks a recently-introduced
invariant (commit f1c7279, migration: do not sent zero pages in
bulk stage, 2013-03-26).
To fix this, use mmap ourselves to get a well-aligned, always zero
block for the RAM. Mmap-ed memory is easy to trim at the sides.
This also removes the need to do something special on valgrind
(see commit c2a8238a, Support running QEMU on Valgrind, 2011-10-31).
Signed-off-by: Paolo Bonzini pbonz...@redhat.com
---
util/oslib-posix.c | 30 +-
1 file changed, 13 insertions(+), 17 deletions(-)
diff --git a/util/oslib-posix.c b/util/oslib-posix.c
index 433dd68..91f5aab 100644
--- a/util/oslib-posix.c
+++ b/util/oslib-posix.c
@@ -52,12 +52,8 @@ extern int daemon(int, int);
#include sysemu/sysemu.h
#include trace.h
#include qemu/sockets.h
+#include sys/mman.h
-#if defined(CONFIG_VALGRIND)
-static int running_on_valgrind = -1;
-#else
-# define running_on_valgrind 0
-#endif
#ifdef CONFIG_LINUX
#include sys/syscall.h
#endif
@@ -108,22 +104,22 @@ void *qemu_memalign(size_t alignment, size_t size)
/* alloc shared memory pages */
void *qemu_vmalloc(size_t size)
{
-void *ptr;
size_t align = QEMU_VMALLOC_ALIGN;
+size_t total = size + align - getpagesize();
+void *ptr = mmap(0, total, PROT_READ | PROT_WRITE,
+ MAP_ANONYMOUS | MAP_PRIVATE, -1, 0);
+size_t offset = QEMU_ALIGN_UP((uintptr_t)ptr, align) - (uintptr_t)ptr;
-#if defined(CONFIG_VALGRIND)
-if (running_on_valgrind 0) {
-/* First call, test whether we are running on Valgrind.
- This is a substitute for RUNNING_ON_VALGRIND from valgrind.h. */
-const char *ld = getenv(LD_PRELOAD);
-running_on_valgrind = (ld != NULL strstr(ld, vgpreload));
-}
-#endif
+ptr += offset;
+total -= offset;
-if (size align || running_on_valgrind) {
-align = getpagesize();
+if (offset 0) {
+munmap(ptr - offset, offset);
+}
+if (total size) {
+munmap(ptr + size, total - size);
}
-ptr = qemu_memalign(align, size);
+
trace_qemu_vmalloc(size, ptr);
return ptr;
}
--
1.8.1.4
Reviewed-by: Peter Lieven p...@kamp.de
Re: [Qemu-devel] [PATCH v4] block: Add support for Secure Shell (ssh) block device.
On Mon, Apr 8, 2013 at 3:05 PM, Richard W.M. Jones rjo...@redhat.com wrote: More specifically, here's the output on my machine: rjones@choo:~/d/qemu/tests/qemu-iotests$ QEMU_PROG=~/d/qemu/x86_64-softmmu/qemu-system-x86_64 PATH=~/d/qemu:$PATH ./check -ssh gah, I just hit a libssh2 limitation. In my .ssh/config I have: NoHostAuthenticationForLocalhost yes This stops ssh from complaining when I hope to another host through an ssh tunnel (the host key wouldn't match localhost). $ ssh localhost ...works fine... $ ./qemu-img info ssh://localhost/home/stefanha/qemu/test.img no host key was found in known_hosts: (libssh2 error code: 0) qemu-img: Could not open 'ssh://localhost/home/stefanha/qemu/test.img': Invalid argument From what I can see libssh2 does not support loading .ssh/config. This is a limitation not just for NoHostAuthenticationForLocalhost but also for all the Hostname aliases with User options that I have in my .ssh/config - I can't use them. I remember the Fabric tool had similar issues, it uses Python paramiko ssh implementation, and I think they added to code to parse .ssh/config so all these conveniences work: https://github.com/paramiko/paramiko/blob/master/paramiko/config.py What do you think? Stefan
Re: [Qemu-devel] Virtualbox svga card in KVM
By richer display, I meant support for different resolution and color depth (including support for nonstandard resolutions as well). -Sriram - Original Message - From: Stefan Hajnoczi stefa...@gmail.com To: Sriram Murthy srira...@yahoo.com Cc: k...@vger.kernel.org k...@vger.kernel.org; qemu list qemu-devel@nongnu.org Sent: Monday, April 8, 2013 3:46 AM Subject: Re: Virtualbox svga card in KVM On Fri, Apr 05, 2013 at 04:52:05PM -0700, Sriram Murthy wrote: For starters, virtual box has better SVGA WDDM drivers that allows for a much richer display when the VM display is local. What does much richer display mean? Stefan
Re: [Qemu-devel] Virtualbox svga card in KVM
On 6 April 2013 00:52, Sriram Murthy srira...@yahoo.com wrote: (actually, the virtualbox SVGA card is based off of the KVM VGA card) Is it possible to implement it as an extension to the VGA card device, or has it diverged incompatibly such that it has to be its own separate device model? thanks -- PMM
[Qemu-devel] [PATCH 2/3] target-arm: Add some missing CPU state fields to VMState
A number of CPU state fields were accidentally omitted from
our migration state: some OMAP specific cp15 registers, and
some related to state for load/store exclusive insns. Add them.
Signed-off-by: Peter Maydell peter.mayd...@linaro.org
---
target-arm/machine.c | 13 ++---
1 file changed, 10 insertions(+), 3 deletions(-)
diff --git a/target-arm/machine.c b/target-arm/machine.c
index 3c41f06..2dd48d7 100644
--- a/target-arm/machine.c
+++ b/target-arm/machine.c
@@ -116,9 +116,9 @@ static const VMStateInfo vmstate_cpsr = {
const VMStateDescription vmstate_arm_cpu = {
.name = cpu,
-.version_id = 10,
-.minimum_version_id = 10,
-.minimum_version_id_old = 10,
+.version_id = 11,
+.minimum_version_id = 11,
+.minimum_version_id_old = 11,
.fields = (VMStateField[]) {
VMSTATE_UINT32_ARRAY(env.regs, ARMCPU, 16),
{
@@ -172,9 +172,16 @@ const VMStateDescription vmstate_arm_cpu = {
VMSTATE_UINT32(env.cp15.c13_tls2, ARMCPU),
VMSTATE_UINT32(env.cp15.c13_tls3, ARMCPU),
VMSTATE_UINT32(env.cp15.c15_cpar, ARMCPU),
+VMSTATE_UINT32(env.cp15.c15_ticonfig, ARMCPU),
+VMSTATE_UINT32(env.cp15.c15_i_max, ARMCPU),
+VMSTATE_UINT32(env.cp15.c15_i_min, ARMCPU),
+VMSTATE_UINT32(env.cp15.c15_threadid, ARMCPU),
VMSTATE_UINT32(env.cp15.c15_power_control, ARMCPU),
VMSTATE_UINT32(env.cp15.c15_diagnostic, ARMCPU),
VMSTATE_UINT32(env.cp15.c15_power_diagnostic, ARMCPU),
+VMSTATE_UINT32(env.exclusive_addr, ARMCPU),
+VMSTATE_UINT32(env.exclusive_val, ARMCPU),
+VMSTATE_UINT32(env.exclusive_high, ARMCPU),
VMSTATE_UINT64(env.features, ARMCPU),
VMSTATE_END_OF_LIST()
},
--
1.7.9.5
