Re: [Qemu-devel] pxe boot problems

[Laszlo Ersek <lersek@redhat.com>]

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 <gleb@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 <gleb@redhat.com>
>>         Signed-off-by: Avi Kivity <avi@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