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-01-29 12:47:15

On 29/01/14 15:04, Brice Goglin wrote:
> I've been thinking about how to use the cpuid hypercall.
> Right now the x86 backend does
> foreach proc
> bind on this proc
> do a lot of cpuid calls
> It would do instead
> foreach proc
> cpuid hypercall on this proc

One alternative is to intercept both the bind and cpuid function calls,
and have the Xen module remember which cpu was last bound to, and fill
in the appropriate hypercall.

This would avoid any major restructuring of the code, if that were the
preferred way to go.

Having said that...

> So we would
> 1) add a cpuid(topology, cpu, inputbuffer, outputbuffer) hook pointer in
> the topology structure
> 2) have xen define that hook (using a new function since the topology
> internals are not visible to plugins). It could be in the xen discover()
> callback. Or it could be in the instantiate() callback if we want the
> x86 backend to work when used before the xen backend. I think we just
> have to be sure we don't enable that hook before we're sure the Xen
> backend will work.
> 3) when this hook is defined, the x86 backend doesn't need to bind
> anymore, but it uses that cpuid hook instead of raw cpuid instructions.

This would be nice, although it would involve some more selection on the
exclusions. Currently, running Xen excludes all other cpu detection
methods as they are more likely than not to be wrong.

One solution to this would be to have a "generic" x86 cpuid topology
generator which must be parametrised with a structure, at which point
both Xen and the fallback x86 methods can supply appropriate function

This would allow Xen to use the generic topology code while still
preventing fallback to the x86 topology detection method.

> We may want to make inputbuffer and outputbuffer generic enough (void* +
> length) so that the model works for other architectures one day? Xen
> will know that they correspond to inputbuffer=one-register and
> outputbuffer=four-registers when running on x86.
> Brice

As correctly indicated by Samuel, x86 cpuid already has ecx as an input
parameter for certain cpuid leaves. (cache information, xsave size

I would have though that cpuid is architecturally-specific enough that
just hard coding 4 input and output parameters would be sufficient.