Re: [Qemu-devel] q35 migration broken

[Marcel Apfelbaum <marcel@redhat.com>]

On 04/01/2016 08:01 PM, Dr. David Alan Gilbert wrote:
> * Marcel Apfelbaum (marcel@redhat.com) wrote:
>> On 04/01/2016 06:54 PM, Dr. David Alan Gilbert wrote:
>>> * Dr. David Alan Gilbert (dgilbert@redhat.com) wrote:
>>>> * Dr. David Alan Gilbert (dgilbert@redhat.com) wrote:
>>>>> Hi,
>>>>>    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 output.
>>>>>
>>>>> 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 \
>>>   -device virtio-blk-pci,scsi=off,bus=pci.1,addr=0x5,drive=image,id=virtio-disk0,bootindex=1 \
>>>   $*
>>>
>>> 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),
         VMSTATE_END_OF_LIST()
     }
};



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

good, we can track this now.

Thanks,
Marcel

>>
>> Thanks,
>> Marcel
>>
>>>
>>> Dave
>>>
>>> --
>>> Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK
>>>
>>
> --
> Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK
>