On Fri, Apr 29, 2022 at 11:50:39AM +0200, Jan Beulich wrote: > On 28.04.2022 23:30, Boris Ostrovsky wrote: > > > > On 4/28/22 11:53 AM, Jan Beulich wrote: > >> Hello, > >> > >> in the course of analyzing the i915 driver causing boot to fail in > >> Linux 5.18 I found that Linux, for all the years, has been running > >> in PV mode as if PAT was (mostly) disabled. This is a result of > >> them tying PAT initialization to MTRR initialization, while we > >> offer PAT but not MTRR in CPUID output. This was different before > >> our moving to CPU featuresets, and as such one could view this > >> behavior as a regression from that change. > >> > >> The first question here is whether not exposing MTRR as a feature > >> was really intended, in particular also for PV Dom0. The XenoLinux > >> kernel and its forward ports did make use of XENPF_*_memtype to > >> deal with MTRRs. That's functionality which (maybe for a good > >> reason) never made it into the pvops kernel. Note that PVH Dom0 > >> does have access to the original settings, as the host values are > >> used as initial state there. > > > > > > Initially MTRR was supposed to be supported but it was shot down by x86 > > maintainers who strongly suggested to use PAT. > > > > > > https://lists.xen.org/archives/html/xen-devel/2010-09/msg01634.html > > I recall Ingo's dislike, yes. But them suggesting to use PAT when > PAT depends on MTRR internally is, well, odd. Plus there continues > to be the question why PVH Dom0 should see (and be able to play > with) MTRRs, when PV Dom0 can't even learn their values.
Oh, I didn't realize the handling of MTRR in PVH dom0 was a question, sorry. I don't think it makes sense to limit PVH dom0 access to MTRR if that then implies changes to Linux when running in PVH mode so it can use PAT, and likely changes to Xen in order to avoid using MTRR when calculating the effective cache types (ie: in epte_get_entry_emt). I also don't think there's a need to have this kind of feature parity between PVH and PV dom0s. IMO we should expose whatever is required or makes the implementation of guests easier. For PVH we could always stop reporting the CPUID MTRR bit and thus stop exposing MTRRs and guests should cope. Thanks, Roger.
