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>,
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>,
"Liang, Kan" <kan.liang@intel.com>,
"Kleen, Andi" <andi.kleen@intel.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 0/2] KVM: VMX: Fix VM entry failure on PT_MODE_HOST_GUEST while host is using PT
Date: Mon, 19 Sep 2022 10:41:18 -0400 [thread overview]
Message-ID: <b3d3fd4c-b191-c4e4-ac95-c46f944c65d6@linux.intel.com> (raw)
In-Reply-To: <DS0PR11MB63739F4DA17F30B3162837B9DC4D9@DS0PR11MB6373.namprd11.prod.outlook.com>
On 2022-09-19 9:46 a.m., Wang, Wei W wrote:
> On Friday, September 16, 2022 9:27 PM, Liang, Kan wrote:
>>> Did you mean to handle the PT event in the proposed driver API? Event
>>> status is just one of the things. There are other things if we want to
>>> make it complete for this, e.g. event->oncpu = -1, and eventually seems we will
>> re-implement perf_event_disable_*.
>>>
>>
>> As my understand, perf always check the status first. If it's a stopped or
>> inactivated event, I don't think event->oncpu will be touched. That's why I think
>> the proposed driver API should be acceptable.
>
> That's the implementation thing. We need to make it architecturally clean though.
>
>>
>>> Btw, Xiaoyao has made it work with perf_event_disable_local, and don’t have
>> that many changes.
>>> If necessary, we can post the 2nd version out to double check.
>>>
>>
>> I'm not worry about which ways (either perf_event_disable_local() or the
>> proposed PT driver API) are chosen to stop the PT. If the existing perf_event
>> interfaces can meet your requirement, that's perfect.
>>
>> My real concern is the pt_save_msr()/pt_load_msr(). I don't think it's a job for
>> KVM. See atomic_switch_perf_msrs(). It is the perf core driver rather than KVM
>> that tells which MSRs should be saved/restored in VMCS.
>> We should do the same thing for PT. (Actually, I think we already encounter
>> issues with the current KVM-dominated method. KVM saves/restores
>> unnecessary MSRs. Right?)
>>
>
> Right. It's on my plan to improve the current PT virtualization, and
> planed to be the next step after this fix. The general rule is the same: make KVM a user
> of perf, that is, we leave those save/restore work to be completely done by the
> perf (driver) side, so we will eventually remove the KVM side pt_save/load_msr.
> To be more precise, it will work as below:
> - we will create a guest event, like what we did for lbr virtualization
Another fake event? We have to specially handle it in the perf code. I
don't think it's a clean way for perf.
> - on VMEnter:
> -- perf_disable_event_local(host_event);
> -- perf_enable_event_local(guest_event);
> - on VMExit:
> -- perf_disable_event_local(guest_event);
> -- perf_enable_event_local(host_event);
Why we cannot use the same way as the perf core driver to switch the
MSRs in the VMCS?
You just need one generic function, perf_guest_get_msrs(), for both PT
and core driver. If you have to disable PT explicitly before VMCS, I
think you can do it in the PT specific perf_guest_get_msrs().
Anyway, that's an improvement for the current code. I don't have a
problem, if you prefer to separate the fix patch and improvement patch.
Thanks,
Kan
>
>> To do so, I think there may be two ways.
>> - Since MSRs have to be switched for both PT and core drivers, it sounds
>> reasonable to provide a new generic interface in the perf_event. The new
>> interface is to tell KVM which MSRs should be saved/restored. Then KVM can
>> decide to save/restore via VMCS or direct MSR access. I suspect this way
>> requires big change, but it will benefit all the drivers which have similar
>> requirements.
>> - The proposed driver API. The MSRs are saved/restored in the PT driver.
>
> As shown above, no need for those. We can completely reuse the
> perf side save/restore.
>
> Thanks,
> Wei
next prev parent reply other threads:[~2022-09-19 14:41 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-08-25 8:56 [RFC PATCH 0/2] KVM: VMX: Fix VM entry failure on PT_MODE_HOST_GUEST while host is using PT Xiaoyao Li
2022-08-25 8:56 ` [RFC PATCH 1/2] perf/x86/intel/pt: Introduce intel_pt_{stop,resume}() Xiaoyao Li
2022-08-25 15:23 ` Sean Christopherson
2022-08-25 8:56 ` [RFC PATCH 2/2] KVM: VMX: Stop/resume host PT before/after VM entry when PT_MODE_HOST_GUEST Xiaoyao Li
2022-08-25 15:34 ` Sean Christopherson
2022-08-25 15:45 ` Xiaoyao Li
2022-08-25 15:59 ` Sean Christopherson
2022-08-26 6:32 ` Xiaoyao Li
2022-08-26 15:08 ` Sean Christopherson
2022-08-29 7:49 ` [RFC PATCH 0/2] KVM: VMX: Fix VM entry failure on PT_MODE_HOST_GUEST while host is using PT Wang, Wei W
2022-08-29 7:49 ` Wang, Wei W
2022-08-29 17:33 ` Sean Christopherson
2022-08-30 6:02 ` Wang, Wei W
2022-09-08 7:25 ` Xiaoyao Li
2022-09-08 8:53 ` Wang, Wei W
2022-09-14 4:15 ` Xiaoyao Li
2022-09-14 6:16 ` Wang, Wei W
2022-09-14 20:25 ` Liang, Kan
2022-09-15 2:46 ` Wang, Wei W
2022-09-15 13:54 ` Liang, Kan
2022-09-15 14:39 ` Wang, Wei W
2022-09-15 15:42 ` Liang, Kan
2022-09-16 2:30 ` Wang, Wei W
2022-09-16 13:27 ` Liang, Kan
2022-09-19 13:46 ` Wang, Wei W
2022-09-19 14:41 ` Liang, Kan [this message]
2022-09-19 15:22 ` Wang, Wei W
2022-09-19 15:55 ` Liang, Kan
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=b3d3fd4c-b191-c4e4-ac95-c46f944c65d6@linux.intel.com \
--to=kan.liang@linux.intel.com \
--cc=acme@kernel.org \
--cc=alexander.shishkin@linux.intel.com \
--cc=andi.kleen@intel.com \
--cc=jolsa@kernel.org \
--cc=kan.liang@intel.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-perf-users@vger.kernel.org \
--cc=mark.rutland@arm.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.