From: Borislav Petkov <bp@xxxxxxxxx> Sent: Monday, March 20, 2023 11:17 AM > > On Mon, Mar 20, 2023 at 01:30:54PM +0000, Michael Kelley (LINUX) wrote: > > In a vTOM VM, CPUID leaf 0x8000001f is filtered so it does *not* return > > Bit 1 (SEV) as set. Consequently, sme_enable() does not read MSR_AMD64_SEV > > and does not populate sev_status. > > So how much of the hardware side of vTOM are you actually using besides > the actual encryption? vTOM mode in Linux is just turning on/off the vTOM bit in the PTE to create unencrypted or encrypted mappings, with encrypted being the default. There's no other hardware dependency except CPUID leaf 0x8000001f reporting that SEV is not enabled, and the GHCB protocol (if you want to call that "hardware") as mentioned below. > > Virtual TOM MSR (C001_0135)? Anything else? > > AFAICT, you're passing the vTOM value from CPUID from the hypervisor so > I'm guessing that happens underneath in the hypervisor? Correct. Linux in vTOM mode is not reading MSR 0xC0010135. The PTE bit position of the vTOM bit is coming from Hyper-V (or the paravisor) via a synthetic MSR. Presumably Hyper-V or the paravisor is reading the vTOM MSR, but I haven't reviewed that code. > > I'd like to make sure there are no more "surprises" down the road... > The only other vTOM changes are for software protocols for communication between the guest and Hyper-V (or the paravisor). Some hypercalls and synthetic MSR accesses need to bypass the paravisor and are handled with the GHCB protocol. The Hyper-V and VMbus specific code in Linux handles those idiosyncrasies. That code went into the 5.15 kernel and isn't modified by this patch set. The vTOM case is down to the bare minimum in the use of the hardware functionality, so it's unlikely anything else would turn up as being different. Michael
