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

[Roger Pau Monné <roger.pau@xxxxxxxxxx>]

On Wed, Feb 23, 2022 at 05:31:53PM +0100, Jan Beulich wrote:
> On 23.02.2022 17:11, Roger Pau Monné wrote:
> > On Wed, Feb 23, 2022 at 09:38:56AM -0600, Alex Olson wrote:
> >> 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.
> > 
> > So it's one of those MSRs that's only writable when dom0 has it's
> > vCPUs pinned. We could allow dom0 to read from it in that case (that's
> > an oversight of the MSR handling rework), but it would seem better to
> > just remove access to it altogether: it's bogus to allow dom0 to play
> > with the MSR in the first place IMO, and it won't really solve issues
> > like the one reported here unless dom0 vCPUs == pCPUs and all are
> > pinned, so that dom0 can fix the MSR in all CPUs.
> 
> Dropping this is imo only legitimate if we decide to do away with
> "cpufreq=dom0-kernel" and alike.

I would be fine with that. I think the mode is bogus anyway: dom0
doesn't have enough knowledge to take meaningful decisions, and it
would require that dom0 vCPUs == pCPUs, or else it's only acting on a
subset of CPUs which is already bogus IMO.

Thanks, Roger.