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 pointers. 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 calculations) I would have though that cpuid is architecturally-specific enough that just hard coding 4 input and output parameters would be sufficient. ~Andrew
