Open MPI logo

Hardware Locality Development Mailing List Archives

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

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:
>>
>> http://xenbits.xen.org/gitweb/?p=people/andrewcoop/hwloc.git;a=shortlog;h=refs/heads/hwloc-xen-topology-v4
>> http://xenbits.xen.org/gitweb/?p=people/andrewcoop/xen.git;a=shortlog;h=refs/heads/hwloc-support-experimental-v2
>>
>> 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.

~Andrew