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@xxxxxxxxxxxxxxx> 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. > 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 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.
