On Sat, Mar 23, 2019 at 10:18:03PM +0800, Like Xu wrote: > === Brief description === > > This proposal for Intel vPMU is still committed to optimize the basic > functionality by reducing the PMU virtualization overhead and not a blind > pass-through of the PMU. The proposal applies to existing models, in short, > is "host perf would hand over control to kvm after counter allocation". > > The pmc_reprogram_counter is a heavyweight and high frequency operation > which goes through the host perf software stack to create a perf event for > counter assignment, this could take millions of nanoseconds. The current > vPMU always does reprogram_counter when the guest changes the eventsel, > fixctrl, and global_ctrl msrs. This brings too much overhead to the usage > of perf inside the guest, especially the guest PMI handling and context > switching of guest threads with perf in use. I think I asked for starting with making pmc_reprogram_counter() less retarded. I'm not seeing that here. > We optimize the current vPMU to work in this manner: > > (1) rely on the existing host perf (perf_event_create_kernel_counter) > to allocate counters for in-use vPMC and always try to reuse events; > (2) vPMU captures guest accesses to the eventsel and fixctrl msr directly > to the hardware msr that the corresponding host event is scheduled on > and avoid pollution from host is also needed in its partial runtime; If you do pass-through; how do you deal with event constraints? > (3) save and restore the counter state during vCPU scheduling in hooks; > (4) apply a lazy approach to release the vPMC's perf event. That is, if > the vPMC isn't used in a fixed sched slice, its event will be released. > > In the use of vPMC, the vPMU always focus on the assigned resources and > guest perf would significantly benefit from direct access to hardware and > may not care about runtime state of perf_event created by host and always > try not to pay for their maintenance. However to avoid events entering into > any unexpected state, calling pmc_read_counter in appropriate is necessary. what?! I can't follow that, and the quick look I had at the patches doesn't seem to help. I did note it is intel only and that is really sad. It also makes a mess of who programs what msr when.