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

[Borislav Petkov]

On Thu, Feb 16, 2023 at 04:16:16PM +0000, Michael Kelley (LINUX) wrote:
> Historically, callbacks like Sean proposed default to NULL and do nothing
> unless they are explicitly set.  The Hyper-V vTOM code would set the callback.
> Is that not sufficient?  Or in the two places where the callback would
> be made, do you want to bracket with a test for being in a Hyper-V vTOM
> VM?  If so, then we're back to needing something like CC_ATTR_PARAVISOR
> on which to gate the callbacks.
> 
> Or do you mean something else entirely?

See the second part of my reply.

This thing...

> > because there's the next crapola with
> > 
> > https://lore.kernel.org/all/20230209072220.6836-4-jgross@xxxxxxxx/
> > 
> > because apparently hyperv does PAT but disables MTRRs for such vTOM
> > SEV-SNP guests and ... madness.
> > 
> > But that's not the only example - Xen has been doing this thing too.
> > 
> > And Jürgen has been trying to address this in a clean way but it is
> > a pain.
> > 
> > What I don't want to have is a gazillion ways to check what needs to
> > happen for which guest type. Because people who change the kernel to run
> > on baremetal, will break them. And I can't blame them. We try to support
> > all kinds of guests in the x86 code but this support should be plain and
> > simple.

... 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.

Thx.

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette