linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Peter Zijlstra <peterz@infradead.org>
To: Wei Wang <wei.w.wang@intel.com>
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: Tue, 9 Jul 2019 14:19:12 +0200	[thread overview]
Message-ID: <20190709121912.GY3402@hirez.programming.kicks-ass.net> (raw)
In-Reply-To: <5D247BC2.70104@intel.com>

On Tue, Jul 09, 2019 at 07:34:26PM +0800, Wei Wang wrote:

> > But what about the counter scheduling rules;
> 
> The counter is emulated independent of the lbr emulation.

> > what happens when a CPU
> > event claims the LBR before the task event can claim it? CPU events have
> > precedence over task events.
> 
> I think the precedence (cpu pined and task pined) is for the counter
> multiplexing,
> right?

No; for all scheduling. The order is:

  CPU-pinned
  Task-pinned
  CPU-flexible
  Task-flexible

The way you created the event it would land in 'task-flexible', but even
if you make it task-pinned, a CPU (or CPU-pinned) event could claim the
LBR before your fake event.

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


  reply	other threads:[~2019-07-09 12:19 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 [this message]
2019-07-10  8:19             ` Wei Wang
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=20190709121912.GY3402@hirez.programming.kicks-ass.net \
    --to=peterz@infradead.org \
    --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=rkrcmar@redhat.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;
as well as URLs for NNTP newsgroup(s).