Thread (16 messages) 16 messages, 6 authors, 2016-09-14

Re: [PATCH] prctl,x86 Add PR_[GET|SET]_CPUID for controlling the CPUID instruction.

flat view

From: Andrew Cooper <hidden>
Date: 2016-09-14 19:34:22
Also in: lkml

On 14/09/2016 19:52, Andy Lutomirski wrote:
On Tue, Sep 13, 2016 at 11:13 PM, Kyle Huey [off-list ref] wrote:
quoted
On Mon, Sep 12, 2016 at 9:56 AM, Andy Lutomirski [off-list ref] wrote:
quoted
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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help