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
