[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [PATCH] x86/EPT: relax iPAT for "invalid" MFNs
On Mon, Jun 10, 2024 at 04:58:52PM +0200, Jan Beulich wrote: > mfn_valid() is RAM-focused; it will often return false for MMIO. Yet > access to actual MMIO space should not generally be restricted to UC > only; especially video frame buffer accesses are unduly affected by such > a restriction. Permit PAT use for directly assigned MMIO as long as the > domain is known to have been granted some level of cache control. > > Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx> > --- > Considering that we've just declared PVH Dom0 "supported", this may well > qualify for 4.19. The issue was specifically very noticable there. > > The conditional may be more complex than really necessary, but it's in > line with what we do elsewhere. And imo better continue to be a little > too restrictive, than moving to too lax. > > --- a/xen/arch/x86/mm/p2m-ept.c > +++ b/xen/arch/x86/mm/p2m-ept.c > @@ -503,7 +503,8 @@ int epte_get_entry_emt(struct domain *d, > > if ( !mfn_valid(mfn) ) > { > - *ipat = true; > + *ipat = type != p2m_mmio_direct || > + (!is_iommu_enabled(d) && !cache_flush_permitted(d)); Looking at this, shouldn't the !mfn_valid special case be removed, and mfns without a valid page be processed normally, so that the guest MTRR values are taken into account, and no iPAT is enforced? I also think this likely wants a: Fixes: 81fd0d3ca4b2 ('x86/hvm: simplify 'mmio_direct' check in epte_get_entry_emt()') As AFAICT before that commit direct MMIO regions would set iPAT to WB, which would result in the correct attributes (albeit guest MTRR was still ignored). Thanks, Roger.
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |