> 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.
from that point probably a pfn_memtype_uncacheable() reads clearer.
