From: Borislav Petkov <bp@xxxxxxxxx> Sent: Thursday, February 16, 2023 9:07 AM > > ... here. > > We need a single way to test for this guest type and stick with it. > > I'd like for all guest types we support to be queried in a plain and > simple way. > > Not: > > * CC_ATTR_GUEST_MEM_ENCRYPT > > * x86_platform.hyper.is_private_mmio(addr) > > * CC_ATTR_PARAVISOR > > to mean three different aspects of SEV-SNP guests using vTOM on Hyper-V. > > This is going to be a major mess which we won't support. > OK, I'm trying to figure out where to go next. I've been following the pattern set by the SEV/SEV-ES/SEV-SNP and TDX platforms in the cc_platform_has() function. Each platform returns "true" for multiple CC_ATTR_* values, and those CC_ATTR_* values are tested in multiple places throughout kernel code. Some CC_ATTR_* values are shared by multiple platforms (like CC_ATTR_GUEST_MEM_ENCRYPT) and some are unique to a particular platform (like CC_ATTR_HOTPLUG_DISABLED). For the CC_ATTR_* values that are shared, the logic of which platforms they apply to occurs once in cc_platform_has() rather than scattered and duplicated throughout the kernel, which makes sense. Any given platform is not represented by a single CC_ATTR_* value, but by multiple ones. Each CC_ATTR_* value essentially represents a chunk of kernel functionality that one or more platforms need, and the platform indicates its need by cc_platform_has() returning "true" for that value. So I've been trying to apply the same pattern to the SNP vTOM sub-case of SEV-SNP. Is that consistent with your thinking, or is the whole cc_platform_has() approach problematic, including for the existing SEV flavors and for TDX? Michael
