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

[Rishi <2rushikeshj@xxxxxxxxx>]

On Mon, Nov 25, 2019 at 1:55 PM Jürgen Groß <jgross@xxxxxxxx> wrote:
>
> On 23.11.19 05:29, Elliott Mitchell wrote:
> > On Thu, Nov 21, 2019 at 04:46:21PM +0100, J??rgen Gro?? wrote:
> >> On 21.11.19 16:36, Jan Beulich wrote:
> >>> On 21.11.2019 15:24, J??rgen Gro?? wrote:
> >>>> So: no, just giving dom0 access to the management hardware isn't going
> >>>> to fly. You need to have a proper virtualization layer for that purpose.
> >>>
> >>> Or, like I had done in our XenoLinux forward port, you need to
> >>> go through hoops to make the coretemp driver actually understand
> >>> the environment it's running in.
> >>
> >> This will still not guarantee you'll be able to reach all physical
> >> cpus. IIRC you pinned the vcpu to the respective physical cpu for
> >> performing its duty, but with cpupools this might not be possible for
> >> all physical cpus in the system.
> >
> > Similar to the issue of MCE support, might it instead be better to have
> > *less* virtualization here instead of more?  The original idea behind Xen
> > was to leave the hard to virtualize bits visible and work with Domain 0.
> >
> > Might it be better to expose this functionality to Domain 0, then
> > intercept the kernel calls?  Just needs 1 vcpu which can be scheduled on
> > any processor and that can be moved around to retrieve the data.  This
> > way Xen wouldn't need a proper driver for the management hardware.
>
> In case dom0 is to handle this then it would be much easier to have a
> way for dom0 to specify which physical cpu the data should be retrieved
> from. Forcing a dom0 vcpu to run on a specific physical cpu would need
> a major rework of the Xen scheduling (especially regarding cpupools, let
> alone core scheduling).
>
>
> Juergen

While modifying coretemp driver, following CPU flags came across
X86_FEATURE_DTHERM
X86_FEATURE_PTS

Need to replace/get these via Xen hypercall. This only detects if
DTHERM and PTS support is present. Currently bypassing them in code
and will wait for a proper EAX exposure.

Next is the MSR read for actual temperature values. Currently
rdmsr_safe_on_cpu is being used, does it already get converted to a
Hypercall to be able to detect values?
While tracing the function calls from code, rdmsr_safe_on_cpu() ->
rdmsr_safe() -> native_read_msr_safe() -> asm volatile() comes up.
I can see xen_read_msr_safe() but not sure if this or its any other
variant can be called.

I haven't gone into depth of this and would appreciate pointers to
understand more.

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