On 01/29/14 18:47, Paolo Bonzini wrote:
> Il 29/01/2014 18:34, Laszlo Ersek ha scritto:
>> KVM chokes on the LJMPW instruction. (It needs to emulate it on this
>> host CPU, but the emulation code fails to decode the instruction.)
>>
>> I *guess* upstream Linux commit
>>
>> commit 414e6277fd148f6470261cef50a7fed0d88a2825
>> Author: Gleb Natapov <g...@redhat.com>
>> Date: Wed Apr 28 19:15:26 2010 +0300
>>
>> KVM: x86 emulator: handle "far address" source operand
>>
>> ljmp/lcall instruction operand contains address and segment.
>> It can be 10 bytes long. Currently we decode it as two different
>> operands. Fix it by introducing new kind of operand that can hold
>> entire far address.
>>
>> Signed-off-by: Gleb Natapov <g...@redhat.com>
>> Signed-off-by: Avi Kivity <a...@redhat.com>
>>
>> which had been first released in v2.6.36, should be ported to the RHEL-6
>> kernel.
>
> That's a candidate, but the commit does not say _what_ is being fixed
> exactly and the RHEL6 kernel does have code to decode 0xea.
Yes, but as far I can see, the commit (which is not in RHEL-6) changes
*how* the operand of ljmp is decoded.
>From "opcode_table" in RHEL-6's "arch/x86/kvm/emulate.c":
/* 0xE8 - 0xEF */
SrcImm | Stack, SrcImm | ImplicitOps,
SrcImmU | Src2Imm16 | No64, SrcImmByte | ImplicitOps,
^^^^^^^^^^^^^^^^^^^^^^^^^^
and the patch changes that to
SrcImmFAddr | No64
and adds new logic to fetch this source operand type.
... Which then seems to have an effect on what goes into
load_segment_descriptor() as segment selector, in the emulation of 0xea.
Of course I'm insufficiently equipped to debate this with you in earnest
:), but it seemed relevant to me.
Thanks,
Laszlo
