All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Jan Beulich" <JBeulich@suse.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Cc: Kevin Tian <kevin.tian@intel.com>,
	Jun Nakajima <jun.nakajima@intel.com>,
	Xen-devel <xen-devel@lists.xen.org>
Subject: Re: [PATCH] x86/vvmx: Improvements to INVEPT instruction handling
Date: Tue, 07 Feb 2017 03:52:56 -0700	[thread overview]
Message-ID: <5899B51802000078001372E9@prv-mh.provo.novell.com> (raw)
In-Reply-To: <13012ab4-da1d-350b-22d7-bf07608c8faf@citrix.com>

>>> On 07.02.17 at 11:39, <andrew.cooper3@citrix.com> wrote:
> On 07/02/17 10:19, Jan Beulich wrote:
>>  >>> On 06.02.17 at 17:55, <andrew.cooper3@citrix.com> wrote:
>>> * Latch current once at the start.
>>>  * Avoid the memory operand read for INVEPT_ALL_CONTEXT.  Experimentally, this
>>>    is how hardware behaves, and avoids an unnecessary pagewalk.
>> Hmm, so you say #GP is being raised for all possible reasons, but
>> #PF can't result here? That would be pretty unusual instruction
>> semantics. But if it's that way (to be confirmed by Intel), and ...
> 
> No.  The memory operand is entirely ignored.  No #PF, or #GP or #SS for
> bad segment or canonical setups.

But then the #GP related checks in decode_vmx_inst() would also
need skipping.

>>>  * Reject Reg/Reg encodings of the instruction.
>> ... if this is possible to occur at all (I'd expect #UD to result instead
>> of a VM exit), then ...
> 
> I'd hope so as well.  This addition is partly from an entirely emulation
> point of view, as well as a proper sanity check of the decode.mem union
> before use.

The "entirely emulation point of view" is not realy applicable here,
as we don't decode the instruction a 2nd time (after the hardware
had done so). Sanity checking hardware produced values of course
is reasonable in places like this; I'm just not sure whether reporting
such issues as #UD to the guest is appropriate - I'd rather see the
guest killed if hardware doesn't behave itself.

>>> --- a/xen/arch/x86/hvm/vmx/vvmx.c
>>> +++ b/xen/arch/x86/hvm/vmx/vvmx.c
>>> @@ -1770,33 +1770,64 @@ int nvmx_handle_vmwrite(struct cpu_user_regs *regs)
>>>  
>>>  int nvmx_handle_invept(struct cpu_user_regs *regs)
>>>  {
>>> +    struct vcpu *curr = current;
>>> +    struct domain *currd = curr->domain;
>>>      struct vmx_inst_decoded decode;
>>> -    unsigned long eptp;
>>>      int ret;
>>>  
>>> -    if ( (ret = decode_vmx_inst(regs, &decode, &eptp, 0)) != X86EMUL_OKAY )
>>> +    if ( (ret = decode_vmx_inst(regs, &decode, NULL, 0)) != X86EMUL_OKAY )
>>>          return ret;
>>>  
>>> +    /* TODO - reject instruction completely if not configured. */
>>> +
>>> +    /* Instruction must have a memory operand. */
>>> +    if ( decode.type != VMX_INST_MEMREG_TYPE_MEMORY )
>>> +    {
>>> +        hvm_inject_hw_exception(TRAP_invalid_op, 0);
>>> +        return X86EMUL_EXCEPTION;
>>> +    }
>>> +
>>>      switch ( reg_read(regs, decode.reg2) )
>>>      {
>>>      case INVEPT_SINGLE_CONTEXT:
>>>      {
>>> -        struct p2m_domain *p2m = p2m_get_nestedp2m(current, eptp);
>>> +        struct p2m_domain *p2m;
>>> +        pagefault_info_t pfinfo;
>>> +        unsigned long eptp;
>>> +
>>> +        /* TODO - reject SINGLE_CONTEXT if not configured. */
>>> +
>>> +        ret = hvm_copy_from_guest_linear(&eptp, decode.mem, 8, 0, &pfinfo);
>> Please use sizeof(eptp) here.
> 
> Ok, but in that case eptp needs to become uint64_t to match the ABI.  In
> fact, I probably need to read all 128 bytes and perform the MBZ check on
> the 2nd word.

Oh, indeed, the more that this may also effect eventual
exceptions needing raising.

Jan


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

  reply	other threads:[~2017-02-07 10:52 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-02-06 16:55 [PATCH] x86/vvmx: Improvements to INVEPT instruction handling Andrew Cooper
2017-02-07 10:19 ` Jan Beulich
2017-02-07 10:39   ` Andrew Cooper
2017-02-07 10:52     ` Jan Beulich [this message]
2017-02-08  7:46 ` Tian, Kevin
2017-05-15 15:02   ` Andrew Cooper

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=5899B51802000078001372E9@prv-mh.provo.novell.com \
    --to=jbeulich@suse.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=jun.nakajima@intel.com \
    --cc=kevin.tian@intel.com \
    --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 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.