[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

On 09/15/2014 09:06 AM, Jan Beulich wrote:
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.

This would be different from how counters are presented since there we are specifying how many of the same type of registers we have whereas with CPU registers (GPR or otherwise) we'd have different "things" (for lack of a better term).

I'll see if I can come up with a representation that is something along the lines of what you are suggesting. If I can't (partly because there is a danger of over-designing it) I'll then put together a set of registers that we now know are needed and provide enough padding for adding new ones without changing major version.

(probably next week though since I am traveling this week. This will be cutting real close to 4.5 deadline)


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.