Attempt to hack around the SNP/TDX guest MTRR disaster by hijacking
x86_platform.is_untracked_pat_range() to force the legacy PCI hole, i.e.
memory from TOLUD => 4GiB, as unconditionally writeback.
TDX in particular has created an impossible situation with MTRRs. Because
TDX disallows toggling CR0.CD, TDX enabling decided the easiest solution
was to ignore MTRRs entirely (because omitting CR0.CD write is obviously
too simple).
Unfortunately, under KVM at least, the kernel subtly relies on MTRRs to
make ACPI play nice with device drivers. ACPI tries to map ranges it finds
as WB, which in turn prevents device drivers from mapping device memory as
WC/UC-.
For the record, I hate this hack. But it's the safest approach I can come
up with. E.g. forcing ioremap() to always use WB scares me because it's
possible, however unlikely, that the kernel could try to map non-emulated
memory (that is presented as MMIO to the guest) as WC/UC-, and silently
forcing those mappings to WB could do weird things.
My initial thought was to effectively revert the offending commit and
skip the cache disabling/enabling, i.e. the problematic CR0.CD toggling,
but unfortunately OVMF/EDKII has also added code to skip MTRR setup. :-(
Sean Christopherson (2):
x86/mtrr: Return success vs. "failure" from guest_force_mtrr_state()
x86/kvm: Override low memory above TOLUD to WB when MTRRs are forced
WB
arch/x86/include/asm/mtrr.h | 5 +++--
arch/x86/kernel/cpu/mtrr/generic.c | 11 +++++++----
arch/x86/kernel/kvm.c | 31 ++++++++++++++++++++++++++++--
3 files changed, 39 insertions(+), 8 deletions(-)
base-commit: fd8c09ad0d87783b9b6a27900d66293be45b7bad
--
2.48.1.362.g079036d154-goog
