From: Borislav Petkov <bp@xxxxxxxxx> Sent: Tuesday, November 22, 2022 2:18 PM > > On Tue, Nov 22, 2022 at 06:22:46PM +0000, Michael Kelley (LINUX) wrote: > > I think the core problem here is the naming and meaning of > > CC_VENDOR_HYPERV. The name was created originally when the > > Hyper-V vTOM handling code was a lot of special cases. With the > > changes in this patch series that make the vTOM functionality more > > mainstream, the name would be better as CC_VENDOR_AMD_VTOM. > > No, if CC_VENDOR_HYPERV means different things depending on what kind of > guests you're doing, then you should not use a CC_VENDOR at all. Agreed. My proposal is to drop CC_VENDOR_HYPERV entirely. Replace it with CC_VENDOR_AMD_VTOM (or something like that) that is set *only* by Linux guests that are running on AMD SEV-SNP processors and using the vTOM scheme instead of the AMD C-bit scheme. > > > vTOM is part of the AMD SEV-SNP spec, and it's a different way of > > doing the encryption from the "C-bit" based approach. As much as > > possible, I'm trying to not make it be Hyper-V specific, though > > currently we have N=1 for hypervisors that offer the vTOM option, so > > it's a little hard to generalize. > > Actually, it is very simple to generalize: vTOM and the paravisor and > VMPL are all part of the effort to support unenlightened, unmodified > guests with SNP. > > So, if KVM wants to run Windows NT 4.0 guests as SNP guests, then it > probably would need the same contraptions. Yes, agreed. My point about generalization is that Hyper-V is the only actual implementation today. Edge cases, like whether the IO-APIC is accessed as encrypted or as decrypted don't have a pattern yet. But that's not a blocker. Such cases can be resolved or special-cased later when/if N > 1. > > > With the thinking oriented that way, a Linux guest on Hyper-V using > > TDX will run with CC_VENDOR_INTEL. A Linux guest on Hyper-V that > > is fully enlightened to use the "C-bit" will run with CC_VENDOR_AMD. > > Right. Good. We're in agreement. :-) > > > Dexuan Cui just posted a patch set for initial TDX support on Hyper-V, > > and I think that runs with CC_VENDOR_INTEL (Dexuan -- correct me if > > I'm wrong about that -- I haven't reviewed your patches yet). I confirmed with Dexuan that his new patch set for TDX guests on Hyper-V has the guest running with CC_VENDOR_INTEL, which is what we want. > > Tianyu Lan > > has a patch set out for Hyper-V guests using the "C-bit". That patch set > > still uses CC_VENDOR_HYPERV. Tianyu and I need to work through > > whether his patch set can run with CC_VENDOR_AMD like everyone > > else using the "C-bit" approach. I haven't followed up with Tianyu yet. > > So I'm not sure the vendor is the right approach here. I guess we need > to specify the *type* of guest being supported. Yes, calling it the "vendor" turns out to not quite be right because in the AMD case, the technology/architecture/scheme/"type" (or whatever you want to call it) is not 1:1 with the vendor. Intel has just one (TDX) while AMD has two (C-bit and vTOM). "vendor" is just a label, but we should get the label right to avoid future confusion. The key point is that we'll have three top-level types: * TDX * AMD with C-bit (and this has some sub-types) * AMD with vTOM The CC_ATTR_* values are then derived from the "type". > > > Yes, the polarity of the AMD vTOM bit matches the polarity of the > > TDX GPA.SHARED bit, and is the opposite polarity of the AMD "C-bit". > > I'll add a comment to that effect. > > > > Anyway, that's where I think this should go. Does it make sense? > > Other thoughts? > > I think all that polarity doesn't matter as long as we abstract it away > with, "mark encrypted" and "mark decrypted". Agreed. Michael
