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

On 14/09/2016 20:36, Andy Lutomirski wrote:

On Wed, Sep 14, 2016 at 12:28 PM, Andrew Cooper
[off-list ref] wrote:

quoted

On 14/09/2016 20:23, Boris Ostrovsky wrote:

quoted

On 09/14/2016 02:52 PM, Andy Lutomirski wrote:

quoted

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?  Should the Xen
PV rdmsr hooks or perhaps the hypervisor mask out the feature if it
isn't going to be supported?

The hypervisor uses CPUID faulting so we shouldn't advertise this
feature to guests.

In the case that the hardware has faulting, or for any HVM guest, the
extra cost to making the feature available to the guest is a single
conditional test in the cpuid path.  This is about as close to zero as a
feature gets.  We really should be offering the feature to guests, and
have it actually working.  The issue here is that it is leaking when we
weren't intending to offer it.

As long as Xen can fix this one way or the other in reasonably short
order, I think I'm okay with having Linux incorrectly think it works
on old Xen hypervisors.

For now, unilaterally hiding CPUID faulting is easy, and simple to backport.

Making the feature available for guests to use is slightly more tricky,
as the toolstack still depends on not being faulted to construct HVM
domains properly.  This is the subject of my current CPUID project,
which will result in dom0 being no more special than any other domain
(in terms of hypervisor-side cpuid handling).

~Andrew