How would you like the user to switch from the fake/guest topology to
the real/host topology in practice? Most applications may still want
fake/guest topos (so that binding works etc) while admins and only some
(advanced?) users will want the real/host topology.
We can easily make Xen lower priority by default and use environment
variables to raise/enable Xen manually. But I am not sure that's a
convenient solution for the end user.
If we add --enable-xen, you'd want to have two hwloc installations, a
normal one and a xen-enabled one?
Le 26/12/2013 22:17, Andrew Cooper a écrit :
> I am looking to add an ability for hwloc to be able to access the system
> topology when operating in the control domain (dom0) of a Xen
> virtualisation environment.
> At the moment, lstopo picks up the VM faked topology. To avoid OS
> schedulers attempting to be 'clever' with their topology, the faked
> topology is 1 socket per vcpu, to prevent a scheduler attempting to
> perform numa optimisation across cores which are not actually numa-adjacent.
> Being a Xen developer myself, I am more than happy with the aspect of
> getting the topology information from Xen. However, I have no idea how
> to integrate this into hwloc.
> I believe can make a topology-xen.c without too much trouble. It likely
> wants to checked before an os-specific hook (Xen dom0's come in at least
> Linux, FreeBSD, NetBSD flavours which have mainstream support)
> Are there any hints/suggestion/information about how to go about
> integrating this? What is the policy with regards to linking against
> new libraries by default (or perhaps by an --enable-xen configure
> option)? At the very least, it would need to link against libxenctrl.so
> which is a userspace library to issue hypercalls (abstracted away from
> the OS specific mechanism).
> hwloc-devel mailing list