On Wed, Feb 22, 2023 at 05:21:27PM -0800, Sean Christopherson wrote:
> The MTRR mess isn't unique to coco guests, e.g. KVM explicitly "supports" VMMs
> hiding MTTRs from the guest by defaulting to WB if MTTRs aren't exposed to the
> guest. Why on earth Hyper-V suddenly needs to enlighten the guest is beyond me,
> but whatever the reason, it's not unique to coco VMs.
Well, TDX can't stomach MTRRs either, reportedly, and I hear we should
try to avoid #VEs for them too.
And this is the problem: all those guest "enlightening" efforts come up
with the weirdest stuff they need to sprinkle around arch/x86/. And if
we let that without paying attention to the big picture, that will
become an unmaintanable mess.
And I'm not proud of some of the stuff we did in arch/x86/ already and
some day they'll get on my nerves just enough...
> All I'm advocating is that for determining whether or not a device should be mapped
> private vs. shared, provide an API so that the hypervisor-specific enlightened code
> can manage that insanity without polluting common code. If we are ever fortunate
> enough to have common enumeration, e.g. through ACPI or something, the enlightened
> code can simply reroute to the common code. This is a well established pattern for
> many paravirt features, I don't see why it wouldn't work here.
Yah, that would be good. If the device can know upfront how it needs to
ioremap its address range, then that is fine - we already have
ioremap_encrypted() for example.
What I don't like is hooking conditionals into the common code to figure
out what to do depending on what we're running on.
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
