From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:42950) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SW5Hl-0000xV-H8 for qemu-devel@nongnu.org; Sun, 20 May 2012 08:30:58 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SW5Hj-0003Yg-Qw for qemu-devel@nongnu.org; Sun, 20 May 2012 08:30:57 -0400 Received: from mx1.redhat.com ([209.132.183.28]:39823) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SW5Hj-0003WX-J3 for qemu-devel@nongnu.org; Sun, 20 May 2012 08:30:55 -0400 Message-ID: <4FB8E3FA.2040408@redhat.com> Date: Sun, 20 May 2012 15:30:50 +0300 From: Avi Kivity MIME-Version: 1.0 References: <1337504620-20378-1-git-send-email-gleb@redhat.com> <1337504620-20378-3-git-send-email-gleb@redhat.com> <4FB8D933.5070800@redhat.com> <20120520121539.GJ10209@redhat.com> In-Reply-To: <20120520121539.GJ10209@redhat.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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: Gleb Natapov Cc: seabios@seabios.org, qemu-devel@nongnu.org On 05/20/2012 03:15 PM, Gleb Natapov wrote: > On Sun, May 20, 2012 at 02:44:51PM +0300, Avi Kivity wrote: > > On 05/20/2012 12:03 PM, Gleb Natapov wrote: > > > QEMU may want to disable guest's S3/S4 support and it wants to distinguish > > > between regular powerdown and S4 powerdown. To support that new fw_cfg > > > option was added that passes supported system states and what value should > > > guest use to enter each state. States are passed in 6 byte array. Each > > > byte represents one system state. If byte at offset X has its MSB set > > > it means that system state X is supported and to enter it guest should > > > use the value from lowest 7 bits. Patch also detects old QEMU and uses > > > values that work in backwards compatible way there. > > > > > > > > > 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. > Regardless, presence of _S3 name or method is all > that needed for OS enabling S3 option. If _S3 is defined as a method it > has to return Package() otherwise iasl refuses to compile it. Can't we Return (Package (...) { ... }) or equivalent? -- error compiling committee.c: too many arguments to function