From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:33182) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W8ZZh-0000LX-7Z for qemu-devel@nongnu.org; Wed, 29 Jan 2014 13:09:27 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1W8ZZb-0003k1-8A for qemu-devel@nongnu.org; Wed, 29 Jan 2014 13:09:21 -0500 Received: from mx1.redhat.com ([209.132.183.28]:42080) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W8ZZa-0003iv-Uk for qemu-devel@nongnu.org; Wed, 29 Jan 2014 13:09:15 -0500 Message-ID: <52E943C4.70409@redhat.com> Date: Wed, 29 Jan 2014 19:09:08 +0100 From: Laszlo Ersek MIME-Version: 1.0 References: <24E144B8C0207547AD09C467A8259F755935FEE9@lisa.maurer-it.com> <52E8FB96.2010801@redhat.com> <52E93B8F.5040600@redhat.com> <52E93E94.10409@redhat.com> In-Reply-To: <52E93E94.10409@redhat.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] pxe boot problems List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: Marcelo Tosatti , Gerd Hoffmann , Dietmar Maurer , "qemu-devel@nongnu.org" 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 >> 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 >> Signed-off-by: Avi Kivity >> >> 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