On 12/16/13 21:38, Igor Mammedov wrote:
> On Mon, 16 Dec 2013 21:30:14 +0200
> "Michael S. Tsirkin" <m...@redhat.com> 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
