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

[Boris Ostrovsky <boris.ostrovsky@xxxxxxxxxx>]

On 09/12/2014 10:38 AM, Jan Beulich wrote:
> > > > On 12.09.14 at 16:21, <boris.ostrovsky@xxxxxxxxxx> 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

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