[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] q35 migration broken

From: Marcel Apfelbaum
Subject: Re: [Qemu-devel] q35 migration broken
Date: Fri, 1 Apr 2016 20:05:18 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0

On 04/01/2016 08:01 PM, Dr. David Alan Gilbert wrote:
* Marcel Apfelbaum (address@hidden) wrote:
On 04/01/2016 06:54 PM, Dr. David Alan Gilbert wrote:
* Dr. David Alan Gilbert (address@hidden) wrote:
* Dr. David Alan Gilbert (address@hidden) wrote:
   I'm seeing a breakage on q35 migration on head (and possibly older
but certainly head; it's also on a 2.5.0 world I've got with a bunch
of patches but I've not tried a clean 2.5.0 yet).

It looks like some type of interrupt screwup; with a virtio-net device
I get a:
   BUG: soft lockup - CPU#0 stuck for 22s!
   ...  virtnet_config_changed_work

but if I swap that out for an e1000 I get:
   Disabling IRQ #22

   and various timeouts on e1000 and cdrom (scsi).
The guest kind of limps along with an existing terminal scrolling dmesg -w 

This is an f23 guest on a rhel7.2-ish host; with the guest sitting an idle
(MATE) Gui.

Also broken with 2.4.1 and 2.5.1 (with pc-q35-2.4 machine type);
see a screen shot attached; note:
    a) The large count on irq 22 (enp2s1) on cpu1
    b) The large count on virtio2-config on cpu1
    c) The count of 'Deferred Error APIC interrupts'.

OK, this seems to be the i82801b11-bridge; if I remove it from the config
it all works.

My minimum config that fails so far is:
/opt/qemu-head/bin/qemu-system-x86_64 -nographic -machine 
pc-q35-2.6,accel=kvm,usb=off,vmport=off -cpu SandyBridge -m 4096 -realtime 
mlock=off -smp 4,sockets=4,cores=1,threads=1 \
  -device i82801b11-bridge,id=pci.1,bus=pcie.0,addr=0x1e \
  -drive id=image,file=/home/vms/f23-serial.qcow2,if=none,cache=none \

if I flip the i82801b11-bridge for a pci-bridge  then it works.

Hi Dave,
That's good news. I see we don't have a vmstate for this bridge, but we do have 
one for the regular pci-bridge.
Maybe this is the problem?

Yeh that's one of my suspicions; but how do device classes work?
If a i82801b11-bridge is a subclass of pci-bridge should it just
pick up the vmstate of the subclass magically?

I am not sure, I think you need something like:

static const VMStateDescription i82801b11-bridge_dev_vmstate = {
    .name = ""i82801b11_bridge,
    .fields = (VMStateField[]) {
        VMSTATE_PCI_DEVICE(parent_obj, PCIBridge),

P.S. I've filed this as RH bz 1323273

good, we can track this now.




Dr. David Alan Gilbert / address@hidden / Manchester, UK

Dr. David Alan Gilbert / address@hidden / Manchester, UK

reply via email to

[Prev in Thread] Current Thread [Next in Thread]