qemu-devel
[Top][All Lists]
Advanced

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

[Qemu-devel] Re: [RESEND PATCH] acpi_piix4: save gpe and pci hotplug slo


From: Juan Quintela
Subject: [Qemu-devel] Re: [RESEND PATCH] acpi_piix4: save gpe and pci hotplug slot status
Date: Thu, 17 Jun 2010 01:05:54 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux)

Alex Williamson <address@hidden> wrote:
> On Wed, 2010-06-16 at 20:43 +0200, Juan Quintela wrote:
>> Alex Williamson <address@hidden> wrote:
>> > On Wed, 2010-06-16 at 17:47 +0200, Juan Quintela wrote:
>> >> Anthony Liguori <address@hidden> 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<address@hidden>
>> >> >>    
>> >> >
>> >> > 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.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]