All of lore.kernel.org
 help / color / mirror / Atom feed
From: Thomas Gleixner <tglx@linutronix.de>
To: Andi Kleen <andi@firstfloor.org>
Cc: peterz@infradead.org, x86@kernel.org,
	linux-kernel@vger.kernel.org, eranian@google.com,
	kan.liang@intel.com, isaku.yamahata@intel.com,
	kvm@vger.kernel.org, Andi Kleen <ak@linux.intel.com>
Subject: Re: [PATCH v1 2/2] perf/x86/kvm: Avoid unnecessary work in guest filtering
Date: Sat, 6 Oct 2018 18:13:57 +0200 (CEST)	[thread overview]
Message-ID: <alpine.DEB.2.21.1810061811020.5454@nanos.tec.linutronix.de> (raw)
In-Reply-To: <alpine.DEB.2.21.1810061632100.5454@nanos.tec.linutronix.de>

On Sat, 6 Oct 2018, Thomas Gleixner wrote:

> On Fri, 5 Oct 2018, Andi Kleen wrote:
> > Some time ago KVM added a workaround for PEBS events leaking
> > into guests. This uses the KVM entry/exit list to add an extra
> > disable of the PEBS_ENABLE MSR.
> > 
> > Intel also added a fix for this issue to microcode updates on
> > Haswell/Broadwell/Skylake.
> > 
> > It turns out using the MSR entry/exit list makes VM exits
> > significantly slower. The list is only needed for disabling
> > PEBS, because the GLOBAL_CTRL change gets optimized by
> > KVM into changing the VMCS.
> > 
> > This patch checks for the microcode updates that have the microcode
> 
> # grep "This patch" Documentation/process
> 
> > fix for leaking PEBS, and disables the extra entry/exit list
> > entry for PEBS_ENABLE. In addition we always clear the
> > GLOBAL_CTRL for the PEBS counter while running in the guest,
> > which is enough to make them never fire at the wrong
> > side of the host/guest transition.
> >  
> > +#define IUCODE(model, step, rev) \
> > +	{ X86_VENDOR_INTEL, 6, model, step, rev, 0, 0 }
> 
> So we are going to have this kind of defines on every usage site. Please
> put these macros into the corresponding header file.
> 
> Also this wants to be named INTEL_MIN_UCODE() so it's clear what this is
> about.

And please use designated initializers. That way the unused fields do not
need explicit zeroing and any change of the data structure either just
works or the compiler catches the breakage.

Thanks,

	tglx

      reply	other threads:[~2018-10-06 16:14 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-10-06  0:19 [PATCH v1 1/2] x86/cpufeature: Add facility to match microcode revisions Andi Kleen
2018-10-06 14:14 ` Thomas Gleixner
2018-10-06 16:10   ` Thomas Gleixner
2018-10-06 18:15   ` Andi Kleen
2018-10-06 18:39     ` Borislav Petkov
2018-10-07  5:32     ` Thomas Gleixner
     [not found] ` <20181006001928.28097-2-andi@firstfloor.org>
2018-10-06 14:40   ` [PATCH v1 2/2] perf/x86/kvm: Avoid unnecessary work in guest filtering Thomas Gleixner
2018-10-06 16:13     ` Thomas Gleixner [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=alpine.DEB.2.21.1810061811020.5454@nanos.tec.linutronix.de \
    --to=tglx@linutronix.de \
    --cc=ak@linux.intel.com \
    --cc=andi@firstfloor.org \
    --cc=eranian@google.com \
    --cc=isaku.yamahata@intel.com \
    --cc=kan.liang@intel.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=peterz@infradead.org \
    --cc=x86@kernel.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.