Re: [PATCH] x86/PAT: have pat_enabled() properly reflect state when running on e.g. Xen

[Jan Beulich]

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