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