Re: [RESEND PATCH] acpi_piix4: save gpe and pci hotplug slot status

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Alex Williamson <alex.williamson@xxxxxxxxxx> wrote:
> On Wed, 2010-06-16 at 20:43 +0200, Juan Quintela wrote:
>> Alex Williamson <alex.williamson@xxxxxxxxxx> wrote:
>> > On Wed, 2010-06-16 at 17:47 +0200, Juan Quintela wrote:
>> >> Anthony Liguori <anthony@xxxxxxxxxxxxx> 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.williamson@xxxxxxxxxx>
>> >> >>    
>> >> >
>> >> > 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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux