[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] pxe boot problems
From: |
Laszlo Ersek |
Subject: |
Re: [Qemu-devel] pxe boot problems |
Date: |
Wed, 29 Jan 2014 19:09:08 +0100 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20131118 Thunderbird/17.0.11 |
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 <address@hidden>
>> 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 <address@hidden>
>> Signed-off-by: Avi Kivity <address@hidden>
>>
>> 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