Hidetoshi Seto | 1 Dec 02:16 2010

Re: [Qemu-devel] Re: [PATCH v5] virtio-9p: fix build on !CONFIG_UTIMENSAT


Maintainers, please tell me if still something is required for
this patch before applying it.


(2010/11/24 17:01), Jes Sorensen wrote:
> On 11/24/10 03:38, Hidetoshi Seto wrote:
>> This patch introduce a fallback mechanism for old systems that do not
>> support utimensat().  This fix build failure with following warnings:
>> hw/virtio-9p-local.c: In function 'local_utimensat':
>> hw/virtio-9p-local.c:479: warning: implicit declaration of function 'utimensat'
>> hw/virtio-9p-local.c:479: warning: nested extern declaration of 'utimensat'
>> and:
>> hw/virtio-9p.c: In function 'v9fs_setattr_post_chmod':
>> hw/virtio-9p.c:1410: error: 'UTIME_NOW' undeclared (first use in this function)
>> hw/virtio-9p.c:1410: error: (Each undeclared identifier is reported only once
>> hw/virtio-9p.c:1410: error: for each function it appears in.)
>> hw/virtio-9p.c:1413: error: 'UTIME_OMIT' undeclared (first use in this function)
>> hw/virtio-9p.c: In function 'v9fs_wstat_post_chmod':
>> hw/virtio-9p.c:2905: error: 'UTIME_OMIT' undeclared (first use in this function)
>> [NOTE: At this time virtio-9p is only user of utimensat(), and is available
>>        only when host is linux and CONFIG_VIRTFS is defined.  So there are
>>        no similar warning for win32.  Please provide a wrapper for win32 in
(Continue reading)

Takuya Yoshikawa | 1 Dec 02:20 2010

Re: [PATCH 09/10] Exit loop if we have been there too long

On Tue, 30 Nov 2010 16:27:13 +0200
Avi Kivity <avi <at> redhat.com> wrote:

> On 11/30/2010 04:17 PM, Anthony Liguori wrote:
> >> What's the problem with burning that cpu?  per guest page, 
> >> compressing takes less than sending.  Is it just an issue of qemu 
> >> mutex hold time?
> >
> >
> > If you have a 512GB guest, then you have a 16MB dirty bitmap which 
> > ends up being an 128MB dirty bitmap in QEMU because we represent dirty 
> > bits with 8 bits.
> Was there not a patchset to split each bit into its own bitmap?  And 
> then copy the kvm or qemu master bitmap into each client bitmap as it 
> became needed?
> > Walking 16mb (or 128mb) of memory just fine find a few pages to send 
> > over the wire is a big waste of CPU time.  If kvm.ko used a 
> > multi-level table to represent dirty info, we could walk the memory 
> > mapping at 2MB chunks allowing us to skip a large amount of the 
> > comparisons.
> There's no reason to assume dirty pages would be clustered.  If 0.2% of 
> memory were dirty, but scattered uniformly, there would be no win from 
> the two-level bitmap.  A loss, in fact: 2MB can be represented as 512 
> bits or 64 bytes, just one cache line.  Any two-level thing will need more.
> We might have a more compact encoding for sparse bitmaps, like 
> run-length encoding.
(Continue reading)

Juan Quintela | 1 Dec 02:52 2010

Re: [PATCH 09/10] Exit loop if we have been there too long

Takuya Yoshikawa <yoshikawa.takuya <at> oss.ntt.co.jp> wrote:
> On Tue, 30 Nov 2010 16:27:13 +0200
> Avi Kivity <avi <at> redhat.com> wrote:

> Does anyone is profiling these dirty bitmap things?

I am.

>  - 512GB guest is really the target?

no, problems exist with smaller amounts of RAM.  with 16GB guest it is
trivial to get 1s stalls, 64GB guest, 3-4s, with more memory, migration
is flaky to say the less.

>  - how much cpu time can we use for these things?

the problem here is that we are forced to walk the bitmap too many
times, we want to do it less times.

>  - how many dirty pages do we have to care?

default values and assuming 1Gigabit ethernet for ourselves ~9.5MB of
dirty pages to have only 30ms of downtime.

But notice that this is what we are advertising, we aren't near there at all.

> Since we are planning to do some profiling for these, taking into account
> Kemari, can you please share these information?

If you see the 0/10 email with this setup, you can see how much time are
(Continue reading)

Takuya Yoshikawa | 1 Dec 03:22 2010

Re: [PATCH 09/10] Exit loop if we have been there too long

On Wed, 01 Dec 2010 02:52:08 +0100
Juan Quintela <quintela <at> redhat.com> wrote:

> > Since we are planning to do some profiling for these, taking into account
> > Kemari, can you please share these information?
> If you see the 0/10 email with this setup, you can see how much time are
> we spending on stuff.  Just now (for migration, kemari is a bit
> different) we have to fix other things first.

Thank you for the information.
  Sorry, I only had the [9/10] in my kvm mail box and did not notice this [0/10].

> >> >> non-interface-changing ways to reduce this latency, like O(1) write 
> >> >> protection, or using dirty bits instead of write protection when 
> >> >> available.
> >
> > IIUC, O(1) will lazily write protect pages beggining from top level?
> > Does this have any impact other than the timing of get_dirty_log()?
> dunno.
> At this point I am trying to:
> - get migration with 16-64GB to not having stalls.
> - get infrastructure to be able to know what is going on.
> So far, bigger stalls are gone, and discusing what to do next.  As
> Anthony suggested I run ram_save_live() loop without qemu_mutex, and now
> guests get much better interaction, but my current patch (for this) is
(Continue reading)

Kevin O'Connor | 1 Dec 03:53 2010

Re: [PATCHv6 00/16] boot order specification

On Tue, Nov 30, 2010 at 04:01:00PM +0200, Gleb Natapov wrote:
> On Mon, Nov 29, 2010 at 08:34:03PM -0500, Kevin O'Connor wrote:
> > On Sun, Nov 28, 2010 at 08:47:34PM +0200, Gleb Natapov wrote:
> > > If you let go to the idea of exact matching of string built by qemu in
> > > Seabios it will be easy to see that /pci <at> i0cf8/ethernet <at> 4/ethernet-phy <at> 0
> > > provides everything that Seabios needs to know and even more. If
> > > you ignore all the noise it just says "boot from pci device slot 4 fn
> > > 0". Seabios may have native support for the card in the slot or it can
> > > use option rom on the card. Qemu does not care.
> > 
> > I'm having a hard time letting go of string matching.  I understand
> > all the info is there if SeaBIOS parses the string.  However, I think
> > parsing out openbios device strings is overkill in an x86 bios that
> > just wants to order the boot objects it knows about.
> > 
> > Is there an issue with qemu generating two strings for devices with
> > roms?
> > 
> I just do not see how I can justify this addition to qemu maintainers
> given that the parsing code below is very simple.

It doesn't look correct to me - it doesn't handle the case where the
PCI device is on a bridge.

BTW, what's the plan for handling SCSI adapters?  Lets say a user has
a scsi card with three drives (lun 1, lun 3, lun 5) that show up as 3
bcvs (lun1, lun3, lun5 in that order) and the user wishes to boot from
lun3.  I understand this use case may not be important for qemu, but
I'd like to use the same code on coreboot.  Being able to boot from
any drive is important - it doesn't have to autodetect, but it should
(Continue reading)

Jin Guojie | 1 Dec 04:10 2010

[patch] MIPS Initial support of Godson-3a multicore CPU

  Attached is a patch for Godson-3a CPU support.
  Godson-3a is a newly developed MIPS-III like, multicore CPU by ICT, China.
  For you review. Any comment is welcomed.

Jin Guojie
Serge Hallyn | 1 Dec 04:39 2010

[Bug 595438] Re: KVM segmentation fault, using SCSI+writeback and linux 2.4 guest

At last!  I was able to reproduce this using a copy of fedora 1 from


This would segfault before completing install from disc 1 more than 50%
of the time.  With the qemu-kvm from -proposed, I've not been able to
get it to segfault.

KVM segmentation fault, using SCSI+writeback and linux 2.4 guest
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.

Status in Kernel Virtual Machine: Confirmed
Status in QEMU: Fix Committed
Status in qemu-kvm: Fix Released
Status in “qemu-kvm” package in Ubuntu: Fix Released
Status in “qemu-kvm” source package in Lucid: Fix Committed
Status in “qemu-kvm” package in Debian: Fix Released

Bug description:
I Use Ubuntu 32 bit 10.04 with standard KVM.
I have Intel E7600   <at>  3.06GHz processor with VMX

In this system I Run:
LC_ALL=C PATH=/usr/local/sbin:/usr/local/bin:/usr/bin:/usr/sbin:/sbin:/bin
QEMU_AUDIO_DRV=none /usr/bin/kvm -M pc-0.12 -enable-kvm -m 256 -smp 1 -name spamsender -uuid
b9cacd5e-08f7-41fd-78c8-89cec59af881 -chardev
(Continue reading)

Yoshiaki Tamura | 1 Dec 09:03 2010

Re: [PATCH 05/21] virtio: modify save/load handler to handle inuse varialble.

2010/11/28 Michael S. Tsirkin <mst <at> redhat.com>:
> On Sun, Nov 28, 2010 at 08:27:58PM +0900, Yoshiaki Tamura wrote:
>> 2010/11/28 Michael S. Tsirkin <mst <at> redhat.com>:
>> > On Thu, Nov 25, 2010 at 03:06:44PM +0900, Yoshiaki Tamura wrote:
>> >> Modify inuse type to uint16_t, let save/load to handle, and revert
>> >> last_avail_idx with inuse if there are outstanding emulation.
>> >>
>> >> Signed-off-by: Yoshiaki Tamura <tamura.yoshiaki <at> lab.ntt.co.jp>
>> >
>> > This changes migration format, so it will break compatibility with
>> > existing drivers. More generally, I think migrating internal
>> > state that is not guest visible is always a mistake
>> > as it ties migration format to an internal implementation
>> > (yes, I know we do this sometimes, but we should at least
>> > try not to add such cases).  I think the right thing to do in this case
>> > is to flush outstanding
>> > work when vm is stopped.  Then, we are guaranteed that inuse is 0.
>> > I sent patches that do this for virtio net and block.
>> Could you give me the link of your patches?  I'd like to test
>> whether they work with Kemari upon failover.  If they do, I'm
>> happy to drop this patch.
>> Yoshi
> Look for this:
> stable migration image on a stopped vm
> sent on:
> Wed, 24 Nov 2010 17:52:49 +0200

(Continue reading)

Jason Wang | 1 Dec 06:45 2010

[PATCHv3 4/6] virtio-net: stop/start bh when appropriate

Michael S. Tsirkin writes:
 > Avoid sending out packets, and modifying
 > device state, when VM is stopped.
 > Add assert statements to verify this does not happen.
 > Avoid scheduling bh when vhost-net is started.
 > Stop bh when driver disabled bus mastering
 > (we must not access memory after this).
 > Signed-off-by: Michael S. Tsirkin <mst <at> redhat.com>

There's no need to disable it bh we call qemu_aio_flush() after
vm_state_notify() in do_vm_stop(). And for timer, looks like every device should
stop its timer in vm state change handler, not only for virtio-net?

 > ---
 > Respinning just this one patch:
 > virtio-net: stop/start bh on vm start/stop
 > it turns out under kvm vcpu can be running after vm stop
 > notifier callbacks are done. And it makes sense: vcpu is
 > just another device, so we should not
 > depend on the order of vmstate notifiers.
 > The state callback is thus a request for device to avoid changing state
 > of other devices, not a guarantee that other devices
 > will not send requests to it.
(Continue reading)

Amit Shah | 1 Dec 10:54 2010

[PATCH v8 1/7] virtio-console: Factor out common init between console and generic ports

The initialisation for generic ports and console ports is similar.
Factor out the parts that are the same in a different function that can
be called from each of the initfns.

Signed-off-by: Amit Shah <amit.shah <at> redhat.com>
 hw/virtio-console.c |   31 ++++++++++++++-----------------
 1 files changed, 14 insertions(+), 17 deletions(-)

diff --git a/hw/virtio-console.c b/hw/virtio-console.c
index caea11f..d7fe68b 100644
--- a/hw/virtio-console.c
+++ b/hw/virtio-console.c
 <at>  <at>  -58,24 +58,28  <at>  <at>  static void chr_event(void *opaque, int event)

-/* Virtio Console Ports */
-static int virtconsole_initfn(VirtIOSerialDevice *dev)
+static int generic_port_init(VirtConsole *vcon, VirtIOSerialDevice *dev)
-    VirtIOSerialPort *port = DO_UPCAST(VirtIOSerialPort, dev, &dev->qdev);
-    VirtConsole *vcon = DO_UPCAST(VirtConsole, port, port);
-    port->info = dev->info;
-    port->is_console = true;
+    vcon->port.info = dev->info;

     if (vcon->chr) {
(Continue reading)