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 5:33 AM
> 
> On Fri, Feb 10, 2023 at 11:47:27PM +0000, Sean Christopherson wrote:
> > I agree with Boris' comment that a one-off "other encrypted range" is a hack, but
> > that's just an API problem.  The kernel already has hypervisor specific hooks (and
> > for SEV-ES even), why not expand that?  That way figuring out which devices are
> > private is wholly contained in Hyper-V code, at least until there's a generic
> > solution for enumerating private devices, though that seems unlikely to happen
> > and will be a happy problem to solve if it does come about.
> 
> I feel ya and this all makes sense and your proposals look clean enough
> to me but we still need some way of determining whether this is a vTOM
> on hyperv 

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?

Michael

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