Re: [Xen-devel] Xen hiding thermal capabilities from Dom0

[Rishi <2rushikeshj@xxxxxxxxx>]

On Mon, Nov 18, 2019 at 3:08 PM Jan Beulich <jbeulich@xxxxxxxx> wrote:
>
> On 15.11.2019 20:19, Rishi wrote:
> > On Thu, Nov 14, 2019 at 10:05 PM Jan Beulich <jbeulich@xxxxxxxx> wrote:
> >>
> >> On 14.11.2019 17:07, Rishi wrote:
> >>> In some of our hosts, Xen is not correctly exposing processor thermal
> >>> capabilities to Dom0.
> >>> Please refer: https://bugzilla.kernel.org/show_bug.cgi?id=205347
> >>>
> >>> The flag
> >>> /* Thermal and Power Management Leaf, CPUID level 0x00000006 (EAX), word 
> >>> 14 */
> >>> X86_FEATURE_DTHERM (14*32+ 0)
> >>>
> >>> is returned 0 via PVOP_VCALL4 vs returns 1 via native_cpuid() call from 
> >>> Dom0.
> >>>
> >>> Sample output via PVCALL vs Native call.
> >>> [63291.688755] cpuid_eax 6 :  a 0
> >>> [63291.688759] native_cpuid : a 77
> >>>
> >>> Is this a bug or needs some special feature to be enabled from Xen 
> >>> command line?
> >>
> >> Exposing this to guests (including Dom0) would imply properly
> >> virtualizing the respective behavior. In
> >> xen/arch/x86/cpuid.c:recalculate_misc() we specifically have
> >>
> >>     p->basic.raw[0x6] = EMPTY_LEAF; /* Therm/Power not exposed to guests. 
> >> */
> >>
> >> If you wanted this exposed, you'd first of all need to come up
> >> with a sane virtualization model of this functionality. Simply
> >> exposing the CPUID bits is not going to be an option.
> >
> > Is it due to any security risks? If so, are there any advisories around it?
>
> No, it's because of the split of responsibilities: It's Xen to manage
> the CPUs.
>
> > Should it be allowed that Xen is hiding CPU flags (in this case
> > Therm), yet a modification to Dom0 kernel allows them to be brought
> > back?
>
> Yes, a PV kernel is supposed to do things the PV way, i.e. in
> particular use the PV form of CPUID. (Note that on hardware supporting
> CPUID faulting you can't "bring back" the flags via a kernel change,
> since then _all_ CPUID invocations will be handled by Xen instead of
> by bare hardware. So _not_ doing things the PV way in the kernel sets
> you up for surprises.)
>
> Jan

ok, thanks for clearing it up. Would a patch be accepted if this
option of showing EAX leaf is selectively done through command line
(default disabled)?
On longer run, what is an expected sane model of virtualizing this?
With some guidance, may be I or someone else can code to bring the
functionality back.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel