qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 09/11] ACPI: move PRST OperationRegion into SSDT


From: Laszlo Ersek
Subject: Re: [Qemu-devel] [PATCH 09/11] ACPI: move PRST OperationRegion into SSDT
Date: Mon, 16 Dec 2013 22:22:40 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20131118 Thunderbird/17.0.11

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" <address@hidden> 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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]