Messages in this thread | | | Date | Thu, 16 Feb 2023 18:06:34 +0100 | From | Borislav Petkov <> | Subject | Re: [PATCH v5 06/14] x86/ioremap: Support hypervisor specified range to map as encrypted |
| |
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@suse.com/ > > > > 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
| |