All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrew Cooper <andrew.cooper3@citrix.com>
To: Andy Lutomirski <luto@amacapital.net>,
	Kyle Huey <me@kylehuey.com>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>
Cc: Thomas Gleixner <tglx@linutronix.de>,
	John Stultz <john.stultz@linaro.org>,
	Ingo Molnar <mingo@redhat.com>, Michal Hocko <mhocko@suse.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	"Michael S. Tsirkin" <mst@redhat.com>,
	Alexander Shishkin <alexander.shishkin@linux.intel.com>,
	Aravind Gopalakrishnan <Aravind.Gopalakrishnan@amd.com>,
	Vlastimil Babka <vbabka@suse.cz>,
	"Luis R. Rodriguez" <mcgrof@kernel.org>,
	Mateusz Guzik <mguzik@redhat.com>,
	Alex Thorlton <athorlton@sgi.com>,
	"Rafael J. Wysocki" <rafael.j.wysocki@intel.com>,
	Dmitry Vyukov <dvyukov@google.com>,
	Vladimir Zapolskiy <vladimir_zapolskiy@mentor.com>,
	Jiri Slaby <jslaby@suse.cz>,
	Andrey Ryabinin <aryabinin@virtuozzo.com>,
	Ben Segall <bsegall@google.com>,
	"maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT)"
	<x86@kernel.org>, Denys Vlasenko <dvlasenk@redhat.com>,
	Paul Gortmaker <paul.gortmaker@windriver.com>,
	Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>,
	"Robert O'Callahan" <robert@ocallahan.org>,
	"open list:X86 ARCHITECTURE (32-BIT AND 64-BIT)" 
	<linux-kernel@vger.kernel.org>, Juergen Gross <jgross@suse.com>,
	Linux API <linux-api@vger.kernel.org>,
	Fenghua Yu <fenghua.yu@intel.com>,
	Kees Cook <keescook@chromium.org>,
	"Peter Zijlstra (Intel)" <peterz@infradead.org>,
	Borislav Petkov <bp@suse.de>, Len Brown <len.brown@intel.com>,
	Huang Rui <ray.huang@amd.com>, "H. Peter Anvin" <hpa@zytor.com>
Subject: Re: [PATCH] prctl,x86 Add PR_[GET|SET]_CPUID for controlling the CPUID instruction.
Date: Wed, 14 Sep 2016 20:22:42 +0100	[thread overview]
Message-ID: <daa2c246-f1dc-de80-21ad-12cb27df6d1a@citrix.com> (raw)
In-Reply-To: <CALCETrWo2XcOvnWOwU4oS-pU1+KL2PnoHa0pdFX=PA3xeM7eqg@mail.gmail.com>

On 14/09/2016 19:52, Andy Lutomirski wrote:
> On Tue, Sep 13, 2016 at 11:13 PM, Kyle Huey <me@kylehuey.com> wrote:
>> On Mon, Sep 12, 2016 at 9:56 AM, Andy Lutomirski <luto@amacapital.net> wrote:
>>> You should explicitly check that, if the
>>> feature is set under Xen PV, then the MSR actually works as
>>> advertised.  This may require talking to the Xen folks to make sure
>>> you're testing the right configuration.
>> This is interesting.  When running under Xen PV the kernel is allowed
>> to read the real value of MSR_PLATFORM_INFO and see that CPUID
>> faulting is supported.  But as you suggested, writing to
>> MSR_MISC_FEATURES_ENABLES doesn't actually enable CPUID faulting, at
>> least not in any way that works.
>>
>> It's not obvious to me how to test this, because when this feature
>> works, CPUID only faults in userspace, not in the kernel.  Is there
>> existing code somewhere that runs tests like this in userspace?
>>
> Andrew, Boris: should we expect Xen PV to do anything sensible when we
> write to MSR_PLATFORM_INFO to turn on CPUID faulting?

It will drop the write, so "No" is the answer to your question.

> Should the Xen
> PV rdmsr hooks or perhaps the hypervisor mask out the feature if it
> isn't going to be supported?

Yes.

Sadly, whomever hacked these things together in the early days decided
that the most simple solution to getting guests to boot was to allow all
domains default-read access across the CPUID and MSR space, blacklisting
out specific areas known to cause problems.  I am in the process of
sorting this stupidity^W "feature" out, but it is taking a while.

