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

[Sergii Dmytruk <sergii.dmytruk@xxxxxxxxx>]

On Wed, Apr 23, 2025 at 11:43:15PM +0100, Andrew Cooper wrote:
> 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".

Nicola Vetrini explained how some errors can be filtered in
https://lore.kernel.org/xen-devel/c2940798-11d0-4aaa-a013-64bef9bbdb82@xxxxxxxxxxxxxxxxxxxx/T/#m153e1cf8a6ef37d3d301253624c07fa3c25814c2
At least in this case it works when done correctly.

> >> 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?

Thanks, I'll try to come up with something first.  So far I thought
about a change in how stack is picked for APs, but I would expect all
hardware to have issues with S3 if that was the problem.

> >> 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.

Thanks, that looks more convenient.

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

Pre-existing one.  I can see `-N` is already passed to `ld`:

-N, --omagic     Do not page align data, do not make text readonly

Specifying `--section-alignment 512 --file-alignment 512 --nmagic`
didn't reduce the alignment.  Statistics so far:

  Give 0x1000 offset:
  GNU ld (GNU Binutils for Debian) 2.31.1
  GNU ld version 2.38-27.fc37

  Give 0x440 offset:
  GNU ld (GNU Binutils for Debian) 2.40
  GNU ld (GNU Binutils for Debian) 2.41

Maybe that's not something configurable and just needs a newer version.