Re: [Xen-devel] [PATCH RFC 12/31] tools: Utility for dealing with featuresets

[Ian Campbell <ian.campbell@xxxxxxxxxx>]

On Tue, 2016-01-05 at 16:14 +0000, Andrew Cooper wrote:
> On 05/01/16 15:17, Ian Campbell wrote:
> > On Wed, 2015-12-16 at 21:24 +0000, Andrew Cooper wrote:
> > > It is able to reports the current featuresets; both the static masks
> > > and
> > > dynamic featuresets from Xen, or to decode an arbitrary featureset
> > > into
> > > `/proc/cpuinfo` style strings.
> > More than adding a utility does this not also arrange for a whole bunch
> > of
> > new functionality to be compiled into libxc? That's worth mentioning
> > here.
> 
> It is almost all just data.ÂÂOnly a single (trivial) function at
> present.ÂÂBut yes - it is worth mentioning.
> 
> > 
> > And doesn't it do so in a non-library namespaced way (e.g.
> > with calculate_featuresets() and decode_featureset() being exposed by
> > the
> > library)?
> 
> calculate_featuresets() is hypervisor-only code and not included by this
> change, and decode_featureset() is a local function to the utility.

Ah, I obviously just got confused.

What are the symbols exported by cpuid.o in a tools build then?

> > Granted there's lots of that sort of thing already, but should we
> > really be
> > making it worse?
> > 
> > libelf avoids this by namespacing itself as a quasi-standalone library
> > in
> > both the tools and hypervisor contexts.
> 
> Nothing from the shared .c files is expected to be exposed in the API. 
> The guts of xc_cpuid_policy() end up using it, but that is an
> implementation detail.

Ah, so is the presence of the vpath stuff in libxc here spurious then?
Since the utility you are adding doesn't actually use anything which it
provides?

That would explain my confusion. (and makes the namespacing moot I think)


> > (and then naturally be part of the autogeneration which has been
> > discussed)
> > > + option_error:
> > > +ÂÂÂÂÂÂÂÂÂÂÂÂprintf("Usage: %s [ info | detail | <featureset>* ]\n",
> > > argv[0]);
> > What format does <featureset> take?
> 
> : or - delimited 32bit hex strings.
> 
> Some sample outputs look like:

Thanks, so one could call

xen-cpuid 
ffeffbff:fffef7ff:efdbfbff:2469bfff:0000000f:21dcffbb:00000001:00000100:00000001

and expect output like:
[...]
> Â [00] 0x00000001.edxÂÂÂÂÂfpu vme de pse tsc msr pae mce cx8 apic
> sysenter mtrr pge mca cmov pat pse36 clflsh acpi mmx fxsr sse sse2
> Â [01] 0x00000001.ecxÂÂÂÂÂsse3 vmx cx16 hyper
> Â [02] 0x80000001.edxÂÂÂÂÂsyscall nx lm
> Â [03] 0x80000001.ecxÂÂÂÂÂlahf_lm
> Â [04] 0x0000000d:1.eaxÂ
> Â [05] 0x00000007:0.ebxÂ
> Â [06] 0x00000007:0.ecxÂ
> Â [07] 0x80000007.edxÂÂÂ
> Â [08] 0x80000008.ebxÂÂÂ

(except not w/space mangled by my MUA)?

If one was only interested in an 0x00000001.edx value one could say

xen-cpuid ffeffbff

But what if one wants only e.g.Â0x80000001.ecx? Can you say :::2469bfff or
is it just not possible?

I don't think this tools warrants full docs or a manpage or whatever, but
if you were to put the usage into a function then it could be more easily
multiline and perhaps include a bit more info, plus then my terribly minor
gripe about the use of goto which I didn't feel was worth mentioning would
go away ;-)

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel