> -----Original Message----- > From: Vitaly Kuznetsov <vkuznets@xxxxxxxxxx> > Sent: Tuesday, March 21, 2023 7:54 AM > To: KY Srinivasan <kys@xxxxxxxxxxxxx>; Saurabh Singh Sengar > <ssengar@xxxxxxxxxxxxxxxxxxx> > Cc: tglx@xxxxxxxxxxxxx; mingo@xxxxxxxxxx; bp@xxxxxxxxx; > dave.hansen@xxxxxxxxxxxxxxx; x86@xxxxxxxxxx; hpa@xxxxxxxxx; 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: [EXTERNAL] RE: [PATCH v2 2/2] x86/hyperv: VTL support for Hyper-V > > KY Srinivasan <kys@xxxxxxxxxxxxx> writes: > > >> -----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: > >> > > > ... > > >> > > +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. > > I understand kernels placed in other VTLs serve very specific purposes so likely > there is no need to run standard kernels shipped with various Linux > distributions there in production. It may still come handy to have such option if > only for debugging/testing purposes. The way it is designed now, > CONFIG_HYPERV_VTL will always end up disabled in anything but your custom > builds for VTLs (as such builds won't boot anywhere else). > > Doing a hypercall in early boot may not be trivial now but should be possible. It > would be even better if current VTL would be exposed somewhere in CPUID by > the hypervisor. > > Just a suggestion. Thanks Vitaly and I hear your concern. The VTL environment is so different and so constrained, that paying the cost of a run-time detection we felt did not buy us anything. We did discuss the CPUID option as the most efficient form of run-time detection and the hypervisor team had some issues with this option and so we went with the compile time option. Regards, K. Y
