RE: [PATCH v5 06/14] x86/ioremap: Support hypervisor specified range to map as encrypted

[Michael Kelley (LINUX)]

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