All of lore.kernel.org
 help / color / mirror / Atom feed
From: Wei Wang <wei.w.wang@intel.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: linux-kernel@vger.kernel.org, kvm@vger.kernel.org,
	pbonzini@redhat.com, ak@linux.intel.com, kan.liang@intel.com,
	mingo@redhat.com, rkrcmar@redhat.com, like.xu@intel.com,
	jannh@google.com, arei.gonglei@huawei.com, jmattson@google.com
Subject: Re: [PATCH v7 08/12] KVM/x86/vPMU: Add APIs to support host save/restore the guest lbr stack
Date: Wed, 10 Jul 2019 16:19:30 +0800	[thread overview]
Message-ID: <5D259F92.6030107@intel.com> (raw)
In-Reply-To: <20190709121912.GY3402@hirez.programming.kicks-ass.net>

On 07/09/2019 08:19 PM, Peter Zijlstra wrote:
>
>> For the lbr feature, could we thought of it as first come, first served?
>> For example, if we have 2 host threads who want to use lbr at the same time,
>> I think one of them would simply fail to use.
>>
>> So if guest first gets the lbr, host wouldn't take over unless some
>> userspace command (we added to QEMU) is executed to have the vCPU
>> actively stop using lbr.
> Doesn't work that way.
>
> Say you start KVM with LBR emulation, it creates this task event, it
> gets the LBR (nobody else wants it) and the guest works and starts using
> the LBR.
>
> Then the host creates a CPU LBR event and the vCPU suddenly gets denied
> the LBR and the guest no longer functions correctly.
>
> Or you should fail to VMENTER, in which case you starve the guest, but
> at least it doesn't malfunction.
>

Ok, I think we could go with the first option for now, like this:

When there are other host threads starting to use lbr, host perf notifies
kvm to disable the guest use of lbr (add a notifier_block), which includes:
  - cancel passing through lbr msrs to guest
  - upon guest access to the lbr msr (will trap to KVM now), return #GP
    (or 0).


Best,
Wei




  reply	other threads:[~2019-07-10  8:14 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-07-08  1:23 [PATCH v7 00/12] Guest LBR Enabling Wei Wang
2019-07-08  1:23 ` [PATCH v7 01/12] perf/x86: fix the variable type of the LBR MSRs Wei Wang
2019-07-08  1:23 ` [PATCH v7 02/12] perf/x86: add a function to get the lbr stack Wei Wang
2019-07-08  1:23 ` [PATCH v7 03/12] KVM/x86: KVM_CAP_X86_GUEST_LBR Wei Wang
2019-07-08  1:23 ` [PATCH v7 04/12] KVM/x86: intel_pmu_lbr_enable Wei Wang
2019-07-08  1:23 ` [PATCH v7 05/12] KVM/x86/vPMU: tweak kvm_pmu_get_msr Wei Wang
2019-07-08  1:23 ` [PATCH v7 06/12] KVM/x86: expose MSR_IA32_PERF_CAPABILITIES to the guest Wei Wang
2019-07-08  1:23 ` [PATCH v7 07/12] perf/x86: no counter allocation support Wei Wang
2019-07-08 14:29   ` Peter Zijlstra
2019-07-09  2:58     ` Wei Wang
2019-07-09  9:43       ` Peter Zijlstra
2019-07-09 11:36         ` Wei Wang
2019-07-08  1:23 ` [PATCH v7 08/12] KVM/x86/vPMU: Add APIs to support host save/restore the guest lbr stack Wei Wang
2019-07-08 14:48   ` Peter Zijlstra
2019-07-09  3:04     ` Wei Wang
2019-07-09  9:39       ` Peter Zijlstra
2019-07-09 11:34         ` Wei Wang
2019-07-09 12:19           ` Peter Zijlstra
2019-07-10  8:19             ` Wei Wang [this message]
2019-07-09 11:45   ` Peter Zijlstra
2019-07-10  8:21     ` Wei Wang
2019-07-08  1:23 ` [PATCH v7 09/12] perf/x86: save/restore LBR_SELECT on vCPU switching Wei Wang
2019-07-08  1:23 ` [PATCH v7 10/12] KVM/x86/lbr: lazy save the guest lbr stack Wei Wang
2019-07-08 14:53   ` Peter Zijlstra
2019-07-08 15:11     ` Andi Kleen
2019-07-09 11:39       ` Peter Zijlstra
2019-07-09  3:14     ` Wei Wang
2019-07-08  1:23 ` [PATCH v7 11/12] KVM/x86: remove the common handling of the debugctl msr Wei Wang
2019-07-08  1:23 ` [PATCH v7 12/12] KVM/VMX/vPMU: support to report GLOBAL_STATUS_LBRS_FROZEN Wei Wang
2019-07-08 15:09   ` Peter Zijlstra
2019-07-09  3:24     ` Wei Wang
2019-07-09 11:35       ` Peter Zijlstra
2019-07-10  9:23         ` Wei Wang

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=5D259F92.6030107@intel.com \
    --to=wei.w.wang@intel.com \
    --cc=ak@linux.intel.com \
    --cc=arei.gonglei@huawei.com \
    --cc=jannh@google.com \
    --cc=jmattson@google.com \
    --cc=kan.liang@intel.com \
    --cc=kvm@vger.kernel.org \
    --cc=like.xu@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=peterz@infradead.org \
    --cc=rkrcmar@redhat.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.