Re: [RFC] Avoid dom0/HVM performance penalty from MSR access tightening

[Jan Beulich <jbeulich@xxxxxxxx>]

On 23.02.2022 16:38, Alex Olson wrote:
> It seems to me there are a few findings useful to the Xen developers from
> venturing down this rabbithole:
> 
> 1) For conditions in which MSR registers are writeable from PV guests (such as
> dom0),  they should probably be readable well, looks like 
> MSR_IA32_THERM_CONTROL
> is currently one of a small number of "unreadable" but writeable
> MSRs.  Otherwise seemingly valid read-(check/modify)-write operations will
> behave incorrectly under Xen.

Hmm, this is indeed odd, just like for the adjacent MSR_IA32_ENERGY_PERF_BIAS.
But changing the behavior for such things requires (a) doing archaeology and
(b) being certain that no old Dom0 may be affected by an adjustment. Quite
likely this write-only behavior is a result from removing read access in the
general case. IOW I think we want to re-add read access for these two MSRs
(and any others fitting this pattern) for Dom0. Care to make a patch?

It's perhaps worth noting that (write) access to these two MSRs sits behind
is_hwdom_pinned_vcpu(). This is a mode we generally recommend against using
anyway. I'm not even sure we consider it (security) supported.

> 2) As Xen controls CPU frequency and c-states,  might there be benefit to it
> being extended to manage Clock Modulation / Throttling? (I wasn't expecting 
> dom0
> to be able to influence this!)

This had been the plan many, many years ago. Yet no-one ever came forward
with any code, afaik.

> 3) Perhaps PV domains (such as dom0) should not be allowed to modify such MSRs
> at all since it would result in unintended effects depending on how CPU pools
> and dom0 are managed?

Well, the general rule already is to limit what can be written. So wrong
cases now need to really be dealt with per individual MSR.

Jan