linux-kernel - RE: [PATCH] x86/hyperv: Allow 15-bit APIC IDs for VTL platforms

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Wed, 10 Jan 2024 05:10:47 +0000
From: Michael Kelley <mhklinux@...look.com>
To: Saurabh Sengar <ssengar@...ux.microsoft.com>, "kys@...rosoft.com"
	<kys@...rosoft.com>, "haiyangz@...rosoft.com" <haiyangz@...rosoft.com>,
	"wei.liu@...nel.org" <wei.liu@...nel.org>, "decui@...rosoft.com"
	<decui@...rosoft.com>, "tglx@...utronix.de" <tglx@...utronix.de>,
	"mingo@...hat.com" <mingo@...hat.com>, "bp@...en8.de" <bp@...en8.de>,
	"dave.hansen@...ux.intel.com" <dave.hansen@...ux.intel.com>, "x86@...nel.org"
	<x86@...nel.org>, "hpa@...or.com" <hpa@...or.com>,
	"linux-hyperv@...r.kernel.org" <linux-hyperv@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
CC: "ssengar@...rosoft.com" <ssengar@...rosoft.com>
Subject: RE: [PATCH] x86/hyperv: Allow 15-bit APIC IDs for VTL platforms

From: Saurabh Sengar <ssengar@...ux.microsoft.com> Sent: Friday, January 5, 2024 2:29 AM
> 
> The current method for signaling the compatibility of a Hyper-V host
> with MSIs featuring 15-bit APIC IDs relies on a synthetic cpuid leaf.
> However, for higher VTLs, this leaf is not reported, due to the absence
> of an IO-APIC.
> 
> As an alternative, assume that when running at a high VTL, the host
> supports 15-bit APIC IDs. This assumption is now deemed safe, as no
> architectural MSIs are employed at higher VTLs.

I'm trying to fully understand this last sentence.  It has the words
"now" and "deemed" as qualifiers.  Can you say anything more about
why "now" (implying it wasn't safe at some point in the past)?
And what are the implications of "deemed"?  Or are both just
wordiness, and it would be just as good to say "This assumption is safe,
as Hyper-V does not employ any architectural MSIs at higher VTLs." ?

The code LGTM.

Michael

> 
> This unblocks startup of VTL2 environments with more than 256 CPUs.
> 
> Signed-off-by: Saurabh Sengar <ssengar@...ux.microsoft.com>
> ---
>  arch/x86/hyperv/hv_vtl.c | 7 +++++++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/arch/x86/hyperv/hv_vtl.c b/arch/x86/hyperv/hv_vtl.c
> index 539c7b5cfa2b..1c225362f88e 100644
> --- a/arch/x86/hyperv/hv_vtl.c
> +++ b/arch/x86/hyperv/hv_vtl.c
> @@ -16,6 +16,11 @@
>  extern struct boot_params boot_params;
>  static struct real_mode_header hv_vtl_real_mode_header;
> 
> +static bool __init hv_vtl_msi_ext_dest_id(void)
> +{
> +	return true;
> +}
> +
>  void __init hv_vtl_init_platform(void)
>  {
>  	pr_info("Linux runs in Hyper-V Virtual Trust Level\n");
> @@ -39,6 +44,8 @@ void __init hv_vtl_init_platform(void)
>  	x86_platform.legacy.warm_reset = 0;
>  	x86_platform.legacy.reserve_bios_regions = 0;
>  	x86_platform.legacy.devices.pnpbios = 0;
> +
> +	x86_init.hyper.msi_ext_dest_id = hv_vtl_msi_ext_dest_id;
>  }
> 
>  static inline u64 hv_vtl_system_desc_base(struct ldttss_desc *desc)
> --
> 2.25.1
>