Re: [RFC PATCH 0/3] Real mode interrupt injection

[Avi Kivity <avi@redhat.com>]

  On 08/10/2010 10:01 PM, Mohammed Gamal wrote:
> On Wed, Aug 11, 2010 at 4:19 AM, Mohammed Gamal<m.gamal005@gmail.com>  wrote:
>> On Wed, Aug 11, 2010 at 2:02 AM, Avi Kivity<avi@redhat.com>  wrote:
>>>   On 08/10/2010 01:06 PM, Mohammed Gamal wrote:
>>>> On 8/10/10, Avi Kivity<avi@redhat.com>    wrote:
>>>>>    On 08/08/2010 03:24 PM, Mohammed Gamal wrote:
>>>>>> This patch introduces real mode interrupt injection for VMX.
>>>>>> It currently invokes the x86 emulator to emulate interrupts
>>>>>> instead of manually setting VMX controls.
>>>>>>
>>>>>> Needless to say, this is not meant for merging in its current state.
>>>>>> The emulator still needs some more work to get this completely
>>>>>> operational.
>>>>> Well, what happens when you run with it?
>>>> The guest fails at two instances. First it sometimes encounters a
>>>> group 7 instruction (0x0f 0x00), which the emulator doesn't emulate.
>>>> Here is the relevant part of the trace:
>>>>
>>>> qemu-system-x86-4321  [001]   150.002191: kvm_entry: vcpu 0
>>>>   qemu-system-x86-4321  [001]   150.002196: kvm_exit: reason
>>>> IO_INSTRUCTION rip 0x3
>>>>   qemu-system-x86-4321  [001]   150.002197: kvm_pio: pio_read at 0x70
>>>> size 1 count 1
>>>>   qemu-system-x86-4321  [001]   150.002205: kvm_entry: vcpu 0
>>>>   qemu-system-x86-4321  [001]   150.002210: kvm_exit: reason
>>>> IO_INSTRUCTION rip 0x5
>>>>   qemu-system-x86-4321  [001]   150.002213: kvm_emulate_insn: f0000:5:
>>>> e4 71 (real)
>>>>   qemu-system-x86-4321  [001]   150.002215: kvm_pio: pio_write at 0x71
>>>> size 1 count 1
>>>>   qemu-system-x86-4321  [001]   150.002223: kvm_entry: vcpu 0
>>>>   qemu-system-x86-4321  [001]   150.002228: kvm_exit: reason
>>>> EXCEPTION_NMI rip 0x18
>>>>   qemu-system-x86-4321  [001]   150.002229: kvm_page_fault: address
>>>> ffff error_code f
>>>>   qemu-system-x86-4321  [001]   150.002270: kvm_entry: vcpu 0
>>>>   qemu-system-x86-4321  [001]   150.002276: kvm_exit: reason
>>>> EXCEPTION_NMI rip 0x1a
>>>>   qemu-system-x86-4321  [001]   150.002277: kvm_page_fault: address
>>>> d4dc error_code f
>>>>   qemu-system-x86-4321  [001]   150.002284: kvm_entry: vcpu 0
>>>>   qemu-system-x86-4321  [001]   150.002289: kvm_exit: reason
>>>> EXCEPTION_NMI rip 0x1d
>>>>   qemu-system-x86-4321  [001]   150.002292: kvm_emulate_insn: f0000:1d:
>>>> 0f 00 (real)
>>> Could be a real instruction - we don't emulate all of group 7, and they're
>>> useful.
>> In fact, we don't emulate group 7 at all.
>>

Right.  Well, turns out it isn't a real instruction:

    efffd:       e4 71                   in     $0x71,%al
    effff:       88 c2                   mov    %al,%dl
    f0001:       b0 b1                   mov    $0xb1,%al
    f0003:       e6 70                   out    %al,$0x70
    f0005:       e4 71                   in     $0x71,%al
    f0007:       0f b6 c0                movzbl %al,%eax
    f000a:       c1 e0 12                shl    $0x12,%eax
    f000d:       0f b6 d2                movzbl %dl,%edx
    f0010:       c1 e2 0a                shl    $0xa,%edx
    f0013:       09 d0                   or     %edx,%eax
    f0015:       05 00 00 10 00          add    $0x100000,%eax
    f001a:       a3 dc d4 0f 00          mov    %eax,0xfd4dc

This is 32-bit code, yet from the trace:

  qemu-system-x86-4321  [001]   150.002276: kvm_exit: reason EXCEPTION_NMI rip 0x1a
  qemu-system-x86-4321  [001]   150.002277: kvm_page_fault: address d4dc error_code f

The address is trimmed, so kvm thinks we're in real mode!  The '0f 00' 
is just leftover bytes from the instruction.

We'll need earlier traces to find how the mixup happened.


    f001f:       6a 01                   push   $0x1
    f0021:       31 d2                   xor    %edx,%edx
    f0023:       52                      push   %edx
    f0024:       50                      push   %eax
    f0025:       31 c0                   xor    %eax,%eax
    f0027:       31 d2                   xor    %edx,%edx


-- 
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.