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

[Jürgen Groß <jgross@xxxxxxxx>]

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

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