public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Nadav Amit <nadav.amit@gmail.com>
To: Paolo Bonzini <pbonzini@redhat.com>,
	Nadav Amit <namit@cs.technion.ac.il>
Cc: gleb@kernel.org, tglx@linutronix.de, mingo@redhat.com,
	hpa@zytor.com, x86@kernel.org, linux-kernel@vger.kernel.org,
	kvm@vger.kernel.org
Subject: Re: [PATCH v2 9/9] KVM: vmx: vmx instructions handling does not consider cs.l
Date: Wed, 18 Jun 2014 19:01:50 +0300	[thread overview]
Message-ID: <53A1B7EE.7070800@gmail.com> (raw)
In-Reply-To: <53A1B33A.3080509@redhat.com>

On 6/18/14, 6:41 PM, Paolo Bonzini wrote:
> Il 18/06/2014 16:19, Nadav Amit ha scritto:
>> VMX instructions use 32-bit operands in 32-bit mode, and 64-bit
>> operands in
>> 64-bit mode.  The current implementation is broken since it does not
>> use the
>> register operands correctly, and always uses 64-bit for reads and writes.
>> Moreover, write to memory in vmwrite only considers long-mode, so it
>> ignores
>> cs.l. This patch fixes this behavior.  The field of vmread/vmwrite is
>> kept
>> intentionally as 64-bit read since if bits [63:32] are not cleared the
>> instruction should fail, according to Intel SDM.
>
> This is not how I read the SDM:
>
> "These instructions fail if given, in 64-bit mode, an operand that sets
> an encoding bit beyond bit 32." (Section 24.11.1.2)
>
> "Outside IA-32e mode, the source operand has 32 bits, regardless of the
> value of CS.D. In 64-bit mode, the source operand has 64 bits; however,
> if bits 63:32 of the source operand are not zero, VMREAD will fail due
> to an attempt to access an unsupported VMCS component (see operation
> section)." (Description of VMREAD in Chapter 30).
>
> I'll fix up the patch myself.
>

Perhaps I am missing something, but I don't see where my mistake is.
The VMREAD source operand is always read as 64-bits and I made no 
changes there. Therefore, if bits 63:32 are not zero, the instruction 
should fail when attempting to access the field.

The value in the source operand of VMWRITE which represents the value 
which should be written is zero-extended outside 64-bit mode.
Quoting: "The effective size of the primary source operand, which may be 
a register or in memory, is always 32 bits outside IA-32e mode (the 
setting of CS.D is ignored with respect to operand size) and 64 bits in 
64-bit mode." (Description of VMWRITE in chapter 30).

Regards,
Nadav



  reply	other threads:[~2014-06-18 16:01 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-06-15 13:12 [PATCH 0/6] KVM: x86: More emulator bugs Nadav Amit
2014-06-15 13:12 ` [PATCH 1/6] KVM: x86: bit-ops emulation ignores offset on 64-bit Nadav Amit
2014-06-15 13:12 ` [PATCH 2/6] KVM: x86: Wrong emulation on 'xadd X, X' Nadav Amit
2014-06-16 17:38   ` Bandan Das
2014-06-17  5:16     ` Paolo Bonzini
2014-06-17 15:35       ` Bandan Das
2014-06-17 16:49         ` Paolo Bonzini
2014-06-15 13:12 ` [PATCH 3/6] KVM: x86: Inter privilage level ret emulation is not implemeneted Nadav Amit
2014-06-15 13:13 ` [PATCH 4/6] KVM: x86: emulation of dword cmov on long-mode should clear [63:32] Nadav Amit
2014-06-15 13:13 ` [PATCH 5/6] KVM: x86: NOP emulation clears (incorrectly) the high 32-bits of RAX Nadav Amit
2014-06-15 13:13 ` [PATCH 6/6] KVM: x86: check DR6/7 high-bits are clear only on long-mode Nadav Amit
2014-06-16 10:17   ` Paolo Bonzini
2014-06-16 10:33     ` Nadav Amit
2014-06-16 11:09       ` Paolo Bonzini
2014-06-16 11:53         ` Nadav Amit
2014-06-16 14:56           ` Paolo Bonzini
2014-06-16 17:07             ` Nadav Amit
2014-06-18 14:19             ` [PATCH v2 0/9] KVM: x86: More emulator bugs Nadav Amit
2014-06-18 14:19               ` [PATCH v2 1/9] KVM: x86: bit-ops emulation ignores offset on 64-bit Nadav Amit
2014-06-18 14:19               ` [PATCH v2 2/9] KVM: x86: Wrong emulation on 'xadd X, X' Nadav Amit
2014-06-18 14:19               ` [PATCH v2 3/9] KVM: x86: Inter privilage level ret emulation is not implemeneted Nadav Amit
2014-06-18 14:19               ` [PATCH v2 4/9] KVM: x86: emulation of dword cmov on long-mode should clear [63:32] Nadav Amit
2014-06-18 14:19               ` [PATCH v2 5/9] KVM: x86: NOP emulation clears (incorrectly) the high 32-bits of RAX Nadav Amit
2014-06-18 14:19               ` [PATCH v2 6/9] KVM: x86: check DR6/7 high-bits are clear only on long-mode Nadav Amit
2014-06-18 14:19               ` [PATCH v2 7/9] KVM: x86: Hypercall handling does not considers opsize correctly Nadav Amit
2014-06-18 14:19               ` [PATCH v2 8/9] KVM: vmx: handle_cr ignores 32/64-bit mode Nadav Amit
2014-06-18 14:19               ` [PATCH v2 9/9] KVM: vmx: vmx instructions handling does not consider cs.l Nadav Amit
2014-06-18 15:41                 ` Paolo Bonzini
2014-06-18 16:01                   ` Nadav Amit [this message]
2014-06-18 16:06                     ` Paolo Bonzini
2014-06-18 17:51                       ` Nadav Amit
2014-06-19  9:45                         ` Paolo Bonzini
2014-06-18 15:45               ` [PATCH v2 0/9] KVM: x86: More emulator bugs Paolo Bonzini
2014-06-16 10:18 ` [PATCH 0/6] " Paolo Bonzini

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=53A1B7EE.7070800@gmail.com \
    --to=nadav.amit@gmail.com \
    --cc=gleb@kernel.org \
    --cc=hpa@zytor.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=namit@cs.technion.ac.il \
    --cc=pbonzini@redhat.com \
    --cc=tglx@linutronix.de \
    --cc=x86@kernel.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