LKML Archive on
help / color / mirror / Atom feed
From: Wei Wang <>
To: Eric Hankland <>
Subject: Re: [PATCH v1] KVM: x86: PMU Whitelist
Date: Sat, 01 Jun 2019 18:55:23 +0800	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On 06/01/2019 03:59 AM, Eric Hankland wrote:
> With anythread=0, I'm not aware of any events that directly give info
> about other VMs, but monitoring events related to shared resources
> (e.g. LLC References and LLC Misses) could indirectly give you info
> about how heavily other users are using that resource.

My question is that have we proved that this indirect info leakage 
indeed happens?
The spec states that the counter will count the related events generated by
the logical CPU with AnyThread=0. I would be inclined to trust the 
hardware behavior
documented in the spec unless we could prove there is a problem.

> I tried returning 1 when the guest tries to write the eventsel msr for
> a disallowed event - the behavior on modern guest kernels looks
> reasonable (warns once about an unchecked MSR access error), but it
> looks like guests using older kernels (older than 2016) might panic
> due to the gpfault (not to mention I'm not sure about the behavior on
> non-linux kernels). So I'm hesitant to return 1 - what do you think?

 From the guest point of view, returning 0 means that the event counting 
is running well.
That is, the guest is expecting to get some count numbers. So better not 
to zero the value
when the guest does rdpmc/rdmsr to get the count in this case.

I think we could just ensure "AnyThread=0" in the config, and create the 
counter as usual.

> I also looked into moving from a vcpu ioctl to a vm ioctl - I can send
> out a version of the patch with this change once we settle on the
> other issues. It will involve some extra locking every time the
> counters are programmed to ensure the whitelist or blacklist isn't
> removed during access.

Yes, the above discussion needs to be done first.


  reply	other threads:[~2019-06-01 10:50 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-05-22 22:23 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 [this message]
2019-06-03 17:30               ` Eric Hankland
2019-06-04  4:42                 ` Wei Wang
2019-06-04 15:56                   ` Eric Hankland
     [not found]                     ` <>
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
2019-06-25  9:12     ` Wei Wang
2019-07-02 17:46       ` Eric Hankland
2019-07-03  9:06         ` Wei Wang
2019-06-20 18:05 ` Andi Kleen
2019-06-24 23:56   ` Eric Hankland

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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \ \
    --subject='Re: [PATCH v1] KVM: x86: PMU Whitelist' \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

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