On 06/09/2019 12:06, Roger Pau Monné wrote: > On Thu, Sep 05, 2019 at 08:04:18PM +0100, Andrew Cooper wrote: >> All 64-bit capable processors use PAT, and with PAT, it is explicitly >> permitted to have mappings with a cacheability different to MTRRs. >> >> On a native system with a real legacy VGA region, MTRRs will cause the region >> to be UC-. When booting virtualised, this range may be RAM and not a legacy >> VGA region, at which point it wants to be WB. >> >> Use WB mapping in the pagetables, such that in systems without a legacy VGA >> region, the RAM between 0xa0000 and 0xc0000 doesn't become unnecesserily UC-. >> However, we still must use small pages to avoid the undefined behaviour >> caused >> by superpages crossing MTRRs of different cacheability. >> >> While adjusting the pagetable construction, switch from pfn to idx for >> consistency with all the other construction logic. >> >> Signed-off-by: Andrew Cooper <andrew.coop...@citrix.com> > Reviewed-by: Roger Pau Monné <roger....@citrix.com> > >> --- >> CC: Jan Beulich <jbeul...@suse.com> >> CC: Wei Liu <w...@xen.org> >> CC: Roger Pau Monné <roger....@citrix.com> >> >> As a future optimisation, Xen could rewrite l2_identmap with a superpage if >> it >> finds that MTRRs are disabled. However, this probably needs to wait until >> Xen >> no longer unconditionally assumes a legacy VGA region to be present in the >> e820 if it finds something other than a hole > Is that still the case? I remember dealing with it when working on the > shim, and I thought the code to unconditionally set a hole in > 0xa0000-0xc0000 was removed.
copy_e820_map() still has the broken logic. I don't recall exactly what state the proposed fixes were in, and I certainly don't have time to dust them off right now. ~Andrew _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
