All of lore.kernel.org
 help / color / mirror / Atom feed
From: "KONRAD Frédéric" <fred.konrad@greensocs.com>
To: mdroth <mdroth@linux.vnet.ibm.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>,
	Anthony Liguori <aliguori@us.ibm.com>,
	qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [ANNOUNCE] QEMU 1.5.0-rc2 is now available
Date: Thu, 16 May 2013 17:17:37 +0200	[thread overview]
Message-ID: <5194F891.9090403@greensocs.com> (raw)
In-Reply-To: <20130516142151.GC23880@vm>

On 16/05/2013 16:21, mdroth wrote:
> On Wed, May 15, 2013 at 06:53:47PM -0500, Anthony Liguori wrote:
>> Hi,
>>
>> On behalf of the QEMU Team, I'd like to announce the availability of the
>> third release candidate for the QEMU 1.5 release.  This release is meant
>> for testing purposes and should not be used in a production environment.
>>
>> http://wiki.qemu.org/download/qemu-1.5.0-rc2.tar.bz2
>>
>> You can help improve the quality of the QEMU 1.5 release by testing this
>> release and reporting bugs on Launchpad:
>>
> Sorry to chime in on this so late in the cycle, but I just noticed what
> seems to be a pretty serious problem with migration to/from 1.4. This is
> the failure for 1.4 -> 1.5-rc2
>
> (qemu) migrate unix:/tmp/migrate.sock
> Unknown savevm section or instance '0000:00:03.0/virtio-net' 0
>
> Configuration:
>
> source: v14/x86_64-softmmu/qemu-system-x86_64 -enable-kvm -L v14-bios -M
> pc-i440fx-1.4 -m 512M -kernel boot/vmlinuz-x86_64 -initrd
> boot/test-initramfs-x86_64.img.gz -vga std -append seed=1234 -drive
> file=disk1.img,if=virtio -drive file=disk2.img,if=virtio -net
> nic,model=virtio -net user -monitor unix:/tmp/vm-hmp.sock,server,nowait
> -qmp unix:/tmp/vm-qmp.sock,server,nowait -vnc :100
>
> target: v15rc2/x86_64-softmmu/qemu-system-x86_64 -enable-kvm -L temp-bios
> -M pc-i440fx-1.4 -m 512M -kernel boot/vmlinuz-x86_64 -initrd
> boot/test-initramfs-x86_64.img.gz -vga std -append seed=1234 -drive
> file=disk1.img,if=virtio -drive file=disk2.img,if=virtio -net
> nic,model=virtio -net user -incoming unix:/tmp/migrate.sock -monitor
> unix:/tmp/vm-hmp-incoming.sock,server,nowait -qmp
> unix:/tmp/vm-qmp-incoming.sock,server,nowait -vnc :101
> QEMU 1.4.0 monitor - type 'help' for more information
>
> This seems to have been introduced with the virtio refactoring:
>
> commit e37da3945fa2fde161e1b217f937fc318c4b7639
> Author: KONRAD Frederic <fred.konrad@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.konrad@greensocs.com>
>      Tested-by: Cornelia Huck <cornelia.huck@de.ibm.com>
>      Message-id: 1365690602-22729-4-git-send-email-fred.konrad@greensocs.com
>      Signed-off-by: Anthony Liguori <aliguori@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 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.

Sorry for that.
Have you made progress?

I'm trying to add get_dev_path function to virtio-pci-bus in 
virtio-pci.c as Paolo suggests.

How do you get those instance_id to check It's working?

Fred
>> Regards,
>>
>> Anthony Liguori
>>
>>

      parent reply	other threads:[~2013-05-16 15:17 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-05-15 23:53 [Qemu-devel] [ANNOUNCE] QEMU 1.5.0-rc2 is now available Anthony Liguori
2013-05-16  3:56 ` Dongsheng Song
2013-05-16 14:21 ` mdroth
2013-05-16 14:51   ` Paolo Bonzini
2013-05-16 15:54     ` KONRAD Frédéric
2013-05-16 16:07       ` Paolo Bonzini
2013-05-16 16:34         ` KONRAD Frédéric
2013-05-16 16:49           ` mdroth
2013-05-16 16:53             ` KONRAD Frédéric
2013-05-16 16:52           ` Paolo Bonzini
2013-05-16 16:35         ` mdroth
2013-05-16 16:33       ` Anthony Liguori
2013-05-16 16:34         ` KONRAD Frédéric
2013-05-16 15:17   ` KONRAD Frédéric [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5194F891.9090403@greensocs.com \
    --to=fred.konrad@greensocs.com \
    --cc=aliguori@us.ibm.com \
    --cc=mdroth@linux.vnet.ibm.com \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.