kvm.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Eric Hankland <ehankland@google.com>
To: Wei Wang <wei.w.wang@intel.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>,
	rkrcmar@redhat.com, linux-kernel@vger.kernel.org,
	kvm@vger.kernel.org
Subject: Re: [PATCH v1] KVM: x86: PMU Whitelist
Date: Mon, 24 Jun 2019 17:32:41 -0700	[thread overview]
Message-ID: <CAOyeoRXr4gmbBPq1RsStoPguiZB8Jxod-irYd3Dm_AGVcQRGSQ@mail.gmail.com> (raw)
In-Reply-To: <5D036843.2010607@intel.com>

Thanks for your feedback - I'll send out an updated version
incorporating your comments shortly (assuming you don't have more
after this).

> > +struct kvm_pmu_whitelist {
> > +       __u64 event_mask;
>
> Is this "ARCH_PERFMON_EVENTSEL_EVENT | ARCH_PERFMON_EVENTSEL_UMASK"?

In most cases, I envision this being the case, but it's possible users
may want other bits - see response to the next question below.

> > +       __u16 num_events;
> > +       __u64 events[0];
>
> Can this be __u16?
> The lower 16 bits (umask+eventsel) already determines what the event is.

It looks like newer AMD processors also use bits 32-35 for eventsel
(see AMD64_EVENTSEL_EVENT/AMD64_RAW_EVENT_MASK in
arch/x86/include/asm/perf_event.h or a recent reference guide), though
it doesn't look like this has made it to pmu_amd.c in kvm yet.
Further, including the whole 64 bits could enable whitelisting some
events with particular modifiers (e.g. in_tx=0, but not in_tx=1). I'm
not sure if whitelisting with specific modifiers will be necessary,
but we definitely need more than u16 if we want to support any AMD
events that make use of those bits in the future.

> > +       struct kvm_pmu_whitelist *whitelist;
>
> This could be per-VM and under rcu?
I'll try this out in the next version.

> Why not moving this filter to reprogram_gp_counter?
>
> You could directly compare "unit_mask, event_sel"  with whitelist->events[i]
The reason is that this approach provides uniform behavior whether an
event is programmed on a fixed purpose counter vs a general purpose
one. Though I admit it's unlikely that instructions retired/cycles
wouldn't be whitelisted (and ref cycles can't be programmed on gp
counters), so it wouldn't be missing too much if I do move this to
reprogram_gp_counter. What do you think?

> I would directly return -EFAULT here.
>
> Same here.

Sounds good - I'll fix that in the next version.

> > +       pmu->whitelist = new;
>
> Forgot to copy the whitelist-ed events to new?
Yep, somehow I deleted the lines that did this - thanks for pointing it out.

  reply	other threads:[~2019-06-25  0:32 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-05-22 22:23 [PATCH v1] KVM: x86: PMU Whitelist Eric Hankland
2019-05-28  2:01 ` Wei Wang
2019-05-28 18:14   ` Eric Hankland
2019-05-29  7:54     ` Wei Wang
2019-05-29 17:11       ` Eric Hankland
2019-05-31  1:02         ` Wei Wang
2019-05-31 19:59           ` Eric Hankland
2019-06-01 10:55             ` Wei Wang
2019-06-03 17:30               ` Eric Hankland
2019-06-04  4:42                 ` Wei Wang
2019-06-04 15:56                   ` Eric Hankland
     [not found]                     ` <CAEU=KTHsVmrAHXUKdHu_OwcrZoy-hgV7pk4UymtchGE5bGdUGA@mail.gmail.com>
2019-06-05 21:35                       ` Eric Hankland
2019-06-06  7:36                         ` Wei Wang
2019-06-13 17:43                           ` Eric Hankland
2019-06-14  9:14                             ` Wei Wang
2019-06-14  9:26 ` Wei Wang
2019-06-25  0:32   ` Eric Hankland [this message]
2019-06-25  9:12     ` Wei Wang
2019-07-02 17:46       ` Eric Hankland
2019-07-03  9:06         ` 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=CAOyeoRXr4gmbBPq1RsStoPguiZB8Jxod-irYd3Dm_AGVcQRGSQ@mail.gmail.com \
    --to=ehankland@google.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --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).