From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:32942) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SW7MF-0008Oj-Ma for qemu-devel@nongnu.org; Sun, 20 May 2012 10:43:45 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SW7MD-0006m7-PE for qemu-devel@nongnu.org; Sun, 20 May 2012 10:43:43 -0400 Received: from mx1.redhat.com ([209.132.183.28]:45949) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SW7MD-0006m2-H8 for qemu-devel@nongnu.org; Sun, 20 May 2012 10:43:41 -0400 Date: Sun, 20 May 2012 17:43:38 +0300 From: Gleb Natapov Message-ID: <20120520144338.GO10209@redhat.com> References: <1337504620-20378-3-git-send-email-gleb@redhat.com> <4FB8D933.5070800@redhat.com> <20120520121539.GJ10209@redhat.com> <4FB8E3FA.2040408@redhat.com> <20120520123633.GL10209@redhat.com> <4FB8E7C6.5090000@redhat.com> <20120520125936.GM10209@redhat.com> <4FB8F3F5.6010903@redhat.com> <20120520135733.GN10209@redhat.com> <4FB90110.1000003@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4FB90110.1000003@redhat.com> Subject: Re: [Qemu-devel] [PATCH 3/3] Get system state configuration from QEMU and patch DSDT with it. List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Avi Kivity Cc: seabios@seabios.org, qemu-devel@nongnu.org On Sun, May 20, 2012 at 05:34:56PM +0300, Avi Kivity wrote: > On 05/20/2012 04:57 PM, Gleb Natapov wrote: > > On Sun, May 20, 2012 at 04:39:01PM +0300, Avi Kivity wrote: > > > On 05/20/2012 03:59 PM, Gleb Natapov wrote: > > > > > > > > > > > > > > > > > > Do we actually have to patch the DSDT? Or can _S3 etc be made into > > > > > > > > > functions instead? (and talk to the bios, or even to fwcfg directly?) > > > > > > > > > > > > > > > > > We better not talk to fwcfg after OSPM is started since this is firmware > > > > > > > > confing interface. > > > > > > > > > > > > > > Why not? The OS isn't going to talk to it, so we can have a driver in ACPI. > > > > > > > > > > > > > The OS is going to talk to it since the OS is the one who interprets > > > > > > AML. > > > > > > > > > > I meant, not directly. So the driver in ACPI has exclusive access. > > > > > > > > > What's the difference? > > > > > > ACPI is firmware, not OS. > > AML is a data provided by firmware. AML's runtime is different from firmware's. > > It's still firmware. > We have to agree to disagree here :) It's just a data for OS to use as far as I am concern. > > > > > > > > > > It's an alternative to patching AML. Sure it takes some effort to write > > > > > the driver, but afterwards we can modify the guest behaviour more > > > > > easily. One possible client is -M old, so you can revert to previous > > > > > behaviour depending on fwcfg data. > > > > -M old is easy to support with the current patch. You just set new > > > > properties to compatibility values. The code is written with this in > > > > mind. And this is not an alternative to patching AML as I am trying to > > > > explain to you below. You can eliminate patching of s4 value, but that's > > > > it, you still need to patch out _S3/_S4 names. > > > > > > What about > > > > > > If (Fcfg(...)) { > > > Method()... > > > } > > > > > > ? > > syntax error, unexpected PARSEOP_IF > > Unfortunately the ACPI spec forbids this construct, so either patching > or double complication is necessary. > It's not double if we will take all possible combinations into account. > > > > > > (i.e.. define the method conditionally at runtime) > > > > > > > > > > > > > > > > > (we don't need a driver in AML to avoid patching, we can have AML talk > > > > > to the bios and the bios drive fwcfg; but I think we'll find uses for a > > > > > driver). > > > > I am not sure what you mean. AML can't talk to the bios. It can read > > > > values that bios put somewhere. > > > > > > That's what I meant - communicate through memory. > > > > > What's the benefit? The patching is still needed. You need to pass > > address of OperationRegion() to AML. You can do it either by patching or > > by creating OperationRegion() code dynamically. > > Or it can be a fixed address in low memory, or a scratch register in > hardware. > Both will work (fixed addresses are better be avoided and who needs another PV device), but I do not see how either of them is better then patching. What is your concern? > > > > > > I do not see advantage of this method > > > > and it requires patching still. > > > > > > For the existence of the names? Yes, if we can't avoid it it's a > > > problem. But if we can avoid patching, we should. > > > > > If we can, we should, but we can't as far as I see. The patching was here long before > > this patch. > > I agree we probably can't. > > -- > error compiling committee.c: too many arguments to function -- Gleb.