From mboxrd@z Thu Jan 1 00:00:00 1970 From: Juan Quintela Subject: Re: [RESEND PATCH] acpi_piix4: save gpe and pci hotplug slot status Date: Thu, 17 Jun 2010 01:05:54 +0200 Message-ID: References: <20100614202803.5259.85808.stgit@localhost.localdomain> <4C1697F3.3090107@codemonkey.ws> <1276705730.12015.964.camel@x201> <1276715664.12015.974.camel@x201> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: blauwirbel@gmail.com, qemu-devel@nongnu.org, kvm@vger.kernel.org To: Alex Williamson Return-path: Received: from mx1.redhat.com ([209.132.183.28]:11942 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755881Ab0FPXF7 (ORCPT ); Wed, 16 Jun 2010 19:05:59 -0400 In-Reply-To: <1276715664.12015.974.camel@x201> (Alex Williamson's message of "Wed, 16 Jun 2010 13:14:24 -0600") Sender: kvm-owner@vger.kernel.org List-ID: Alex Williamson wrote: > On Wed, 2010-06-16 at 20:43 +0200, Juan Quintela wrote: >> Alex Williamson wrote: >> > On Wed, 2010-06-16 at 17:47 +0200, Juan Quintela wrote: >> >> Anthony Liguori 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 >> >> >> >> >> > >> >> > 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.