From: Borislav Petkov <bp@xxxxxxxxx> Sent: Tuesday, November 29, 2022 12:41 AM > > On Tue, Nov 29, 2022 at 01:15:39AM +0000, Michael Kelley (LINUX) wrote: > > So that's why I'm suggesting CC_VENDOR_AMD_VTOM. > > There's no CC_VENDOR_AMD_VTOM. How many times do I need to explain this?! > CC_VENDOR is well the CC vendor - not some special case. Let's back up half a step. We have CC_VENDOR_INTEL and CC_VENDOR_AMD because that's a convenient way to identify two fairly different schemes for doing guest encryption. The schemes have some things in common, but the details are pretty different. Tagging the schemes based on the vendor makes sense because the schemes were independently developed by each processor vendor. But it turns out that AMD really has two fairly different schemes: the C-bit scheme and the vTOM scheme. The details of these two AMD schemes are pretty different. vTOM is *not* just a minor option on the C-bit scheme. It's an either/or -- a guest VM is either doing the C-bit scheme or the vTOM scheme, not some combination. Linux code in coco/core.c could choose to treat C-bit and vTOM as two sub-schemes under CC_VENDOR_AMD, but that makes the code a bit messy because we end up with "if" statements to figure out whether to do things the C-bit way or the vTOM way. The difference in the C-bit way and the vTOM way is not Hyper-V specific. Any hypervisor running on an AMD processor can make the same choice to offer C-bit VMs or vTOM VMs. Or we could model the two AMD schemes as two different vendors, which is what I'm suggesting. Doing so recognizes that the two schemes are fairly disjoint, and it makes the code cleaner. Tom Lendacky -- any thoughts on this question from AMD's standpoint? > > IOW, the goal here is for generic SNP functionality to be the same for > *all* SNP guests. We won't do the AMD's version of vTOM enablement, > Hyper-V's version of vTOM enablement and so on. It must be a single > vTOM feature which works on *all* hypervisors as vTOM is a generic SNP > feature - not Hyper-V feature. Yes, there's only one version of vTOM enablement -- the AMD version. But the broader AMD SNP functionality is bifurcated: there's the C-bit scheme and the vTOM scheme. The question is how Linux code should model those two different schemes. I'm suggesting that things are cleaner conceptually and in the code if we model the two different AMD schemes as two different vendors. Michael > > > Of course, when you go from N=1 hypervisors (i.e., KVM) to N=2 (KVM > > and Hyper-V, you find some places where incorrect assumptions were > > made or some generalizations are needed. Dexuan Cui's patch set for > > TDX support is fixing those places that he has encountered. But with > > those fixes, the TDX support will JustWork(tm) for Linux guests on > > Hyper-V. > > That sounds like the right direction to take. > > > I haven't gone deeply into the situation with AMD C-bit support on > > Hyper-V. Tianyu Lan's set of patches for that support is a bit bigger, > > and I'm planning to look closely to understand whether it's also just > > fixing incorrect assumptions and such, or whether they really are > > some differences with Hyper-V. If there are differences, I want to > > understand why. > > You and me too. So I guess we should look at Tianyu's set first. >
