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

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

On 09/29/2014 10:30 AM, Jan Beulich wrote:
>>>> On 29.09.14 at 16:17, <JBeulich@suse.com> wrote:
>>>>> On 25.09.14 at 21:28, <boris.ostrovsky@oracle.com> 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;
>>>   DEFINE_XEN_GUEST_HANDLE(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.

-boris