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

["Jürgen Groß" <jgross@suse.com>]

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@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel