[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/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

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

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...


Xen-devel mailing list



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