>
> On Tue, Jul 08, 2014 at 09:49:40AM -0700, kan.liang@xxxxxxxxx wrote:
> > --- a/arch/x86/kernel/cpu/perf_event.h
> > +++ b/arch/x86/kernel/cpu/perf_event.h
> > @@ -464,6 +464,12 @@ struct x86_pmu {
> > */
> > struct extra_reg *extra_regs;
> > unsigned int er_flags;
> > + /*
> > + * EXTRA REG MSR can be accessed
> > + * The extra registers are completely unrelated to each other.
> > + * So it needs a flag for each extra register.
> > + */
> > + bool extra_msr_access[EXTRA_REG_MAX];
> >
> > /*
> > * Intel host/guest support (KVM)
>
> # pahole -C extra_reg arch/x86/kernel/cpu/perf_event_intel.o
> struct extra_reg {
> unsigned int event; /* 0 4 */
> unsigned int msr; /* 4 4 */
> u64 config_mask; /* 8 8 */
> u64 valid_mask; /* 16 8 */
> int idx; /* 24 4 */
>
> /* size: 32, cachelines: 1, members: 5 */
> /* padding: 4 */
> /* last cacheline: 32 bytes */
> };
>
> There's still 4 empty bytes at the tail of extra_reg itself; would it make sense
> to store the availability of the reg in there?
>
Now, it perfectly matches the 4 empty bytes. However, the extra_reg_type may be extended in the near future.
> After all; the place we use it (x86_pmu_extra_regs) already has the pointer
> to the structure.
Yes, it's doable. However, if we move extra_msr_access to extra_reg, I guess we have to modify all the related micros (i.e EVENT_EXTRA_REG) to initialize the new items. That could be a big change.
On the other side, in x86_pmu structure, there are extra_regs related items defined under the comments "Extra registers for events". And the bit holes are enough for current usage and future extension.
I guess x86_pmu should be a good place to store the availability of the reg.
/* --- cacheline 6 boundary (384 bytes) --- */
bool lbr_double_abort; /* 384 1 */
/* XXX 7 bytes hole, try to pack */
struct extra_reg * extra_regs; /* 392 8 */
unsigned int er_flags; /* 400 4 */
/* XXX 4 bytes hole, try to pack */
struct perf_guest_switch_msr * (*guest_get_msrs)(int *); /* 408 8 */
/* size: 416, cachelines: 7, members: 64 */
/* sum members: 391, holes: 6, sum holes: 25 */
/* bit holes: 1, sum bit holes: 27 bits */
/* last cacheline: 32 bytes */
Thanks,
Kan
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
