On 01/29/14 19:13, Paolo Bonzini wrote: > Il 29/01/2014 19:09, Laszlo Ersek ha scritto: >> 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. > > Yeah, it seems relevant to me too. > > But before it was decoding two immediates, one after another, the first > c->op_bytes long in c->src, and the second 2 bytes long in c->src2. Now > it's doing the same, but putting all c->op_bytes+2 bytes in c->src...
You were right (what a surprise! :)) First (as I suspected) when unrestricted_guest is supported and enabled on the host, everything works. In case unrestricted_guest is either unsupported or disabled, the symptom manifests itself. I added some debug messages to the emulation code in KVM where I expected something to go wrong (near 0xea (jmp far) and near Src2Imm16). Nothing was printed, indicating that the emulation code never ran. I looked up the hardware exit reason in the report (80000021) -- it's EXIT_REASON_INVALID_STATE. Thus I started browsing the KVM commit log for "unrestricted". Obviously the commit I first found had to be commit daf727225b8abfdfe424716abac3d15a3ac5626a Author: Paolo Bonzini <pbonz...@redhat.com> Date: Thu Oct 31 23:05:24 2013 +0100 KVM: x86: fix emulation of "movzbl %bpl, %eax" (by whom else :)), and the rest of the commit message taught me about the "emulate_invalid_guest_state" module parameter (of module kvm-intel). When setting this modparam to 1, the guest progresses a bit farther, but then the following appears in the dmesg: emulation failed (emulation failure) rip 225 ff 2e 4e 00 Which seems to refer to 3e6: ff 2e ljmp *(%esi) 3e8: 4e dec %esi (also visible in the earlier disassembly). Based on the upstream kernel, it looks like the RHEL-6 kernel misses "Group5 / jmp_far" emulation: <http://thread.gmane.org/gmane.comp.emulators.kvm.devel/47489> Patch 1: commit e35b7b9c9e7d8768ee34e5904fed4cb0f2c2cb5d Author: Gleb Natapov <g...@redhat.com> Date: Thu Feb 25 16:36:42 2010 +0200 KVM: x86 emulator: Add decoding of 16bit second in memory argument Add decoding of Ep type of argument used by callf/jmpf. Signed-off-by: Gleb Natapov <g...@redhat.com> Signed-off-by: Avi Kivity <a...@redhat.com> Patch 2: commit ea79849d4c8461034b75acb19c8041b6fddee2a5 Author: Gleb Natapov <g...@redhat.com> Date: Thu Feb 25 16:36:43 2010 +0200 KVM: x86 emulator: Implement jmp far opcode ff/5 Implement jmp far opcode ff/5. It is used by multiboot loader. Signed-off-by: Gleb Natapov <g...@redhat.com> Signed-off-by: Avi Kivity <a...@redhat.com> These were first released in v2.6.35, the RHEL-6 kernel lacks them, but they are clean cherry-picks. They solve the problem for me. I filed https://bugzilla.redhat.com/show_bug.cgi?id=1059496 Thanks! Laszlo