From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:41582) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VsfUH-0006f6-DH for qemu-devel@nongnu.org; Mon, 16 Dec 2013 16:14:07 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VsfUA-0001YL-KK for qemu-devel@nongnu.org; Mon, 16 Dec 2013 16:14:01 -0500 Received: from mx1.redhat.com ([209.132.183.28]:5311) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VsfUA-0001YF-CC for qemu-devel@nongnu.org; Mon, 16 Dec 2013 16:13:54 -0500 Message-ID: <52AF6CFA.3030307@redhat.com> Date: Mon, 16 Dec 2013 22:13:30 +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> In-Reply-To: <20131216213819.48568028@thinkpad> 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 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, - or, after moving the definition of PRS (as part of Field()) together with PRST to another table, all references to PRS (in the PRSC method) would have to be qualified. (But I guess this is what you tried.) Laszlo