From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:43692) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vsfcy-0002TW-Cb for qemu-devel@nongnu.org; Mon, 16 Dec 2013 16:23:06 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Vsfcs-0004GK-A6 for qemu-devel@nongnu.org; Mon, 16 Dec 2013 16:23:00 -0500 Received: from mx1.redhat.com ([209.132.183.28]:3473) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vsfcs-0004G9-2B for qemu-devel@nongnu.org; Mon, 16 Dec 2013 16:22:54 -0500 Message-ID: <52AF6F20.6030507@redhat.com> Date: Mon, 16 Dec 2013 22:22:40 +0100 From: Laszlo Ersek MIME-Version: 1.0 References: <1386951736-929-1-git-send-email-imammedo@redhat.com> <1386951736-929-10-git-send-email-imammedo@redhat.com> <20131216193014.GC21330@redhat.com> <20131216213819.48568028@thinkpad> <52AF6CFA.3030307@redhat.com> In-Reply-To: <52AF6CFA.3030307@redhat.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 09/11] ACPI: move PRST OperationRegion into SSDT List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Igor Mammedov Cc: stefanha@redhat.com, "Michael S. Tsirkin" , hutao@cn.fujitsu.com, qemu-devel@nongnu.org, brogers@suse.com, kraxel@redhat.com, aliguori@amazon.com, kaneshige.kenji@jp.fujitsu.com, chen.fan.fnst@cn.fujitsu.com, pbonzini@redhat.com, jjherne@us.ibm.com On 12/16/13 22:13, Laszlo Ersek wrote: > On 12/16/13 21:38, Igor Mammedov wrote: >> On Mon, 16 Dec 2013 21:30:14 +0200 >> "Michael S. Tsirkin" wrote: >> >>> On Fri, Dec 13, 2013 at 05:22:14PM +0100, Igor Mammedov wrote: >>>> .. and report range used by it to OSPM via _CRS. >>>> PRST is needed in SSDT since its base will depend on >>>> chipset and will be dynamically set by QEMU. >>>> Also move PRSC() method along with PRST since cross >>>> table reference to PRST doesn't work. >>> >>> Could you clarify this last sentence? >>> I don't mind where it is but I'd like to know >>> where does the limitation come from. >> It's empiric deduction so far I haven't found such limitation in spec yet. >> iasl builds tables just fine but neither linux nor windows were able to find >> Operation region from SSDT when loading DSDT, failing whole table loading >> process. Decompiling DSDT/SSDT tables in guest shows that region is in >> expected scope but OSPM refuses to see it when referenced outside SSDT. > > There seem to be four things here: > - the OperationRegion definition, > - its external declaration, > - the Field() declaration, > - use of fields. > > I think referencing an OperationRegion defined in another table should > work (by way of External). I suspect the tricky part is with Field(): > > The fields are parts of the object named by RegionName, but their > names appear in the same scope as the Field term. > > So, > - maybe moving PRST only, and leaving the definition of PRS (as part of > Field()) together with PRSC would suffice, I think this might be exactly what we don in OVMF's builtin tables. (I could of course fully misinterpret the situation.) In the DSDT we have a _CRS method that includes: - External (FWDT, OpRegionObj) - Field(FWDT, QWordAcc, NoLock, Preserve) { ... fields ... } - accesses to these fields In the SSDT we have: - OperationRegion(FWDT, ...) So I guess: - you could put the PRST in the SSDT (this is the goal), - you could keep the PRSC method in DSDT, - but an External reference and the PRS field declaration would also have to remain in DSDT. Laszlo