> -----Original Message----- > From: Saurabh Singh Sengar <ssengar@xxxxxxxxxxxxxxxxxxx> > Sent: Monday, March 13, 2023 10:02 AM > To: Vitaly Kuznetsov <vkuznets@xxxxxxxxxx> > Cc: tglx@xxxxxxxxxxxxx; mingo@xxxxxxxxxx; bp@xxxxxxxxx; > dave.hansen@xxxxxxxxxxxxxxx; x86@xxxxxxxxxx; hpa@xxxxxxxxx; KY Srinivasan > <kys@xxxxxxxxxxxxx>; Haiyang Zhang <haiyangz@xxxxxxxxxxxxx>; > wei.liu@xxxxxxxxxx; Dexuan Cui <decui@xxxxxxxxxxxxx>; arnd@xxxxxxxx; > Tianyu Lan <Tianyu.Lan@xxxxxxxxxxxxx>; Michael Kelley (LINUX) > <mikelley@xxxxxxxxxxxxx>; linux-kernel@xxxxxxxxxxxxxxx; linux- > hyperv@xxxxxxxxxxxxxxx; linux-arch@xxxxxxxxxxxxxxx > Subject: Re: [PATCH v2 2/2] x86/hyperv: VTL support for Hyper-V > > On Mon, Mar 13, 2023 at 03:45:02PM +0100, Vitaly Kuznetsov wrote: > > Saurabh Sengar <ssengar@xxxxxxxxxxxxxxxxxxx> writes: > > > > > Virtual Trust Levels (VTL) helps enable Hyper-V Virtual Secure Mode > > > (VSM) feature. VSM is a set of hypervisor capabilities and > > > enlightenments offered to host and guest partitions which enable the > > > creation and management of new security boundaries within operating > system software. > > > VSM achieves and maintains isolation through VTLs. > > > > > > Add early initialization for Virtual Trust Levels (VTL). This > > > includes initializing the x86 platform for VTL and enabling boot > > > support for secondary CPUs to start in targeted VTL context. For > > > now, only enable the code for targeted VTL level as 2. > > > > > > When starting an AP at a VTL other than VTL 0, the AP must start > > > directly in 64-bit mode, bypassing the usual 16-bit -> 32-bit -> > > > 64-bit mode transition sequence that occurs after waking up an AP > > > with SIPI whose vector points to the 16-bit AP startup trampoline code. > > > > > > This commit also moves hv_get_nmi_reason function to header file, so > > > that it can be reused by VTL. > > > > > > Signed-off-by: Saurabh Sengar <ssengar@xxxxxxxxxxxxxxxxxxx> > > > --- > > > arch/x86/Kconfig | 24 +++ > > > arch/x86/hyperv/Makefile | 1 + > > > arch/x86/hyperv/hv_vtl.c | 227 +++++++++++++++++++++++++++++ > > > arch/x86/include/asm/hyperv-tlfs.h | 75 ++++++++++ > > > arch/x86/include/asm/mshyperv.h | 14 ++ > > > arch/x86/kernel/cpu/mshyperv.c | 6 +- > > > include/asm-generic/hyperv-tlfs.h | 4 + > > > > This patch is quite big, I'd suggest you split it up. E.g. TLFS > > definitions can easily be a separate patch. Moving hv_get_nmi_reason() > > can be a separate patch. Secondary CPU bringup can be a separate > > patch. The new config option to enable the feature (assuming it is > > really needed) can be the last separate patch. > > Ok will do in next version. > > > > > > 7 files changed, 346 insertions(+), 5 deletions(-) create mode > > > 100644 arch/x86/hyperv/hv_vtl.c > > > > > > diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig index > > > 453f462f6c9c..b9e52ac9c9f9 100644 > > > --- a/arch/x86/Kconfig > > > +++ b/arch/x86/Kconfig > > > @@ -782,6 +782,30 @@ menuconfig HYPERVISOR_GUEST > > > > > > if HYPERVISOR_GUEST > > > > > > +config HYPERV_VTL > > > + bool "Enable VTL" > > > + depends on X86_64 && HYPERV > > > + default n > > > + help > > > + Virtual Secure Mode (VSM) is a set of hypervisor capabilities and > > > + enlightenments offered to host and guest partitions which enables > > > + the creation and management of new security boundaries within > > > + operating system software. > > > + > > > + VSM achieves and maintains isolation through Virtual Trust Levels > > > + (VTLs). Virtual Trust Levels are hierarchical, with higher levels > > > + being more privileged than lower levels. VTL0 is the least privileged > > > + level, and currently only other level supported is VTL2. > > > + > > > + Select this option to build a Linux kernel to run at a VTL other than > > > + the normal VTL 0, which currently is only VTL 2. This option > > > + initializes the x86 platform for VTL 2, and adds the ability to boot > > > + secondary CPUs directly into 64-bit context as required for VTLs other > > > + than 0. A kernel built with this option must run at VTL 2, and will > > > + not run as a normal guest. > > > > This is quite unfortunate, is there a way to detect which VTL the > > guest is running at and change the behavior dynamically? > > Only way to detect VTL is via hypercall. However hypercalls are not available > this early in boot sequence. Vitaly, we looked at all the options and we felt this detection did not have to be dynamic and could well be a compile time option. Think of this kernel as a Linux based Trusted Execution Environment that only runs in the Virtual Trust Level surfaced by Hyper-V with limited hardware exposed to this environment. K. Y
