Received-SPF: pass (google.com: domain of linux-kernel+bounces-95858-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:40f1:3f00::1 as permitted sender) client-ip=2604:1380:40f1:3f00::1;
Date: Thu, 7 Mar 2024 17:27:52 +0100
From: Borislav Petkov <bp@alien8.de>
To: Dave Hansen <dave.hansen@linux.intel.com>
Cc: linux-kernel@vger.kernel.org, kirill.shutemov@linux.intel.com,
	pbonzini@redhat.com, tglx@linutronix.de, x86@kernel.org,
	jgross@suse.com
Subject: Re: [RFC][PATCH 01/34] x86/xen: Explain why calling get_cpu_cap() so
 early is a hack
Message-ID: <20240307162752.GAZenrCDqs0lMTjmu1@fat_crate.local>
References: <20240222183926.517AFCD2@davehans-spike.ostc.intel.com>
 <20240222183928.0D8942B2@davehans-spike.ostc.intel.com>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <20240222183928.0D8942B2@davehans-spike.ostc.intel.com>

On Thu, Feb 22, 2024 at 10:39:28AM -0800, Dave Hansen wrote:
> 
> From: Dave Hansen <dave.hansen@linux.intel.com>
> 
> xen_start_kernel() some of the first C code run "Xen PV" systems.

That sentence reads weird.

> 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

s/is/contains/

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

If all it needs is to figure out whether it supports NX, just do that by
foot here and get rid of the get_cpu_cap(&boot_cpu_data) call
completely.

It won't be a hack anymore.

Thx.

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette