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.

quoted

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