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

[Jürgen Groß <jgross@xxxxxxxx>]

On 10.04.25 02:09, 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.
The test for !X86_FEATURE_CPUID will probably never be true now.

I guess the most simple fix will be to just call xen_get_vendor()
unconditionally.


Juergen

Attachment: OpenPGP_0xB0DE9DD628BF132F.asc
Description: OpenPGP public key

Attachment: OpenPGP_signature.asc
Description: OpenPGP digital signature