From: "Xu, Like" <like.xu@intel.com>
To: Peter Zijlstra <peterz@infradead.org>,
Like Xu <like.xu@linux.intel.com>,
Paolo Bonzini <pbonzini@redhat.com>
Cc: Sean Christopherson <sean.j.christopherson@intel.com>,
Vitaly Kuznetsov <vkuznets@redhat.com>,
Wanpeng Li <wanpengli@tencent.com>,
Jim Mattson <jmattson@google.com>, Joerg Roedel <joro@8bytes.org>,
kvm@vger.kernel.org, linux-kernel@vger.kernel.org,
wei.w.wang@intel.com, ak@linux.intel.com
Subject: Re: [PATCH v10 08/11] KVM: x86/pmu: Add LBR feature emulation via guest LBR event
Date: Tue, 12 May 2020 12:58:28 +0800 [thread overview]
Message-ID: <43e093a5-61fc-815e-bec8-2a11c27d08d1@intel.com> (raw)
In-Reply-To: <20200508130931.GE5298@hirez.programming.kicks-ass.net>
On 2020/5/8 21:09, Peter Zijlstra wrote:
> On Mon, Apr 27, 2020 at 11:16:40AM +0800, Like Xu wrote:
>> On 2020/4/24 20:16, Peter Zijlstra wrote:
>>> And I suppose that is why you need that horrible:
>>> needs_guest_lbr_without_counter() thing to begin with.
>> Do you suggest to use event->attr.config check to replace
>> "needs_branch_stack(event) && is_kernel_event(event) &&
>> event->attr.exclude_host" check for guest LBR event ?
> That's what the BTS thing does.
Thanks, I'll apply it.
>
>>> Please allocate yourself an event from the pseudo event range:
>>> event==0x00. Currently we only have umask==3 for Fixed2 and umask==4
>>> for Fixed3, given you claim 58, which is effectively Fixed25,
>>> umask==0x1a might be appropriate.
>> OK, I assume that adding one more field ".config = 0x1a00" is
>> efficient enough for perf_event_attr to allocate guest LBR events.
> Uh what? The code is already setting .config. You just have to change it
> do another value.
Thanks, I'll apply it.
>
>>> Also, I suppose we need to claim 0x0000 as an error, so that other
>>> people won't try this again.
>> Does the following fix address your concern on this ?
>>
>> diff --git a/arch/x86/events/core.c b/arch/x86/events/core.c
>> index 2405926e2dba..32d2a3f8c51f 100644
>> --- a/arch/x86/events/core.c
>> +++ b/arch/x86/events/core.c
>> @@ -498,6 +498,9 @@ int x86_pmu_max_precise(void)
>>
>> int x86_pmu_hw_config(struct perf_event *event)
>> {
>> + if (!unlikely(event->attr.config & X86_ARCH_EVENT_MASK))
>> + return -EINVAL;
>> +
>> if (event->attr.precise_ip) {
>> int precise = x86_pmu_max_precise();
> That wouldn't work right for AMD. But yes, something like that.
Sure, I may figure it out and leave it in another thread.
>
>>> Also, what happens if you fail programming due to a conflicting cpu
>>> event? That pinned doesn't guarantee you'll get the event, it just means
>>> you'll error instead of getting RR.
>>>
>>> I didn't find any code checking the event state.
>>>
>> Error instead of RR is expected.
>>
>> If the KVM fails programming due to a conflicting cpu event
>> the LBR registers will not be passthrough to the guest,
>> and KVM would return zero for any guest LBR records accesses
>> until the next attempt to program the guest LBR event.
>>
>> Every time before cpu enters the non-root mode where irq is
>> disabled, the "event-> oncpu! =-1" check will be applied.
>> (more details in the comment around intel_pmu_availability_check())
>>
>> The guests administer is supposed to know the result of guest
>> LBR records is inaccurate if someone is using LBR to record
>> guest or hypervisor on the host side.
>>
>> Is this acceptable to you?
>>
>> If there is anything needs to be improved, please let me know.
> It might be nice to emit a pr_warn() or something on the host when this
> happens. Then at least the host admin can know he wrecked things for
> which guest.
Sure, I will use pr_warn () and indicate which guest it is.
If you have more comments on the patchset, please let me know.
If not, I'll spin the next version based on your current feedback.
Thanks,
Like Xu
next prev parent reply other threads:[~2020-05-12 4:58 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-23 8:14 [PATCH v10 00/11] Guest Last Branch Recording Enabling Like Xu
2020-04-23 8:14 ` [PATCH v10 01/11] perf/x86: Fix variable type for LBR registers Like Xu
2020-04-23 8:14 ` [PATCH v10 02/11] perf/x86/core: Refactor hw->idx checks and cleanup Like Xu
2020-04-23 8:14 ` [PATCH v10 03/11] perf/x86/lbr: Add interface to get basic information about LBR stack Like Xu
2020-04-23 8:14 ` [PATCH v10 04/11] perf/x86: Add constraint to create guest LBR event without hw counter Like Xu
2020-04-23 8:14 ` [PATCH v10 05/11] perf/x86: Keep LBR stack unchanged in host context for guest LBR event Like Xu
2020-04-23 8:14 ` [PATCH v10 06/11] KVM: x86: Add KVM_CAP_X86_GUEST_LBR to dis/enable LBR from user-space Like Xu
2020-04-27 16:23 ` kbuild test robot
2020-04-23 8:14 ` [PATCH v10 07/11] KVM: x86/pmu: Tweak kvm_pmu_get_msr to pass 'struct msr_data' in Like Xu
2020-04-23 8:14 ` [PATCH v10 08/11] KVM: x86/pmu: Add LBR feature emulation via guest LBR event Like Xu
2020-04-24 12:16 ` Peter Zijlstra
2020-04-27 3:16 ` Like Xu
2020-05-08 8:48 ` Like Xu
2020-05-08 13:09 ` Peter Zijlstra
2020-05-12 4:58 ` Xu, Like [this message]
2020-04-23 8:14 ` [PATCH v10 09/11] KVM: x86/pmu: Release guest LBR event via vPMU lazy release mechanism Like Xu
2020-04-28 5:06 ` kbuild test robot
2020-04-28 5:06 ` [RFC PATCH] KVM: x86/pmu: kvm_pmu_lbr_cleanup() can be static kbuild test robot
2020-04-23 8:14 ` [PATCH v10 10/11] KVM: x86: Expose MSR_IA32_PERF_CAPABILITIES for LBR record format Like Xu
2020-04-23 8:14 ` [PATCH v10 11/11] KVM: x86: Remove the common trap handler of the MSR_IA32_DEBUGCTLMSR Like Xu
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=43e093a5-61fc-815e-bec8-2a11c27d08d1@intel.com \
--to=like.xu@intel.com \
--cc=ak@linux.intel.com \
--cc=jmattson@google.com \
--cc=joro@8bytes.org \
--cc=kvm@vger.kernel.org \
--cc=like.xu@linux.intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=pbonzini@redhat.com \
--cc=peterz@infradead.org \
--cc=sean.j.christopherson@intel.com \
--cc=vkuznets@redhat.com \
--cc=wanpengli@tencent.com \
--cc=wei.w.wang@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox