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
