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

Re: [Xen-devel] [PATCH v12 for-xen-4.5 09/20] x86/VPMU: Add public xenpmu.h

On 09/29/2014 10:30 AM, Jan Beulich wrote:
On 29.09.14 at 16:17, <JBeulich@xxxxxxxx> wrote:
On 25.09.14 at 21:28, <boris.ostrovsky@xxxxxxxxxx> wrote:
--- a/xen/include/public/arch-x86/xen-x86_64.h
+++ b/xen/include/public/arch-x86/xen-x86_64.h
@@ -174,6 +174,14 @@ struct cpu_user_regs {
  typedef struct cpu_user_regs cpu_user_regs_t;
+struct xen_pmu_regs {
+    __DECL_REG(ip);
+    __DECL_REG(sp);
Do you really need __DECL_REG() here? I.e. can't these two fields
be just xen_ulong_t e[is]p and the structure definition then be
shared with 32-bit code (and hence moved altogether into pmu.h)?
Otoh - is cs useful at all on 64-bit?

perf uses user_mode() to figure which mode we are in and that requires CS.

And thinking of that - is esp without ss useful on 32-bit? And
are cs (and maybe ss) useful without knowing the execution
mode of the target?

I don't know how exactly ESP is used (by perf, which is the only tool that I have been testing with). For performance counters it is not used at all, I added it only because it will clearly be needed for stack unwinding when this becomes supported. But presumably SS would also be necessary, yes.

CS is useful because only CPL field is looked at.


Xen-devel mailing list



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