Open MPI logo

Hardware Locality Development Mailing List Archives

  |   Home   |   Support   |   FAQ   |   all Hardware Locality Development mailing list

Subject: [hwloc-devel] hwloc with Xen system support - v2
From: Andrew Cooper (andrew.cooper3_at_[hidden])
Date: 2014-01-07 06:19:48


Please find v2 of Xen support here:;a=shortlog;h=refs/heads/hwloc-xen-topology-v2

This branch contains a few of Brice's patches to export more functions
for plugins, as well as the main Xen patch which is a merge of various
fixes against it since I originally posted.

Xen support is usable as a plugin, and has a default of 0, requiring
explicit activation using "HWLOC_COMPONENTS=xen" when running in dom0.

It currently supports PU, Core, NUMA Node and Socket enumeration, with
memory information for NUMA nodes.

The code is based on top of master, and there is possibly a bug,
(Original thread: ).

One of the issues I had was that the Core IDs (as reported by Xen) are
enumerated per socket rather than as an entire system. The purpose of
"HACK - patch up cpu_to_core." in hwloc_get_xen_info() is to change the
per-socket enumeration to being per system.

Samuel believes that hwloc should be able to cope with duplicate core
IDs with different cpusets, but if I attempt to do that, I get the
following error:

/* hwloc has encountered what looks like an error from the operating system./
/* object (Core P#0 cpuset 0x30000003) intersection without inclusion!/
/* Error occurred in topology.c line 853/
/* Please report this error message to the hwloc user's mailing list,/
/* along with the output from the script./

(Although in this case, I am quite certain that
will be of little use.)

I currently have a crazy idea for getting at the cache information.
topology-x86.c has a lot of cpuid knowledge, and I have a proposed new
hypercall which executes cpuid on a specific PU. Would it be possible
(or indeed sensible) to parametrise the code in topology-x86.c to take a
few function pointers for get/set binding information, and for the cpuid
call itself?

That way, the common x86 knowledge could be used correctly by the Xen
component, while still keeping its current design.