[RFC][PATCH 01/34] x86/xen: Explain why calling get_cpu_cap() so early is a hack

Dave Hansen
2024-02-22T18:39:28Z

xen_start_kernel() some of the first C code run "Xen PV" systems.
It precedes normally very early things like setup_arch() or the
processor initialization code.

That means that 'boot_cpu_data' is garbage. It has not even
established the utter basics like if the CPU supports the CPUID
instruction. Unfortunately get_cpu_cap() requires this exact
information.

Nevertheless xen_start_kernel() calls get_cpu_cap(). But it
works out in practice because it's looking for the NX bit which
comes from an extended CPUID leaf that doesn't depend on
c->cpuid_level being set. This also implicitly assumes that
Xen PV guests support CPUID.

Leave the hack in place, but at least explain some of what is
going on.

Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com>
Cc: Juergen Gross <jgross@suse.com>
---

b/arch/x86/xen/enlighten_pv.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)

diff -puN arch/x86/xen/enlighten_pv.c~xen-explain1 arch/x86/xen/enlighten_pv.c
--- a/arch/x86/xen/enlighten_pv.c~xen-explain1 2024-02-22 10:08:48.404451146 -0800
+++ b/arch/x86/xen/enlighten_pv.c 2024-02-22 10:08:48.404451146 -0800
@@ -1372,7 +1372,11 @@ asmlinkage __visible void __init xen_sta
/* Get mfn list */
xen_build_dynamic_phys_to_machine();

- /* Work out if we support NX */
+ /*
+ * This is a hack. 'boot_cpu_data' is not filled out enough
+ * for get_cpu_cap() to function fully. But it _can_ fill out
+ * the leaves where NX is. Gross, but it works.
+ */
get_cpu_cap(&boot_cpu_data);
x86_configure_nx();

_