> On Nov 5, 2014, at 14:18, Paolo Bonzini <pbonz...@redhat.com> wrote:
>
>
>
> On 02/11/2014 10:55, Nadav Amit wrote:
>> Commit 3b32004a66e9 ("KVM: x86: movnti minimum op size of 32-bit is not
>> kept")
>> did not fully fix the minimum operand size of MONTI emulation. Still, MOVNTI
>> may be mistakenly performed using 16-bit opsize.
>>
>> This patch add No16 flag to mark an instruction does not support 16-bits
>> operand size.
>
> So a
>
> .byte 0x66
> movntiw (%esi), %eax
>
> will zero the higher two bytes of %eax before this patch, and load 4
> bytes from (%esi) after?
>
Well, actually the 0x66 prefix is an illegal prefix for this instruction, so it
will cause #UD.
But if the default operand size is 16 (e.g., CS.D = 0), then yes - after this
patch it will load 4 bytes from (%esi), and this is the expected behaviour.
Here is a small test to show the behaviour (build with -m32 ).
We set CS to 16-bit segment, so default operand size is 16-bit, but 32-bits are
assigned.
If you replace movntil with movl, you’ll see only 16-bits are stored, as you
would expect from mov.
---
#include <sys/types.h>
#include <asm/ldt.h>
#include <stdio.h>
int main()
{
unsigned int a = 0;
unsigned int b = 0x87654321u;
struct user_desc d = {
.entry_number = 0,
.base_addr = 0,
.limit = 0xfffffu,
.seg_32bit = 0,
.contents = 2,
.read_exec_only = 1,
.limit_in_pages = 1,
.seg_not_present = 0,
.useable = 1,
};
modify_ldt(1, &d, sizeof(d));
asm volatile ( "lcall $0x7, $1f\n\t"
"jmp 2f\n\t"
"1: .byte 0x67\n\t"
"movntil %%ebx, (%%eax)\n\t"
".byte 0x66\n\t"
"lret\n\t"
"2:\n\t"
: : "a"(&a), "b"(b) : "memory");
printf("result %x\n", a);
return 0;
}
---
Nadav
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
