Messages in this thread | | | Date | Fri, 26 Apr 2024 09:46:40 +0800 | Subject | Re: [RFC PATCH 23/41] KVM: x86/pmu: Implement the save/restore of PMU state for Intel CPU | From | "Mi, Dapeng" <> |
| |
On 4/26/2024 5:46 AM, Sean Christopherson wrote: > On Thu, Apr 25, 2024, Kan Liang wrote: >> On 2024-04-25 4:16 p.m., Mingwei Zhang wrote: >>> On Thu, Apr 25, 2024 at 9:13 AM Liang, Kan <kan.liang@linux.intel.com> wrote: >>>> It should not happen. For the current implementation, perf rejects all >>>> the !exclude_guest system-wide event creation if a guest with the vPMU >>>> is running. >>>> However, it's possible to create an exclude_guest system-wide event at >>>> any time. KVM cannot use the information from the VM-entry to decide if >>>> there will be active perf events in the VM-exit. >>> Hmm, why not? If there is any exclude_guest system-wide event, >>> perf_guest_enter() can return something to tell KVM "hey, some active >>> host events are swapped out. they are originally in counter #2 and >>> #3". If so, at the time when perf_guest_enter() returns, KVM will ack >>> that and keep it in its pmu data structure. >> I think it's possible that someone creates !exclude_guest event after > I assume you mean an exclude_guest=1 event? Because perf should be in a state > where it rejects exclude_guest=0 events.
Suppose should be exclude_guest=1 event, the perf event without exclude_guest attribute would be blocked to create in the v2 patches which we are working on.
> >> the perf_guest_enter(). The stale information is saved in the KVM. Perf >> will schedule the event in the next perf_guest_exit(). KVM will not know it. > Ya, the creation of an event on a CPU that currently has guest PMU state loaded > is what I had in mind when I suggested a callback in my sketch: > > : D. Add a perf callback that is invoked from IRQ context when perf wants to > : configure a new PMU-based events, *before* actually programming the MSRs, > : and have KVM's callback put the guest PMU state
when host creates a perf event with exclude_guest attribute which is used to profile KVM/VMM user space, the vCPU process could work at three places.
1. in guest state (non-root mode)
2. inside vcpu-loop
3. outside vcpu-loop
Since the PMU state has already been switched to host state, we don't need to consider the case 3 and only care about cases 1 and 2.
when host creates a perf event with exclude_guest attribute to profile KVM/VMM user space, an IPI is triggered to enable the perf event eventually like the following code shows.
event_function_call(event, __perf_event_enable, NULL);
For case 1, a vm-exit is triggered and KVM starts to process the vm-exit and then run IPI irq handler, exactly speaking __perf_event_enable() to enable the perf event.
For case 2, the IPI irq handler would preempt the vcpu-loop and call __perf_event_enable() to enable the perf event.
So IMO KVM just needs to provide a callback to switch guest/host PMU state, and __perf_event_enable() calls this callback before really touching PMU MSRs.
> > It's a similar idea to TIF_NEED_FPU_LOAD, just that instead of a common chunk of > kernel code swapping out the guest state (kernel_fpu_begin()), it's a callback > into KVM.
| |