Re: [Qemu-devel] pxe boot problems

[Laszlo Ersek <lersek@redhat.com>]

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

Patch 2:

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