Re: [Xen-devel] [PATCH v10 09/20] x86/VPMU: Add public xenpmu.h

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 15.09.14 at 13:56, <konrad.wilk@xxxxxxxxxx> wrote:
>  5). Exposing only CS, RIP, and EFLAGS seems to be tailoring the
>      interface for Linux perf use case.
> 
>  6). Exposing all of the GPRs, while not needed for the current
>      set of Linux patches, could allow other tools to use this
>      (Intel's tracing tool for example - which uses the perf
>      ABI). But surely there are tools on FreeBSD, NetBSD that
>      do profiling.
> 
> 
> If I understand Jan's concerns correctly, the question is -
> if we are not using all of the GPRs right now in the tools
> why even bother expanding it? And if the new version of
> the architecture does expose it -  and we have the support
> - then we can expand the page structure? (and of course
> rev the major).
> 
> While Boris's view is that the condition above will happen -
> we will expand the registers/use case - so why do the
> intermediate step of expanding the page structure - when we can
> make the structure bigger now (and rev the minor).
> 
> Is that about right?

Not exactly, at least as far as my part is concerned: My main
problem is doing a middle thing here: Expose more than the
minimum amount of information, but also not the complete
picture. As said in replies to Boris before (in different words) -
there's nothing making %r13 any more important than %xmm5.
And since exposing complete state seems overkill at this point,
doing the minimum set looks like the only reasonable _and_
consistent thing to me right now.

Of course, if the interface was changed such that rather than
exposing struct cpu_user_regs it would expose an enumerable
register set (with a way to add any current or future register
without needing to change the ABI, i.e. conceptually similar to
how the counters get exposed), then I would not see initially
exposing an arbitrary subset as a problem.

Jan


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