All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Jan Beulich" <JBeulich@suse.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Cc: Juergen Gross <jgross@suse.com>,
	Kevin Tian <kevin.tian@intel.com>, Wei Liu <wei.liu2@citrix.com>,
	Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>,
	Xen-devel <xen-devel@lists.xen.org>,
	Jun Nakajima <jun.nakajima@intel.com>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>,
	Brian Woods <brian.woods@amd.com>,
	Roger Pau Monne <roger.pau@citrix.com>
Subject: Re: [PATCH] x86/hvm: Intercept RDPMC when vPMU is disabled
Date: Mon, 25 Feb 2019 08:26:31 -0700	[thread overview]
Message-ID: <5C7409270200007800219F57@prv1-mh.provo.novell.com> (raw)
In-Reply-To: <f3f3dfb4-6c77-28e0-2ab2-d5b488111ec5@citrix.com>

>>> On 25.02.19 at 15:11, <andrew.cooper3@citrix.com> wrote:
> On 25/02/2019 13:11, Jan Beulich wrote:
>> For Intel, afaics, we indeed produce a blank CPUID leaf in
>> all cases, so the behavior looks reasonably consistent. I would
>> question though whether a blank CPUID leaf / the absence of any
>> counters wouldn't call for #UD instead of #GP(0).
> 
> RDPMC hasn't #UD'd in a quarter of a century, but does #GP in userspace
> outside of developer profiling scenarios.

I guess I could equally well say that RDPMC hasn't #GP'd for as long
for indexes zero and one.

>> Otherwise,
>> along the lines of AMD, aren't the first two indexes uniformly valid
>> for Intel?
> 
> No - its model specific behaviour.  The only difference for more modern
> systems is that they have agreed on a common behaviour.
> 
> And that is specifically why implementing 0's is a non-starter - it is
> not a remotely sensible use of time to build enough infrastructure to
> provide correct model-specific behaviour just for a corner case which
> operating systems don't encounter in practice.

No-one said you need to consider all cases. But returning zeros for
the first four (AMD) or two (Intel) counters can hardly be that big
of a problem.

Anyway - I'm not going to fight this much more, as vPMU clearly
isn't my primary area of interest. But I'll listen to further comments
from Boris, wrt giving an eventual ack.

Jan



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

  reply	other threads:[~2019-02-25 15:26 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-02-22 21:13 [PATCH] x86/hvm: Intercept RDPMC when vPMU is disabled Andrew Cooper
2019-02-22 21:58 ` Boris Ostrovsky
2019-02-22 22:44   ` Andrew Cooper
2019-02-22 23:48     ` Boris Ostrovsky
2019-02-25 13:11       ` Jan Beulich
2019-02-25 14:11         ` Andrew Cooper
2019-02-25 15:26           ` Jan Beulich [this message]
2019-02-25 21:25             ` Boris Ostrovsky

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=5C7409270200007800219F57@prv1-mh.provo.novell.com \
    --to=jbeulich@suse.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=boris.ostrovsky@oracle.com \
    --cc=brian.woods@amd.com \
    --cc=jgross@suse.com \
    --cc=jun.nakajima@intel.com \
    --cc=kevin.tian@intel.com \
    --cc=roger.pau@citrix.com \
    --cc=suravee.suthikulpanit@amd.com \
    --cc=wei.liu2@citrix.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.