qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Glauber Costa <glommer@redhat.com>
To: qemu-devel@nongnu.org
Cc: kraxel@redhat.com, armbru@redhat.com
Subject: [Qemu-devel] sending pci information over the wire
Date: Thu, 18 Jun 2009 16:39:46 -0300	[thread overview]
Message-ID: <20090618193946.GH3517@poweredge.glommer> (raw)

Hi folks,

I have some trial code here for a proposal, which I'd like to hear your
opinions about (Well, I _had_, because I'm totally stupid and git reset'd --hard
the wrong location, that happened to contain part of the code for it)

Let me start by explaining what I'm trying to accomplish, and say that I myself
am not sure this is the best approach, it is just a crazy idea that poped up.

Right now, migration of pci devices work by a bit of luck. This is because the
other side of the wire can enumerate the devices in a different order, causing
them to end up at different addresses. Markus approach of pci_addr= patches
do help that fact. 

However, theoretically, there can be a case in which we:
 * start receiving guest, with parameters determined by pci_addr=
 * start live migration
 * add a device.

The receiving guest won't know about that device, and migration then fail.
This is not a problem _today_, as mgmt tools disallow addition of hardware
during migration. But this is a restriction that comes exactly from the lack
of robustness of migration! Furthermore, mgmt tools might want to change
that behaviour in the future...

That said, my proposal is as following:

in the savevm part of the pci bus, list properties of all present devices.
on the load part of the pci bus, scan the bus looking for devices that
should be present and are not, and create them, if needed.

A new machine type gets added, pc_migr, that does not put pci devices in the bus.
All pci devices will be missing, and them them all get created.

To do that, we also have to save/load some qemu internal state. For example,
nd_table has to be transferred, to guarantee that proper configuration will
exist on the other side. Ultimately, that can be used to transfer _all_ qemu
internal state. A side effect, is that a qemu instance receiving migration
can be shot with : qemu-system-x86_64 -M pc_migr -incoming addr -vnc :x.
It is not that important, if you use mgmt apps, but a nice side effect, otherwise.

I tested this with some network cards, and it kinda works. So, let me know what
is the general feeling about that. If there is a compelling case for it,
I can go back and hack it more. Otherwise, it was fun anyway.


----- End forwarded message -----

             reply	other threads:[~2009-06-18 19:33 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-06-18 19:39 Glauber Costa [this message]
2009-06-18 20:03 ` [Qemu-devel] sending pci information over the wire Anthony Liguori
2009-06-18 20:12   ` Glauber Costa
2009-06-18 20:38     ` Anthony Liguori
2009-06-19  8:55       ` Gerd Hoffmann
2009-06-19 13:10         ` Anthony Liguori
2009-06-19 14:33           ` Gerd Hoffmann
2009-06-19 14:47             ` Paul Brook
2009-06-19 15:16             ` Anthony Liguori
2009-06-19 15:38               ` Gerd Hoffmann
2009-06-19 15:56                 ` Anthony Liguori
2009-06-20 18:58   ` Avi Kivity

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=20090618193946.GH3517@poweredge.glommer \
    --to=glommer@redhat.com \
    --cc=armbru@redhat.com \
    --cc=kraxel@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).