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
