Messages in this thread | | | Date | Tue, 29 Nov 2022 09:40:46 +0100 | From | Borislav Petkov <> | Subject | Re: [Patch v3 07/14] x86/hyperv: Change vTOM handling to use standard coco mechanisms |
| |
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.
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.
> 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.
Thx.
-- Regards/Gruss, Boris.
https://people.kernel.org/tglx/notes-about-netiquette
| |