Re: [PATCH 00/21] x86: Trenchboot Secure Launch DRTM (Xen)

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 23/04/2025 7:45 pm, Sergii Dmytruk wrote:
> On Wed, Apr 23, 2025 at 02:38:37PM +0100, Andrew Cooper wrote:
>> On 22/04/2025 6:14 pm, Andrew Cooper wrote:
>>> I've stripped out the sha2 patch and fixed up to use the existing sha2,
>>> then kicked off some CI testing:
>>>
>>> https://gitlab.com/xen-project/hardware/xen-staging/-/pipelines/1780285393
>>> https://cirrus-ci.com/build/5452335868018688
>>>
>>> When the dust has settled, I'll talk you through the failures.
>> And here we go.  Interestingly, the FreeBSD testing was entirely happy,
>> and that is the rare way around.
>>
>> For Gitlab, there are several areas.
>>
>> First, for MISRA.  In the job logs, you want the "Browse current
>> reports:" link which will give you full details, but it's all pretty
>> simple stuff.
> Thanks, but that link gives me a list of 5096 failures all over the code
> base.  Is there any way to see a diff against master?

No sadly not.  What you see is a mix of the blocking issues, and the "we
want to see these so we can work on them".

Immediately under the link is the one-line tl;dr.  For ARM, it's just a
single:

Failure: 1 regressions found for clean guidelines
  service MC3A2.R7.2: (required) A `u' or `U' suffix shall be applied to
all integer constants that are represented in an unsigned type:
   violation: 1

Clicking through into the R7.2 analysis shows
https://saas.eclairit.com:3787/fs/var/local/eclair/xen-project.ecdf/xen-project/hardware/xen-staging/ECLAIR_normal/andrew/tb-v1.1/ARM64/9791028027/PROJECT.ecd;/by_service/MC3A2.R7.2.html

This violation is shared with x86 because it's a header pulled into a
common file.

For x86, the list is rather longer.  You've got:

6x D1.1
2x D4.14
1x R5.3
116x R7.2
1x R7.3
12x R8.3
7x R8.4
1x R11.9
87x R20.7

These are the blocking directives/rules.  Others which you see in the
overall report are non-blocking.

>
>> kbl-suspend-x86-64-gcc-debug is a real S3 test on KabyLake hardware,
>> which appears to have gone to sleep and never woken up.  (More likely,
>> crashed on wakeup before we got the console up).  The AlderLake
>> equivalent test seems to be happy, as well as the AMD ones.
> Hm, not sure what that could be, but will try to reproduce/guess.

KBL is unreliable in one specific way, but not with these symptoms.

I reran the suspend test, and it failed in the same way.  I think it's a
deterministic bug.

I can probably dig out my emergency serial debugging patches for S3 if
you want?

>> Other common failures seem to be:
>>
>>     # take image offset into account
>>     arch/x86/efi/fixmlehdr xen.efi 0x200000
>>     Failed to find MLE header in xen.efi
>>     arch/x86/Makefile:220: recipe for target 'xen.efi' failed
>>     make[3]: *** [xen.efi] Error 1
>>
>> ~Andrew
> That seems to be the only reason behind the rest of build failures.
> I was able to reproduce the failure in Fedora 37 docker.  Searching for
> the header in 8KiB instead of 4KiB fixes it.  Looks like large default
> alignment of some toolchains pushes `head.S` to 4 KiB offset.

FYI, you can access all the Xen containers with:

CONTAINER=foo ./automation/scripts/containerize

in the xen.git tree.

Alignment that large is unexpected, and I suspect we want to fix it.  Is
it pre-existing, or something introduced by your series?

~Andrew