[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [PATCH] x86/PAT: have pat_enabled() properly reflect state when running on e.g. Xen
On 06.07.2022 19:01, Borislav Petkov wrote: > On Wed, Jul 06, 2022 at 08:17:41AM +0200, Jan Beulich wrote: >> Sure, but that alone won't help. > > Well, the MTRR code looks at X86_FEATURE_MTRR. If Xen doesn't expose the > MTRRs, then that bit should be clear in the CPUID the guest sees. > > So in that case, you could test X86_FEATURE_XENPV at the end of > mtrr_bp_init() and not disable PAT if running as a PV guest. Would that > work? > >> There's a beneficial side effect of running through pat_disable(): >> That way pat_init() will bail right away. Without that I'd need to >> further special case things there (as under Xen/PV PAT must not be >> written, only read) > > We have wrmsr_safe for that. Well, right now the pvops hook for Xen swallows #GP anyway (wrongly so imo, but any of my earlier pointing out of that has been left unheard, despite even the code comments there saying "It may be worth changing that"). The point is therefore that after writing PAT, it would need reading back. In which case it feels (slightly) more clean to me to avoid the write attempt in the first place, when we know it's not going to work. >> Any decent hypervisor will allow overriding CPUID, so in principle >> I'd expect any to permit disabling MTRR to leave a guest to use >> the (more modern and less cumbersome) PAT alone. > > So I'm being told that it would be generally beneficial for all kinds of > virtualization solutions to be able to support PAT only, without MTRRs > so it would be interesting to see how ugly it would become to decouple > PAT from MTRRs in Linux... If I may ask - doesn't this mean this patch, in its current shape, is already a (small) step in that direction? In any event what you say doesn't sound to me like a viable (backportable) route to addressing the regression at hand. Jan
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |