From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:51217) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vsg9c-0007De-LT for qemu-devel@nongnu.org; Mon, 16 Dec 2013 16:56:50 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Vsg9P-0005XX-Rj for qemu-devel@nongnu.org; Mon, 16 Dec 2013 16:56:44 -0500 Received: from mx1.redhat.com ([209.132.183.28]:17309) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vsg9P-0004zG-G8 for qemu-devel@nongnu.org; Mon, 16 Dec 2013 16:56:31 -0500 Date: Mon, 16 Dec 2013 22:53:24 +0100 From: Igor Mammedov Message-ID: <20131216225324.18c52bf9@thinkpad> In-Reply-To: <52AF6CFA.3030307@redhat.com> 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> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII 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: Laszlo Ersek 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 Mon, 16 Dec 2013 22:13:30 +0100 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(): ^^^ it looks like it should work and decompiled tables look fine as well but it unfortunately doesn't. > > 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, That was the first thing I've tried. > - 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.) yep, that didn't work too. I'm not fun of moving a bunch of code around, but looks like there is no other way. I'd be happy to try if there are any other suggestions. > > Laszlo > -- Regards, Igor