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
