On Fri, Jan 31, 2025 at 4:50 PM Sean Christopherson <seanjc@xxxxxxxxxx> wrote: > > 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. :-( > EDK2 has a bug tracker. Maybe this is still fixable on Intel's end. Adding Qinglan, Isaku, and Min to comment. > 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 > -- -Dionna Glaze, PhD, CISSP, CCSP (she/her)
