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

[Boris Ostrovsky <boris.ostrovsky@oracle.com>]

On 09/15/2014 09:06 AM, Jan Beulich wrote:
>>>> On 15.09.14 at 13:56, <konrad.wilk@oracle.com> 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)

-boris