All of lore.kernel.org
 help / color / mirror / Atom feed
From: Boris Ostrovsky <boris.ostrovsky@oracle.com>
To: "Kleen, Andi" <andi.kleen@intel.com>,
	"Tian, Kevin" <kevin.tian@intel.com>,
	Jan Beulich <JBeulich@suse.com>
Cc: "andrew.cooper3@citrix.com" <andrew.cooper3@citrix.com>,
	Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>,
	"Nakajima, Jun" <jun.nakajima@intel.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [PATCH v2 0/3] VPMU fixes
Date: Mon, 7 Dec 2015 18:05:58 -0500	[thread overview]
Message-ID: <566610D6.2010300@oracle.com> (raw)
In-Reply-To: <3A6EF2BBBDCC5C4E9A8DD8E0DF41A7BA5F533A59@ORSMSX104.amr.corp.intel.com>

On 12/07/2015 04:24 PM, Kleen, Andi wrote:
> I'm not aware of that specific quirk on Nehalem. Standard perf has a workaround for the errata below, but it sounds different from what you have.
>
> But if it's a NHM/WSM problem your model numbers are certainly not enough.

That's exactly the problem that we are having --- we don't know who 
exactly is affected, including whether it's limited to Nehalem.

>
> You always need some kind of limiter for the PMI because it is possible to program the PMU that PMIs/NMIs appear back-to-back and lock up the system. But just programming them to 1 is not enough in this case, really have to be limited (perf both accounts and limits the frequency in time and the total CPU consumption of the PMI).

Are you referring to 14c63f17b1 / update_perf_cpu_limits()?

> I think if you have such a generic limiter it would likely be able to handle this issue too.

In theory I think we shouldn't need to do this since when guest's VCPU 
is descheduled its PMU registers are no longer loaded into HW. So if the 
guest is programming PMU in such a way that it can no longer do any 
useful work --- well, that's the guest's problem.

The quirk that we have in Xen is apparently trying to prevent system 
lock-up.

I should also note that this only observed in HVM (i.e. with VMX) so 
perhaps this is something specific to virtualization. E.g. getting a PMI 
while executing a VMRUN or something...

>
> Comments of the Nehalem workaround in the main perf code:
>
> * Workaround for:
>   *   Intel Errata AAK100 (model 26)
>   *   Intel Errata AAP53  (model 30)
>   *   Intel Errata BD53   (model 44)
>   *
>   * The official story:
>   *   These chips need to be 'reset' when adding counters by programming the
>   *   magic three (non-counting) events 0x4300B5, 0x4300D2, and 0x4300B1 either
>   *   in sequence on the same PMC or on different PMCs.

These look like errata for *incorrect* counting and so it's up to guests 
to work around these (which the guests do, provided they have 
intel_pmu_nhm_workaround(), or an equivalent in another OS).


Thanks.
-boris


>   *
>   * In practise it appears some of these events do in fact count, and
>   * we need to programm all 4 events.
>
>           * The Errata requires below steps:
>           * 1) Clear MSR_IA32_PEBS_ENABLE and MSR_CORE_PERF_GLOBAL_CTRL;
>           * 2) Configure 4 PERFEVTSELx with the magic events and clear
>           *    the corresponding PMCx;
>           * 3) set bit0~bit3 of MSR_CORE_PERF_GLOBAL_CTRL;
>           * 4) Clear MSR_CORE_PERF_GLOBAL_CTRL;
>           * 5) Clear 4 pairs of ERFEVTSELx and PMCx;
>
> -Andi

      reply	other threads:[~2015-12-07 23:05 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-12-01 16:50 [PATCH v2 0/3] VPMU fixes Boris Ostrovsky
2015-12-01 16:50 ` [PATCH v2 1/3] x86/VPMU: Support only versions 2 through 4 of architectural performance monitoring Boris Ostrovsky
2015-12-02 14:32   ` Jan Beulich
2015-12-04  1:29   ` Tian, Kevin
2015-12-01 16:50 ` [PATCH v2 2/3] x86/VPMU: No need to check whether VPMU quirk is needed on Intel Boris Ostrovsky
2015-12-03  6:18   ` Tian, Kevin
2015-12-03 15:46     ` Boris Ostrovsky
2015-12-04  1:31       ` Tian, Kevin
2015-12-01 16:50 ` [PATCH v2 3/3] MAINTAINERS: Restore original maintainership of arch VPMU files Boris Ostrovsky
2015-12-04  1:32   ` Tian, Kevin
2015-12-02  2:20 ` [PATCH v2 0/3] VPMU fixes Tian, Kevin
2015-12-02  9:21   ` Dietmar Hahn
2015-12-03  6:16     ` Tian, Kevin
2015-12-03 10:36       ` Jan Beulich
2015-12-03 10:46         ` Tian, Kevin
2015-12-03 11:02           ` Jan Beulich
2015-12-03 15:44             ` Boris Ostrovsky
2015-12-04  1:28               ` Tian, Kevin
2015-12-07  8:23               ` Tian, Kevin
2015-12-07 21:24                 ` Kleen, Andi
2015-12-07 23:05                   ` Boris Ostrovsky [this message]

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=566610D6.2010300@oracle.com \
    --to=boris.ostrovsky@oracle.com \
    --cc=JBeulich@suse.com \
    --cc=andi.kleen@intel.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=dietmar.hahn@ts.fujitsu.com \
    --cc=jun.nakajima@intel.com \
    --cc=kevin.tian@intel.com \
    --cc=xen-devel@lists.xen.org \
    /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.