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

[Jürgen Groß]

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



(Early PVH is running identity mapped, so it's offset from ffffffff80000000)



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);



That's as far as I got here.

vmcall is the Intel instruction, and vmmcall is the AMD one, so CPU detection is malfunctioning. 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. But it still calls xen_hypercall_intel().  So maybe x86_vendor isn't getting set and ends up as 0 (X86_VENDOR_INTEL)? 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

OpenPGP_0xB0DE9DD628BF132F.asc
Description: OpenPGP public key

OpenPGP_signature.asc
Description: OpenPGP digital signature