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.
