+Tom On Thu, May 16, 2024, Kevin Tian wrote: > > From: Zhao, Yan Y <yan.y.zhao@xxxxxxxxx> > > Sent: Tuesday, May 7, 2024 5:13 PM > > > > On Tue, May 07, 2024 at 04:26:37PM +0800, Tian, Kevin wrote: > > > > From: Zhao, Yan Y <yan.y.zhao@xxxxxxxxx> > > > > Sent: Tuesday, May 7, 2024 2:19 PM > > > > > > > > @@ -705,7 +705,17 @@ static enum page_cache_mode > > > > lookup_memtype(u64 paddr) > > > > */ > > > > bool pat_pfn_immune_to_uc_mtrr(unsigned long pfn) > > > > { > > > > - enum page_cache_mode cm = lookup_memtype(PFN_PHYS(pfn)); > > > > + u64 paddr = PFN_PHYS(pfn); > > > > + enum page_cache_mode cm; > > > > + > > > > + /* > > > > + * Check MTRR type for untracked pat range since lookup_memtype() > > > > always > > > > + * returns WB for this range. > > > > + */ > > > > + if (x86_platform.is_untracked_pat_range(paddr, paddr + PAGE_SIZE)) > > > > + cm = pat_x_mtrr_type(paddr, paddr + PAGE_SIZE, > > > > _PAGE_CACHE_MODE_WB); > > > > > > doing so violates the name of this function. The PAT of the untracked > > > range is still WB and not immune to UC MTRR. > > Right. > > Do you think we can rename this function to something like > > pfn_of_uncachable_effective_memory_type() and make it work under > > !pat_enabled() too? > > let's hear from x86/kvm maintainers for their opinions. > > My gut-feeling is that kvm_is_mmio_pfn() might be moved into the > x86 core as the logic there has nothing specific to kvm itself. Also > naming-wise it doesn't really matter whether the pfn is mmio. The > real point is to find the uncacheble memtype in the primary mmu > and then follow it in KVM. Yeaaaah, we've got an existing problem there. When AMD's SME is enabled, KVM uses kvm_is_mmio_pfn() to determine whether or not to map memory into the guest as encrypted or plain text. I.e. KVM really does try to use this helper to detect MMIO vs. RAM. I highly doubt that actually works in all setups. For SME, it seems like the best approach would be grab the C-Bit from the host page tables, similar to how KVM uses host_pfn_mapping_level(). SME aside, I don't have objection to moving kvm_is_mmio_pfn() out of KVM. > from that point probably a pfn_memtype_uncacheable() reads clearer. or even just pfn_is_memtype_uc()?