From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:38314) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UczX2-0004ci-9h for qemu-devel@nongnu.org; Thu, 16 May 2013 10:51:49 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UczX0-0005a9-SY for qemu-devel@nongnu.org; Thu, 16 May 2013 10:51:48 -0400 Received: from mail-gh0-f177.google.com ([209.85.160.177]:46933) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UczX0-0005a3-NK for qemu-devel@nongnu.org; Thu, 16 May 2013 10:51:46 -0400 Received: by mail-gh0-f177.google.com with SMTP id f20so635379ghb.22 for ; Thu, 16 May 2013 07:51:45 -0700 (PDT) Sender: Paolo Bonzini Message-ID: <5194F279.30200@redhat.com> Date: Thu, 16 May 2013 16:51:37 +0200 From: Paolo Bonzini MIME-Version: 1.0 References: <1368662027-14213-1-git-send-email-aliguori@us.ibm.com> <20130516142151.GC23880@vm> In-Reply-To: <20130516142151.GC23880@vm> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [ANNOUNCE] QEMU 1.5.0-rc2 is now available List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: mdroth Cc: Anthony Liguori , qemu-devel@nongnu.org, fred.konrad@greensocs.com Il 16/05/2013 16:21, mdroth ha scritto: > commit e37da3945fa2fde161e1b217f937fc318c4b7639 > Author: KONRAD Frederic > 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 > Tested-by: Cornelia Huck > Message-id: 1365690602-22729-4-git-send-email-fred.konrad@greensocs.com > Signed-off-by: Anthony Liguori > > 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 >> >> > >