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

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

On 09/12/2014 10:38 AM, Jan Beulich wrote:
>>>> On 12.09.14 at 16:21, <boris.ostrovsky@oracle.com> wrote:
>> On 09/12/2014 02:50 AM, Jan Beulich wrote:
>>> Okay, so you're tailoring the hypervisor interface to Linux. That's
>>> not what we generally aim for, and hence I continue to think this
>>> isn't the right approach.
>> But we know that at least one consumer of this interface (Linux/perf)
>> does want to have full GPR set.
> You said they use a struct pt_regs somewhere - that's not the same
> as struct cpu_user_regs (and the overlap of registers being in both
> is not much more than a coincidence), and you didn't clarify yet how
> much of this information is _actually_ getting consumed (i.e. this may
> well just happen to be a suitable container for conveying a smaller
> set).

I don't know how all registers are consumed in Linux code (except for 
RIP and CS) and I am not sure it's all that important: we know that we 
need to pass GPRs to perf infrastructure which, for the most part, is a 
black box (especially given the insane amount of code churn that happens 
in perf).

If and when we find out that something that perf wants is not provided 
in pt_regs (converted from cpu_user_regs) then we will have to deal with 
it. But it's not much different from what would happen if we use 
specific registers in the shared structure.

>
>> So why not provide it? Especially since
>> (I suspect that) doing memcpy may be faster than copying only selected
>> fields.
>>
>> If you are categorically against this I can certainly rework this and
>> pass RIP, RSP, CS and EFLAGS only.
> My problem with this is that (a) it exposes an arbitrary subset of
> registers and (b) in an incompatible way (a 32-bit profiling domain
> should very well be told all 64-bit registers of a 64-bit guest it
> profiles). Since b would need addressing by a custom structure
> anyway, dealing with a at the same time seems reasonable to me.

Note that (b) is not supported --- 32-bit domains can only profile 
themselves and not the hypervisor (or other domains).

>
> But of course it would help if other interested parties would voice
> their view of this...

-boris