[Top][All Lists]
[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.