[RFC] SBBR Test Case Additions to FWTS

[Jeffrey Hugo]

On 1/10/2017 11:17 AM, Leif Lindholm wrote:
> Hi Jeffrey,
>
> On Tue, Jan 10, 2017 at 11:00:19AM -0700, Jeffrey Hugo wrote:
>>> Once, the above two questions have been answered and we arrive at a
>>> solution which is easier to maintain, will send out a list of patches
>>> related to SBBR.
>>>
>>> Thanks in advance for your inputs.
>>
>> Can you elaborate on the motivation for adding SBBR compliance to FWTS?
>>
>> SBBR is ARM specific, yet FWTS is architecture agnostic in its purpose.
>> While my primary interest is ARM, it sounds like to add SBBR testing to FWTS
>> requires the addition of a bunch of ARM specific tweaks that don't play well
>> with other architectures.  Greater ARM support is nice, but not at the cost
>> of not playing well with others.
>
> To clarify - this isn't a "test all of SBBR compliance using FWTS"
> thing, it's a "test the bits that FWTS are already looking for, but
> make the absence of certain tables result in reported test failures".

Hmm, I guess my perception of running the SBBR compliance testing is not 
accurate.

Being that SBBR is ARM specific, and not even all ARM systems need to 
conform to SBBR as its a server specification (ie an ARM phone SoC), I 
personally do not feel as though changing the default behavior of FWTS 
is what I would like to see.

SPCR for example, is an optional table per my reading of the ACPI spec. 
Therefore, I believe FWTS does the correct thing, today.  Since SBBR 
adds additional requirements, ie requires SPCR to be implemented, and 
and only applies to a small subset of FWTS consumers, then I feel that 
SBBR testing in FWTS should be an explicit thing that the user invokes - 
an "expert option" if you will.

Off the top of my head, it would probably be more useful to me if SBBR 
were a separate test within FWTS (ie "fwts sbbr"), but a command line 
switch ("fwts --sbbr") seems acceptable to me.  Given that it sounds 
like FWTS does 95% of what you want already, the command line switch may 
be easier to implement.

I guess that is a partial answer from be concerning Question 1 posed by 
Supreeth.  I would prefer option 1B.  I would not advise a separate 
branch as that seems to be a lot of cost for no real benefit as far as I 
can tell.

Regarding question 2, I'm not sure what the issue with the SMBIOS test 
is, it currently works on our ARM64 platform.  If the issue is specific 
to the ARM arch as a whole, then compile time separation seems 
appropriate, however if the issue is specific to SBBR testing, then the 
switch should be done based on the fact that the user requested SBBR 
testing, since the issue won't apply to all platforms as discussed above.

I think I'd need to see code addressing the issue with SMBIOS to comment 
more.

>
> The other part of SBBR compliance validation runs in a UEFI SCT
> context.
>
>> Additionally, ARM (the company) has already published a SBBR compliance test
>> at https://github.com/ARM-software/arm-enterprise-acs
>>
>> Why duplicate that in FWTS?
>
> Because that compliance test is based to a larger extent on FWTS and
> ARM does not want to maintain a non-upstream branch in perpetuity if
> it can be avoided.
>
> This pre-RFC is for investigating possibilities for getting away from
> carrying patches against FWTS as part of that compliance test suite.
>

Ah, sadly I haven't currently dug into the compliance test as much as I 
would like.  I see, so the test currently has a fork of FWTS, and you'd 
prefer to be using mainline for reasons which are now obvious. 
Motivation sufficiently explained.  Thank you.

As a FWTS user, I'm interested to see where this goes.  I'm looking 
forward to seeing patches.

-- 
Jeffrey Hugo
Qualcomm Datacenter Technologies as an affiliate of Qualcomm 
Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the
Code Aurora Forum, a Linux Foundation Collaborative Project.