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 because there's the next crapola with https://lore.kernel.org/r/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. Thx. -- Regards/Gruss, Boris. https://people.kernel.org/tglx/notes-about-netiquette
