From: "Liang, Kan" <kan.liang@linux.intel.com>
To: "Wang, Wei W" <wei.w.wang@intel.com>,
"Li, Xiaoyao" <xiaoyao.li@intel.com>,
Peter Zijlstra <peterz@infradead.org>,
Ingo Molnar <mingo@redhat.com>,
Arnaldo Carvalho de Melo <acme@kernel.org>,
Mark Rutland <mark.rutland@arm.com>,
Alexander Shishkin <alexander.shishkin@linux.intel.com>,
Jiri Olsa <jolsa@kernel.org>, Namhyung Kim <namhyung@kernel.org>,
"Christopherson,, Sean" <seanjc@google.com>,
Paolo Bonzini <pbonzini@redhat.com>
Cc: "linux-perf-users@vger.kernel.org"
<linux-perf-users@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"kvm@vger.kernel.org" <kvm@vger.kernel.org>
Subject: Re: [RFC PATCH v2 2/3] perf/x86/intel/pt: Introduce and export pt_get_curr_event()
Date: Mon, 26 Sep 2022 11:32:59 -0400 [thread overview]
Message-ID: <4320bb19-b206-97b6-4eae-093c9d815ba0@linux.intel.com> (raw)
In-Reply-To: <DS0PR11MB6373C84139621DC447D3F466DC4E9@DS0PR11MB6373.namprd11.prod.outlook.com>
On 2022-09-22 8:58 a.m., Wang, Wei W wrote:
> On Thursday, September 22, 2022 8:34 PM, Liang, Kan wrote:
>>> To solve the problem, introduce and export pt_get_curr_event() for KVM
>>> to get current pt event.
>>
>> I don't think the current pt event is created by KVM. IIUC, the patch basically
>> expose the event created by the other user to KVM. That doesn't sounds
>> correct.
>
> Yes, that's the host PT event running on the current CPU. Not created by KVM.
>
>>
>> I think it should be perf's responsibility to decide which events should be
>> disabled, and which MSRs should be switched. Because only perf can see all the
>> events. The users should only see the events they created.
>
> For other pmu cases, yes. For PT, its management is simpler than other pmu
> resources and PT PMU is much simpler. It doesn't have a scheduler to manage
> events.
>
Right, but I think we'd better to create a simpler scheduler (just for
two events) in the PT driver, since you have two co-existing PT events
now, one is from the host and the other is from the guest. I don't think
it's KVM's responsibility to schedule events.
So I think the process should be something as below.
- Let KVM create a PT event if the guest request one.
- In VM-entry, just invoke the perf_event_enable_local(guest).
The PT driver should schedule out the host event or whatever events
and schedule in the guest event.
- In VM-exit, just invoke the perf_event_disable_local(guest).
The PT driver should schedule in the host event or whatever events and
schedule out the guest event.
I still don't think we want to expose the host event.
Thanks,
Kan
> I think the usage here is similar to the CPU thread scheduling case. When we have
> CPUs isolated from the CPU scheduler, i.e. no scheduler for those CPUs, basically
> we rely on users to ping tasks to those CPUs (e.g. taskset).
>
> For the commit log, probably we don't need those KVM details here. Simplify a bit:
>
> Add a function to expose the current running PT event to users. One usage is in KVM,
> it needs to get and disable the running host PT event before VMEnter to the guest and
> resumes the event after VMexit to host.
next prev parent reply other threads:[~2022-09-26 16:45 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-09-21 16:45 [RFC PATCH v2 0/3] KVM: VMX: Fix VM entry failure on PT_MODE_HOST_GUEST while host is using PT Xiaoyao Li
2022-09-21 16:45 ` [RFC PATCH v2 1/3] perf/core: Expose perf_event_{en,dis}able_local() Xiaoyao Li
2022-09-22 12:16 ` Wang, Wei W
2022-09-21 16:45 ` [RFC PATCH v2 2/3] perf/x86/intel/pt: Introduce and export pt_get_curr_event() Xiaoyao Li
2022-09-21 20:56 ` kernel test robot
2022-09-22 0:50 ` kernel test robot
2022-09-22 5:14 ` Xiaoyao Li
2022-09-22 12:33 ` Liang, Kan
2022-09-22 12:58 ` Wang, Wei W
2022-09-22 13:34 ` Peter Zijlstra
2022-09-22 13:59 ` Wang, Wei W
2022-09-22 14:09 ` Peter Zijlstra
2022-09-22 14:42 ` Wang, Wei W
2022-09-26 15:48 ` Liang, Kan
2022-09-26 17:24 ` Jim Mattson
2022-09-26 18:08 ` Liang, Kan
2022-09-27 14:27 ` Wang, Wei W
2022-09-27 16:52 ` Liang, Kan
2022-09-26 15:32 ` Liang, Kan [this message]
2022-09-21 16:45 ` [RFC PATCH v2 3/3] KVM: VMX: Stop/resume host PT before/after VMX transition when PT_MODE_HOST_GUEST Xiaoyao Li
2022-09-22 12:34 ` Wang, Wei W
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4320bb19-b206-97b6-4eae-093c9d815ba0@linux.intel.com \
--to=kan.liang@linux.intel.com \
--cc=acme@kernel.org \
--cc=alexander.shishkin@linux.intel.com \
--cc=jolsa@kernel.org \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-perf-users@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=mingo@redhat.com \
--cc=namhyung@kernel.org \
--cc=pbonzini@redhat.com \
--cc=peterz@infradead.org \
--cc=seanjc@google.com \
--cc=wei.w.wang@intel.com \
--cc=xiaoyao.li@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.