Alex Williamson <alex.william...@redhat.com> wrote: > On Wed, 2010-06-16 at 20:43 +0200, Juan Quintela wrote: >> Alex Williamson <alex.william...@redhat.com> wrote: >> > On Wed, 2010-06-16 at 17:47 +0200, Juan Quintela wrote: >> >> Anthony Liguori <anth...@codemonkey.ws> wrote: >> >> > On 06/14/2010 03:28 PM, Alex Williamson wrote: >> >> >> PCI hotplug currently doesn't work after a migration because >> >> >> we don't migrate the enable bits of the GPE state. Pull hotplug >> >> >> structs into vmstate. >> >> >> >> >> >> Signed-off-by: Alex Williamson<alex.william...@redhat.com> >> >> >> >> >> > >> >> > Applied. Thanks. >> >> > >> >> > Regards, >> >> > >> >> > Anthony Liguori >> >> >> >> I think this is better implemented as a subsection. We didin't need >> >> this until hotplug arrived, I think that checking if any up/down are >> >> != 0 and then send it as subsections is a best way to do it. >> >> >> >> This way it could also be backported to stable. >> > >> > The slots aren't really the issue, they were mostly for completeness. >> > The key is gpe.en, which is likely always going to be all 1s for an ACPI >> > aware OS. So if we test != 0, we're going to need that subsection in >> > 99% of the cases. Maybe we can assume gpe.en is all set on the target, >> > but I don't really look forward to finding out the ways that might >> > break. Thanks, >> >> We have never sent it before. That means that the default value (for >> whatever value is it) should be working quite well. > > The gpe.en bits back an ioport range that's poked by the guest via ACPI. > So the guest is the one telling ACPI "I enable you to send me this gpe". > When a hotplug event happens, we figure out which gpe line it would > toggle, set the matching gpe.sts bit, then if the OS has told us to > enable that bit, we send an interrupt. The OS then masks gpe.en, checks > gpe.sts, preforms actions and clears the respective gpe.sts bits, then > re-enables gpe.en. So, qemu never sets the bits, but if we decide to > clear (or set) them, we're interfering with how the OS expects them to > work. I think we're screwed, we need to bump the rev.
Sniff. I tried. Cross version migration is such a nice thing :( Later, Juan. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
