Open MPI logo

Hardware Locality Development Mailing List Archives

  |   Home   |   Support   |   FAQ   |  

This web mail archive is frozen.

This page is part of a frozen web archive of this mailing list.

You can still navigate around this archive, but know that no new mails have been added to it since July of 2016.

Click here to be taken to the new web archives of this list; it includes all the mails that are in this frozen archive plus all new mails that have been sent to the list since it was migrated to the new archives.

Subject: Re: [hwloc-devel] hwloc with Xen system support - v2
From: Andrew Cooper (andrew.cooper3_at_[hidden])
Date: 2014-02-13 06:03:37

On 13/02/14 10:52, Brice Goglin wrote:
> Le 13/02/2014 02:48, Andrew Cooper a écrit :
>> That's fantastic! I was expecting to have to attempt to code this up myself.
>> I hereby present v4 of the series, available from:
>> Where the hwloc-xen-topology-v4 branch is now based on x86-common rather
>> than master.
>> hwloc-support-experimental-v2 in the Xen tree now contains two changes.
>> In addition to the *_bounced() functions, there is a new SYSCTL
>> hypercall for Xen to allow the toolstack to request execution of an
>> arbitrary cpuid instruction on a specific processor. It seems to work
>> in each of the usecases I had before, and now provides substantially
>> more information.
>> I suspect that the new cpuid function call needs to be properly guarded
>> by the configure script; While the previous code was common to all Xen
>> architectures, the cpuid sysctl is very definitely x86 specific.
> I just *rebased* and repushed the x86-common branch. You now need to
> #ifdef HWLOC_HAVE_X86_CPUID before calling the cpuid function. I have
> also cleaned the namespace (to avoid possible conflicts with non-x86
> cpuid-similar functions in the future). So you should replace "x86" with
> "x86_cpuid" in the function name and in the flags.

I will take a look at rebasing on top of your rebase, but probably
tomorrow at this rate.

> Let me know if you see anything to change before I merge this into the
> master branch.

Will do.

> Where are you on your side? Your code looks fine to me, but there was
> some discussion about switching to another xen lib, and some possible
> issue with the API/ABI changing without version numbers to check against.

Still pending. Xen is currently on code freeze pending the release of
Xen-4.4 so my changes arn't going anywhere immediately. Following that,
there is no grantee my changes will be accepted in their current form,
so more work might be needed when xen-unstable opens up again.

> Do you want to merge something in hwloc soon?

Would you mind merging your two patches that I am carrying?

"plugins: export hwloc_alloc_root_sets()"
"plugins: cleanup hwloc_setup_pu_level() and export it to plugins"

Neither of them are explicitly Xen specific, and from a lazy point of
view it would be nicer to have a sorter branch to look after. (I am
fairly sure I have rebased them properly going forwards over the other
changes recently)

> I am thinking of releasing
> hwloc v1.9 within one month or two. I am not against releasing the hwloc
> Xen backend as long as we do not cause failures to build for many
> people. If it's too hard, we could also keep it disabled by default
> until hwloc v1.10?
> Brice

Until the library and hypervisor support is present in Xen-unstable,
releasing anything in hwloc seems premature. Getting anything properly
sorted for v1.9 seems unlikely, but v1.10 seems reasonable. I will of
course keep my xen and hwlock trees with working code in, so people can
play if they wish.