Il 16/05/2013 16:21, mdroth ha scritto: > commit e37da3945fa2fde161e1b217f937fc318c4b7639 > Author: KONRAD Frederic <fred.kon...@greensocs.com> > 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 <fred.kon...@greensocs.com> > Tested-by: Cornelia Huck <cornelia.h...@de.ibm.com> > Message-id: 1365690602-22729-4-git-send-email-fred.kon...@greensocs.com > Signed-off-by: Anthony Liguori <aligu...@us.ibm.com> > > 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 >> >> > >