Hello, 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? Brice
Le 26/12/2013 22:17, Andrew Cooper a écrit : > Hello, > > 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). > > Thanks, > > ~Andrew > _______________________________________________ > hwloc-devel mailing list > hwloc-de...@open-mpi.org > http://www.open-mpi.org/mailman/listinfo.cgi/hwloc-devel
