Re: [PATCH TEST-ARTEFACTS 0/8] Cleanup and Linux ARM64 support

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 10/04/2025 1:09 am, Jason Andryuk wrote:
> On 2025-04-09 13:01, Andrew Cooper wrote:
>> On 09/04/2025 5:36 pm, Andrew Cooper wrote:
>>> Various bits of cleanup, and support for arm64 Linux builds.
>>>
>>> Run using the new Linux 6.6.86 on (most) x86, and ARM64:
>>>   
>>> https://gitlab.com/xen-project/hardware/xen-staging/-/pipelines/1760667411
>>
>> Lovely, Linux 6.6.86 is broken for x86 PVH.  It triple faults very
>> early on.
>>
>> Sample log:
>> https://gitlab.com/xen-project/hardware/xen-staging/-/jobs/9673797450
>>
>> I guess we'll have to stay on 6.6.56 for now.  (Only affects the final
>> patch.)
>
> This is an AMD system:
>
> (XEN) [    2.577549] d0v0 Triple fault - invoking HVM shutdown action 1
> (XEN) [    2.577557] RIP:    0008:[<0000000001f851d4>]
>
> The instruction:
> ffffffff81f851d4:       0f 01 c1                vmcall
>
> vmcall is the Intel instruction, and vmmcall is the AMD one, so CPU
> detection is malfunctioning.
>
> (Early PVH is running identity mapped, so it's offset from
> ffffffff80000000)
>
> There are no debug symbols in the vmlinux I extracted from the bzImage
> from gitlab, but I can repro locally with on 6.6.86.  It's unclear to
> me why it's failing.
>
> Trying:
> diff --git i/arch/x86/xen/enlighten.c w/arch/x86/xen/enlighten.c
> index 0219f1c90202..fb4ad7fe3e34 100644
> --- i/arch/x86/xen/enlighten.c
> +++ w/arch/x86/xen/enlighten.c
> @@ -123,11 +123,10 @@ noinstr void *__xen_hypercall_setfunc(void)
>         if (!boot_cpu_has(X86_FEATURE_CPUID))
>                 xen_get_vendor();
>
> -       if ((boot_cpu_data.x86_vendor == X86_VENDOR_AMD ||
> -            boot_cpu_data.x86_vendor == X86_VENDOR_HYGON))
> -               func = xen_hypercall_amd;
> -       else
> +       if (boot_cpu_data.x86_vendor == X86_VENDOR_INTEL )
>                 func = xen_hypercall_intel;
> +       else
> +               func = xen_hypercall_amd;
>
>         static_call_update_early(xen_hypercall, func);
>
> But it still calls xen_hypercall_intel().  So maybe x86_vendor isn't
> getting set and ends up as 0 (X86_VENDOR_INTEL)?
>
> That's as far as I got here.
>
> Different but related, on mainline master, I also get a fail in
> vmcall. There, I see in the disassembly that
> __xen_hypercall_setfunc()'s calls to xen_get_vendor() is gone. 
> xen_get_vendor() seems to have been DCE-ed.  There is some new code
> that hardcodes features - "x86/cpufeatures: Add {REQUIRED,DISABLED}
> feature configs" - which may be responsible.

6.6.74 is broken too.  (That's the revision that the ARM tests want). 
So it broke somewhere between .56 and .74 which narrows the bisect a little.

https://gitlab.com/xen-project/hardware/xen-staging/-/pipelines/1761323774

In Gitlab, both AMD and Intel are failing in roughly the same way.

~Andrew