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
