[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH 06/10] x86/cpuid: Handle leaf 0x6 in guest_cpuid()
>>> 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
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |