Re: [Qemu-devel] [ANNOUNCE] QEMU 1.5.0-rc2 is now available

[Paolo Bonzini]

Il 16/05/2013 16:21, mdroth ha scritto:
> commit e37da3945fa2fde161e1b217f937fc318c4b7639
> Author: KONRAD Frederic <address@hidden>
> Date:   Thu Apr 11 16:29:58 2013 +0200
> 
>     virtio-net-pci: switch to the new API.
>     
>     Here the virtio-net-pci is modified for the new API. The device
>     virtio-net-pci extends virtio-pci. It creates and connects a
>     virtio-net-device during the init. The properties are not changed.
>     
>     Signed-off-by: KONRAD Frederic <address@hidden>
>     Tested-by: Cornelia Huck <address@hidden>
>     Message-id: address@hidden
>     Signed-off-by: Anthony Liguori <address@hidden>
> 
> And if we roll that back, we have similar failures for virtio-blk, and most
> likely the other virtio devices touched by the refactoring.
> 
> The issue seems to be a change the way section id strings are generated in
> vmstate_register(). In v1.4.x we had:
> 
> se->instance_id: 0, se->idstr: 0000:00:03.0/virtio-net
> 
> In v1.5.0-rc2 we have:
> 
> se->instance_id: 0, se->idstr: virtio-net
> 
> This seems to be due to the fact that these devices now sit on a
> TYPE_VIRTIO_BUS that has no implementation of TYPE_BUS's get_dev_path()
> interface, which is what savevm uses to calculate the id prefix for
> se->idstr.
> 
> Prior to the refactoring, the device sat on a TYPE_PCI_BUS which used
> pcibus_get_dev_path() to calculate this.
> 
> I'm not sure what the best fix is for this. I looking at implementing
> get_dev_path() for TYPE_VIRTIO_BUS, but to maintain migration
> compatibility we'd end up baking in PCI-specific stuff which from what
> I gather is exactly what we were trying to avoid there.

I think get_dev_path for TYPE_VIRTIO_BUS could simply forward to the
parent device's parent bus.

Paolo

> I think adding a compat string property to TYPE_VIRTIO_DEVICE and having
> that get set somewhere like virtio_bus_plug_device() is a better
> approach, but vmstate_register() gets call during TYPE_VIRTIO_DEVICE
> init which I think happens before then.
> 
> Still looking at it but if someone more familiar with this code has
> some ideas or wants to whip up a patch please jump right in.
> 
>>
>> Regards,
>>
>> Anthony Liguori
>>
>>
> 
>