Re: [Xen-devel] [PATCH 06/10] x86/cpuid: Handle leaf 0x6 in guest_cpuid()

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 21.02.17 at 18:40, <andrew.cooper3@xxxxxxxxxx> wrote:
> On 21/02/17 17:25, Jan Beulich wrote:
>>>>> On 20.02.17 at 12:00, <andrew.cooper3@xxxxxxxxxx> wrote:
>>> The thermal/performance leaf was previously hidden from HVM guests, but 
> fully
>>> visible to PV guests.  Most of the leaf refers to MSR availability, and 
> there
>>> is nothing an unprivileged PV guest can do with the information, so hide the
>>> leaf entirely.
>>>
>>> The PV MSR handling logic as minimal support for some thermal/perf 
>>> operations
>> ... has ...
>>
>>> from the hardware domain, so leak through the implemented subset of 
>>> features.
>> Does it make sense to continue to special case PV hwdom here?
> 
> Being able to play with these MSRs will be actively wrong for HVM
> context.  It is already fairly wrong for PV context, as nothing prevents
> you being rescheduled across pcpus while in the middle of a read/write
> cycle on the MSRs.

So the MSRs in question are, afaics
- MSR_IA32_MPERF, MSR_IA32_APERF, MSR_IA32_PERF_CTL (all
  of which are is_cpufreq_controller() dependent)
- MSR_IA32_THERM_CONTROL, MSR_IA32_ENERGY_PERF_BIAS
  (both of which are is_pinned_vcpu() dependent)
For the latter your argument doesn't apply. For the former, I've
been wondering for a while whether we shouldn't do away with
"cpufreq=dom0-kernel".

>> Should there perhaps be at least a fixme note?
> 
> One way or another, we have to invest some different mechanism of
> providing real hardware details to the hardware domain which don't
> collide with their vcpus.

Hence the question whether to at least add a "fixme" note.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel