Messages in this thread | | | Date | Wed, 22 Feb 2023 23:33:38 +0100 | From | Borislav Petkov <> | Subject | Re: [PATCH v5 06/14] x86/ioremap: Support hypervisor specified range to map as encrypted |
| |
On Wed, Feb 22, 2023 at 02:13:44PM -0800, Sean Christopherson wrote: > Because vTOM is a hardware feature, whereas the IO-APIC and vTPM being accessible > via private memory are software features. It's very possible to emulate the > IO-APIC in trusted code without vTOM.
I know, but their use case is dictated by the fact that they're using a SNP guest *with* vTOM as a SEV feature. And so their guest does IO-APIC and vTPM *with* the vTOM SEV feature. That's what I'm trying to model.
> > If the access method to the IO-APIC and vTPM are specific to the > > HyperV's vTOM implementation, then I don't mind if this were called > > > > cc_platform_has(CC_ATTR_GUEST_HYPERV_VTOM); > > I still think that's likely to caused problems in the future, e.g. if Hyper-V > moves more stuff into the paravisor or if Hyper-V ends up with similar functionality > for TDX.
Yah, reportedly, TDX folks are not very interested in this case.
> But it's not a sticking point, the only thing I'm fiercely resistant to > is conflating hardware features with software features.
So you and I need to find a common ground...
-- Regards/Gruss, Boris.
https://people.kernel.org/tglx/notes-about-netiquette
| |