What is the purpose of the check?  I think it might be easiest to just
do the native thing, and raise a bug in general against Xen citing
"incorrect behaviour with respect to MSR_PLATFORM_INFO", get it fixed in
stable trees and pretend that this breakage never happened.

Short of having a small userspace stub check, I can't see any way to
actually test this, and I certainly would prefer to avoid workarounds
which end up like the OXSAVE detection, which is a complete disaster for
both Linux and Xen.

~Andrew

WARNING: multiple messages have this Message-ID (diff)
From: Andrew Cooper <andrew.cooper3@citrix.com>
To: Andy Lutomirski <luto@amacapital.net>,
	Kyle Huey <me@kylehuey.com>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>
Cc: Thomas Gleixner <tglx@linutronix.de>,
	John Stultz <john.stultz@linaro.org>,
	Ingo Molnar <mingo@redhat.com>, Michal Hocko <mhocko@suse.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	"Michael S. Tsirkin" <mst@redhat.com>,
	Alexander Shishkin <alexander.shishkin@linux.intel.com>,
	Aravind Gopalakrishnan <Aravind.Gopalakrishnan@amd.com>,
	Vlastimil Babka <vbabka@suse.cz>,
	"Luis R. Rodriguez" <mcgrof@kernel.org>,
	Mateusz Guzik <mguzik@redhat.com>,
	Alex Thorlton <athorlton@sgi.com>,
	"Rafael J. Wysocki" <rafael.j.wysocki@intel.com>,
	Dmitry Vyukov <dvyukov@google.com>,
	Vladimir Zapolskiy <vladimir_zapolskiy@mentor.com>,
	Jiri Slaby <jslaby@suse.cz>,
	Andrey Ryabinin <aryabinin@virtuozzo.com>,
	Ben Segall <bsegall@google.com>,
	maintainer:X86 ARCHITECTURE (32-BIT
Subject: Re: [PATCH] prctl,x86 Add PR_[GET|SET]_CPUID for controlling the CPUID instruction.
Date: Wed, 14 Sep 2016 20:22:42 +0100	[thread overview]
Message-ID: <daa2c246-f1dc-de80-21ad-12cb27df6d1a@citrix.com> (raw)
In-Reply-To: <CALCETrWo2XcOvnWOwU4oS-pU1+KL2PnoHa0pdFX=PA3xeM7eqg@mail.gmail.com>

On 14/09/2016 19:52, Andy Lutomirski wrote:
> On Tue, Sep 13, 2016 at 11:13 PM, Kyle Huey <me@kylehuey.com> wrote:
>> On Mon, Sep 12, 2016 at 9:56 AM, Andy Lutomirski <luto@amacapital.net> wrote:
>>> You should explicitly check that, if the
>>> feature is set under Xen PV, then the MSR actually works as
>>> advertised.  This may require talking to the Xen folks to make sure
>>> you're testing the right configuration.
>> This is interesting.  When running under Xen PV the kernel is allowed
>> to read the real value of MSR_PLATFORM_INFO and see that CPUID
>> faulting is supported.  But as you suggested, writing to
>> MSR_MISC_FEATURES_ENABLES doesn't actually enable CPUID faulting, at
>> least not in any way that works.
>>
>> It's not obvious to me how to test this, because when this feature
>> works, CPUID only faults in userspace, not in the kernel.  Is there
>> existing code somewhere that runs tests like this in userspace?
>>
> Andrew, Boris: should we expect Xen PV to do anything sensible when we
> write to MSR_PLATFORM_INFO to turn on CPUID faulting?

It will drop the write, so "No" is the answer to your question.

> Should the Xen
> PV rdmsr hooks or perhaps the hypervisor mask out the feature if it
> isn't going to be supported?

Yes.

Sadly, whomever hacked these things together in the early days decided
that the most simple solution to getting guests to boot was to allow all
domains default-read access across the CPUID and MSR space, blacklisting
out specific areas known to cause problems.  I am in the process of
sorting this stupidity^W "feature" out, but it is taking a while.

What is the purpose of the check?  I think it might be easiest to just
do the native thing, and raise a bug in general against Xen citing
"incorrect behaviour with respect to MSR_PLATFORM_INFO", get it fixed in
stable trees and pretend that this breakage never happened.

Short of having a small userspace stub check, I can't see any way to
actually test this, and I certainly would prefer to avoid workarounds
which end up like the OXSAVE detection, which is a complete disaster for
both Linux and Xen.

~Andrew

  reply	other threads:[~2016-09-14 19:34 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-09-12  0:29 [PATCH] prctl,x86 Add PR_[GET|SET]_CPUID for controlling the CPUID instruction Kyle Huey
2016-09-12  0:29 ` Kyle Huey
2016-09-12  9:07 ` Borislav Petkov
2016-09-12  9:07   ` Borislav Petkov
2016-09-12 14:15   ` Kyle Huey
2016-09-12 14:15     ` Kyle Huey
2016-09-12 14:34     ` Borislav Petkov
2016-09-12 14:34       ` Borislav Petkov
2016-09-12 14:34       ` Borislav Petkov
2016-09-13 18:42     ` Kyle Huey
2016-09-13 18:42       ` Kyle Huey
2016-09-12 16:56 ` Andy Lutomirski
2016-09-12 16:56   ` Andy Lutomirski
2016-09-12 17:18   ` Borislav Petkov
2016-09-12 17:18     ` Borislav Petkov
2016-09-12 17:56   ` Jann Horn
2016-09-12 17:56     ` Jann Horn
2016-09-12 21:07     ` Andy Lutomirski
2016-09-12 21:07       ` Andy Lutomirski
2016-09-14  6:13   ` Kyle Huey
2016-09-14  6:13     ` Kyle Huey
2016-09-14 18:52     ` Andy Lutomirski
2016-09-14 18:52       ` Andy Lutomirski
2016-09-14 19:22       ` Andrew Cooper [this message]
2016-09-14 19:22         ` Andrew Cooper
2016-09-14 19:23       ` Boris Ostrovsky
2016-09-14 19:23         ` Boris Ostrovsky
2016-09-14 19:28         ` Andrew Cooper
2016-09-14 19:28           ` Andrew Cooper
2016-09-14 19:36           ` Andy Lutomirski
2016-09-14 19:36             ` Andy Lutomirski
2016-09-14 19:42             ` Andrew Cooper
2016-09-14 19:42               ` Andrew Cooper
2016-09-14 19:42             ` [PATCH] prctl, x86 " Andrew Cooper
2016-09-12 17:37 ` [PATCH] prctl,x86 " Andi Kleen
2016-09-12 18:25   ` Henrique de Moraes Holschuh

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=daa2c246-f1dc-de80-21ad-12cb27df6d1a@citrix.com \
    --to=andrew.cooper3@citrix.com \
    --cc=Aravind.Gopalakrishnan@amd.com \
    --cc=akpm@linux-foundation.org \
    --cc=alexander.shishkin@linux.intel.com \
    --cc=aryabinin@virtuozzo.com \
    --cc=athorlton@sgi.com \
    --cc=boris.ostrovsky@oracle.com \
    --cc=bp@suse.de \
    --cc=bsegall@google.com \
    --cc=dvlasenk@redhat.com \
    --cc=dvyukov@google.com \
    --cc=fenghua.yu@intel.com \
    --cc=hpa@zytor.com \
    --cc=jgross@suse.com \
    --cc=john.stultz@linaro.org \
    --cc=jslaby@suse.cz \
    --cc=keescook@chromium.org \
    --cc=len.brown@intel.com \
    --cc=linux-api@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luto@amacapital.net \
    --cc=mcgrof@kernel.org \
    --cc=me@kylehuey.com \
    --cc=mguzik@redhat.com \
    --cc=mhocko@suse.com \
    --cc=mingo@redhat.com \
    --cc=mst@redhat.com \
    --cc=paul.gortmaker@windriver.com \
    --cc=peterz@infradead.org \
    --cc=rafael.j.wysocki@intel.com \
    --cc=ray.huang@amd.com \
    --cc=robert@ocallahan.org \
    --cc=srinivas.pandruvada@linux.intel.com \
    --cc=tglx@linutronix.de \
    --cc=vbabka@suse.cz \
    --cc=vladimir_zapolskiy@mentor.com \
    --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.