Re: [Xen-devel] [PATCH v2 2/3] x86 Test and expose CPUID faulting capabilities in /proc/cpuinfo

From: Andy Lutomirski
Date: Thu Sep 15 2016 - 15:38:02 EST

On Thu, Sep 15, 2016 at 12:11 PM, Kyle Huey <me@xxxxxxxxxxxx> wrote:
> On Thu, Sep 15, 2016 at 3:25 AM, Jan Beulich <JBeulich@xxxxxxxx> wrote:
>>>>> On 15.09.16 at 12:05, <david.vrabel@xxxxxxxxxx> wrote:
>>> On 14/09/16 22:01, Kyle Huey wrote:
>>>> Xen advertises the underlying support for CPUID faulting but not does pass
>>>> through writes to the relevant MSR, nor does it virtualize it, so it does
>>>> not actually work. For now mask off the relevant bit on MSR_PLATFORM_INFO.
>>> Could you clarify in the commit message that it is PV guests that are
>>> affected.
>> What makes you think HVM ones aren't?
> Testing on EC2, HVM guests are affected as well. Not sure what to do
> about that.

It's kind of nasty, but it shouldn't be *too* hard to probe for this
thing during early boot. Allocate a page somewhere that has the user
bit set, put something like this in it:

inc %eax /* return 1 */
movw %ax, %ss /* force %GP to get out of here */

Call it like this from asm (real asm, not inline):

pushq %rbx

xorl %eax, %eax

/* Push return frame */
pushq %ss
pushq %rsp
addq $8, (%rsp)
pushq %cs
pushq $end_of_cpuid_faulting_test

/* Call it! */
pushq $__USER_DS
pushq $0
pushq $X86_EFLAGS_FIXED /* leave IF off when running the CPL3 stub */
pushq $__USER_CS
pushq [address of userspace stub]

pop %rbx


Run this after the main GDT is loaded but while the #GP vector is
temporarily pointing to:

movq SS-RIP(%rsp), %rsp /* pop the real return frame */

and with interrupts off. The function should return 0 if CPUID
faulting works and 1 if it doesn't.

Yeah, this is gross, but it should work. I'm not sure how okay I am
with putting this crap in the kernel...