NetBSD-Bugs archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: kern/59371 (Xen domU uvm_fault since FPU state allocation patch)



Synopsis: Xen domU uvm_fault since FPU state allocation patch

State-Changed-From-To: open->analyzed
State-Changed-By: riastradh%NetBSD.org@localhost
State-Changed-When: Mon, 28 Apr 2025 12:46:46 +0000
State-Changed-Why:
This happens because amd64 defines __HAVE_CPU_UAREA_ROUTINES only under
#if !defined(XENPV):

    114 #if defined(__x86_64__) && !defined(XENPV)
    115 #if !defined(KASAN) && !defined(KMSAN)
    116 #define	__HAVE_PCPU_AREA 1
    117 #define	__HAVE_DIRECT_MAP 1
    118 #endif
    119 #define	__HAVE_CPU_UAREA_ROUTINES 1
    120 #endif

https://nxr.netbsd.org/xref/src/sys/arch/amd64/include/types.h?r=1.71#114

So the logic in x86/vm_machdep.c's cpu_uarea_alloc/free to initialize
the FPU save area of a newly allocated uarea doesn't kick in.  It's not
clear to me why separate uarea allocation is disabled under XENPV --
they were introduced by maxv@ for a stack guard page (`redzone') back
in March 2020:

https://mail-index.netbsd.org/port-amd64/2020/03/14/msg003179.html
https://mail-index.netbsd.org/source-changes/2020/03/17/msg115178.html

--- a/sys/arch/amd64/include/types.h
+++ b/sys/arch/amd64/include/types.h
...
@@ -114,10 +114,11 @@ typedef   unsigned char           __cpu_simple_lock_nv_t;
 #if defined(__x86_64__) && !defined(XENPV)
 #if !defined(KASAN) && !defined(KMSAN)
 #define        __HAVE_PCPU_AREA 1
 #define        __HAVE_DIRECT_MAP 1
 #endif
+#define        __HAVE_CPU_UAREA_ROUTINES 1
 #if !defined(NO_PCI_MSI_MSIX)
 #define        __HAVE_PCI_MSI_MSIX
 #endif
 #endif

It's possible maxv@ just didn't want to think about XENPV implications
or test it.  It's possible that the guard page works badly in XENPV for
some reason, or somehow hurts performance, I dunno.

So, as a stop-gap measure, let's first just use the same approach as
i386 (no pointer to savefpu area, disable Intel AMX), and then think
about enabling the guard page -- and if the guard page doesn't work for
some reason, we can either leave it at that or make the uarea routine
skip the guard page under XENPV.





Home | Main Index | Thread Index | Old Index