> > > > > static void pmc_reprogram_counter(struct kvm_pmc *pmc, u32 type,
> > > > > unsigned config, bool exclude_user,
> > > > > bool exclude_kernel, bool intr,
> > > > > - bool in_tx, bool in_tx_cp)
> > > > > + bool in_tx, bool in_tx_cp, bool pebs)
> > > > > {
> > > > > struct perf_event *event;
> > > > > struct perf_event_attr attr = { @@ -111,9 +111,12 @@ static
> > > > > void pmc_reprogram_counter(struct kvm_pmc *pmc,
> > u32 type,
> > > > > .exclude_user = exclude_user,
> > > > > .exclude_kernel = exclude_kernel,
> > > > > .config = config,
> > > > > + .precise_ip = pebs ? 1 : 0,
> > > > > + .aux_output = pebs ? 1 : 0,
> > > >
> > > > srsly?
> > >
> > > Hi Peter,
> > > Thanks for review. For aux_output, I think it should be set 1
> > > when the guest wants to
> > enabled PEBS by Intel PT.
> > > For precise_ip, it is the precise level in perf and set by perf
> > > command line in KVM
> > guest, this may not reflect the accurate value (can be 0~3) here. Here
> > set to 1 is used to allocate a counter for PEBS event and set the
> > MSR_IA32_PEBS_ENABLE register. For PMU virtualization, KVM will trap
> > the guest's write operation to PMU registers and allocate/free event
> > counter from host if a counter enable/disable in guest. We can't
> > always deduce the exact parameter of perf command line from the value of the guest
> writers to the register.
> >
> > Please, teach your MUA to wrap on 78 chars.
> >
> > The thing I really fell over is the gratuitous 'bool ? 1 : 0'. But
> > yes, the aux_output without a group leader is dead wrong. We'll go fix
> > perf_event_create_kernel_counter() to refuse that.
>
> Yes, I also think it is a little gratuitous here. But it is a little hard to reconstruct the guest
> perf parameters from the register value, especially the "precise_ip". Do you have any
> advice?
>
> About refuse the perf_event_create_kernel_counter() request w/o aux_ouput, I think I
> need to allocate the PT event as group leader here, is that right?
Hi Peter,
What's your opinion?
Thanks,
Luwei Kang
