Question about rsdp test?

[Al Stone]

On 07/21/2016 07:25 AM, Colin Ian King wrote:
> On 21/07/16 02:34, Dong, Eric wrote:
>>> On 07/20/2016 01:02 AM, Dong, Eric wrote:
>>>> Hi Alex,
>>>>
>>>> We are using the UEFI code. In UEFI code, it uses both Rsdt and Xsdt. I check the ACPI spec and found below info: (Excerpt from ACPI
>>> spec 6.0 page 113)
>>>> 	Platforms provide the RSDT to enable compatibility with ACPI 1.0 operating systems. The XSDT, described in the next section,
>>> supersedes RSDT functionality.
>>>>
>>>> So base on this, I think UEFI code is ok and Fwts should not do such check.
>>>
>>> Right.  That is what the spec says.  I think Alex's question was different,
>>> though, and something the spec does not address.
>>>
>>
>> I think if the spec not has clear description, the Fwts tool should not add such check base on some of the current implementation.

We'll have to disagree, then.  I see FWTS as a tool to help me make sure that
my firmware and my OS can work together properly.  If that means that we have
to adapt to what actually gets shipped, or de facto standards that are not
part of the spec, that's just reality.

>>> The test being referred to below is saying that the RSDT and XSDT addresses
>>> are different.  It is okay to use both addresses.  But, if they are different,
>>> which one is the correct one for the OS?  There is no way to know, and the
>>> spec does not tell us, so this is an error.
>>>
>>
>> I think it depend on what ACPI version this OS support. If the OS supports ACPI 1.0 version, it can use the RSDT, else it use XSDT.
>>  
>> For the UEFI code, I think it just wants to support different OS with same image. So it use RSDT and XSDT both with different value.  If the OS supports ACPI 1.0, it can use RSDT, else it can use XSDT. I think the UEFI solution is correct and make sense.

Again, the test is not saying you cannot use RSDT.  The test is saying you
can use RSDT, or you can use XSDT, or you can use both, but I expect the
addresses to be consistent.  If they are not, this often presents a really
big problem for the OS.

The firmware that I have seen that works properly has a 32-bit address in
RSDT and the same address in XSDT, even though it is 64-bit.  When the OS
sees this, it can use either pointer since they both point to exactly the
same ACPI table data.

The firmware that I have seen that is broken is when RSDT != XSDT.  In those
cases, the 32-bit ACPI tables had different content from the 64-bit tables,
and in one case, the 32-bit data had never been tested.  What's more, the
tables were written saying they only needed ACPI 1.0, which was a slightly
different mistake since parts of the DSDT used ACPI 5.0 features.  So, this
test was written so the OS would not have to workaround buggy firmware that
is known to exist -- which is what I thought was the point of using FWTS.

I still have to disagree; I believe the UEFI implementation is not quite right
and creating tables that can or will cause trouble with an OS later on.

> Given the case we have some ambiguity here, I think the way forward is
> to remove the failure mode from the test and replace it with some
> warning and NOT report an error, e.g. something like:
> 
> fwts_log_warning(fw, "Note: The RSDT and XSDT are both defined. An "
> 	"OS supporting ACPI 1.0 should use the RSDT, otherwise the "
> 	"OS will use the XSDT. RSDT = 0x%" PRIu32 "x, "
> 	"XSDT = 0x%" PRIu64,
> 	rsdp->rsdt_address, rsdp->xsdt_address);
> 
> If that sounds sane I'll send a patch.
> 
> Colin
> 

WFM.  I disagree that it's ambiguous :), but I can live with it if
there's at least this warning.  Thanks, Colin.

-- 
ciao,
al
-----------------------------------
Al Stone
Software Engineer
Linaro Enterprise Group
al.stone at linaro.org
-----------------------------------