On 08/10/2010 10:01 PM, Mohammed Gamal wrote:
On Wed, Aug 11, 2010 at 4:19 AM, Mohammed Gamal<m.gamal005@xxxxxxxxx> wrote:
On Wed, Aug 11, 2010 at 2:02 AM, Avi Kivity<avi@xxxxxxxxxx> wrote:
On 08/10/2010 01:06 PM, Mohammed Gamal wrote:
On 8/10/10, Avi Kivity<avi@xxxxxxxxxx> 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.
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
