xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
From: Andrew Cooper <andrew.cooper3@citrix.com>
To: Jan Beulich <JBeulich@suse.com>, Kyle Huey <me@kylehuey.com>
Cc: Kevin Tian <kevin.tian@intel.com>,
	Robert O'Callahan <robert@ocallahan.org>,
	Jun Nakajima <jun.nakajima@intel.com>,
	xen-devel@lists.xen.org
Subject: Re: [PATCH v2 2/2] x86/Intel: virtualize support for cpuid faulting
Date: Fri, 14 Oct 2016 15:46:35 +0100	[thread overview]
Message-ID: <c9da1c89-24e3-eaa5-9552-fb19f0fc5ef5@citrix.com> (raw)
In-Reply-To: <5800E5E7020000780011767E@prv-mh.provo.novell.com>

On 14/10/16 13:04, Jan Beulich wrote:
>>>> On 13.10.16 at 23:09, <me@kylehuey.com> wrote:
>> --- a/xen/arch/x86/traps.c
>> +++ b/xen/arch/x86/traps.c
>> @@ -1315,16 +1315,20 @@ static int emulate_forced_invalid_op(struct cpu_user_regs *regs)
>>      /* We only emulate CPUID. */
>>      if ( ( rc = copy_from_user(instr, (char *)eip, sizeof(instr))) != 0 )
>>      {
>>          propagate_page_fault(eip + sizeof(instr) - rc, 0);
>>          return EXCRET_fault_fixed;
>>      }
>>      if ( memcmp(instr, "\xf\xa2", sizeof(instr)) )
>>          return 0;
>> +    /* Let the guest have this one */
>> +    if ( current->arch.cpuid_fault && !guest_kernel_mode(current, regs) )
>> +        return 0;
>> +
> I think another blank line ahead of the addition would be nice. I also
> think the comment should include the conditional aspect of what is
> says (same on the second instance below).
>
> And then there is the question of state here: There's no rIP update
> ahead of here, yet I'm uncertain whether we can expect the guest
> kernel to handle both bare and Xen-prefixed CPUID instructions.
> Andrew, what do you think?

The #GP fault handed back to the guest kernel should point at the cpuid
instruction, not the ud2 of the FEP.

In reality, the only real use of this path from userspace is the
`xen-detect` utility.  Regular userspace shouldn't know or care. 
Therefore, I am not concerned about the fact that it causes an implicit
change of information source.


I have taken the liberty of writing a CPUID Faulting XTF test, which
should cover all the intended guest-side behaviour (although I did code
it without a hypervisor side implementation, so I don't guarantee it is
bug-free).

The test can be found
http://xenbits.xen.org/gitweb/?p=people/andrewcoop/xen-test-framework.git;a=shortlog;h=refs/heads/cpuid-faulting
and general docs on using XTF can be found
http://xenbits.xen.org/docs/xtf/index.html  After cloning and building,
use "./xtf-runner cpuid-faulting" to run the test in all types of VM.

In particular, it will catch this specific issue when the exception
frame from an emulated cpuid doesn't point at the cpuid instruction.

Would you mind trying out this test?  Ideally, we would look to putting
it (or a bugfixed version of it) into our CI system at the same time as
the hypervisor support gets accepted.

~Andrew

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

  reply	other threads:[~2016-10-14 14:46 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-10-13 21:09 [PATCH v2] x86/Intel: virtualize support for cpuid faulting Kyle Huey
2016-10-13 21:09 ` [PATCH v2 1/2] x86/Intel: Expose cpuid_faulting_enabled so it can be used elsewhere Kyle Huey
2016-10-14 11:51   ` Jan Beulich
2016-10-13 21:09 ` [PATCH v2 2/2] x86/Intel: virtualize support for cpuid faulting Kyle Huey
2016-10-14 12:04   ` Jan Beulich
2016-10-14 14:46     ` Andrew Cooper [this message]
2016-10-14 17:05       ` Kyle Huey
2016-10-14 17:18         ` Andrew Cooper
2016-10-14 19:28           ` Kyle Huey
2016-10-17  9:23             ` Andrew Cooper
2016-10-14 19:36           ` Kyle Huey
2016-10-17 12:34             ` Andrew Cooper
2016-10-17 16:28               ` Kyle Huey
2016-10-17 16:39                 ` Andrew Cooper
2016-10-17 17:42                   ` Kyle Huey

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=c9da1c89-24e3-eaa5-9552-fb19f0fc5ef5@citrix.com \
    --to=andrew.cooper3@citrix.com \
    --cc=JBeulich@suse.com \
    --cc=jun.nakajima@intel.com \
    --cc=kevin.tian@intel.com \
    --cc=me@kylehuey.com \
    --cc=robert@ocallahan.org \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).