VMX: Reinject real mode exception
PATCH 2/2 VMX: Reinject real mode exception
As we execute real mode guests in VM86 mode, exception have to be reinjected appropriately when the guest triggered them. For this purpose the patch adopts the real-mode injection pattern used in vmx_inject_irq to vmx_queue_exception, additionally taking care that the IP is set correctly for #BP exceptions. Furthermore it extends handle_rmode_exception to reinject all those exceptions that can be raised in real mode.
This fixes the execution of himem.exe from FreeDOS and also makes its debug.com work properly.
Note that guest debugging in real mode is broken now. This has to be fixed by the scheduled debugging infrastructure rework (will be done once base patches for QEMU have been accepted).
--- arch/x86/kvm/vmx.c | 40 ++++++++++++++++++++++++++++++++++++++-- include/asm-x86/kvm_host.h | 2 ++ 2 files changed, 40 insertions(+), 2 deletions(-)
arch/x86/kvm/vmx.c +38 -2
@@ -735,12 +735,30 @@ static void skip_emulated_instruction(ststatic void vmx_queue_exception (struct kvm_vcpu *vcpu,unsigned nr,bool has_error_code,u32 error_code) { +struct vcpu_vmx *vmx =to_vmx (vcpu); + +if (has_error_code) +vmcs_write32 (VM_ENTRY_EXCEPTION_ERROR_CODE , error_code); + +if (vcpu->arch.rmode.active) { + vmx->rmode.irq.pending = true; + vmx->rmode.irq.vector = nr; + vmx->rmode.irq.rip =kvm_rip_read (vcpu); +if (nr ==BP_VECTOR ) + vmx->rmode.irq.rip++; +vmcs_write32 (VM_ENTRY_INTR_INFO_FIELD , + nr |INTR_TYPE_SOFT_INTR + | (has_error_code ?INTR_INFO_DELIVER_CODE_MASK :0 ) + |INTR_INFO_VALID_MASK ); +vmcs_write32 (VM_ENTRY_INSTRUCTION_LEN ,1 ); +kvm_rip_write (vcpu, vmx->rmode.irq.rip -1 ); +return ; + } +vmcs_write32 (VM_ENTRY_INTR_INFO_FIELD , nr |INTR_TYPE_EXCEPTION | (has_error_code ?INTR_INFO_DELIVER_CODE_MASK :0 ) |INTR_INFO_VALID_MASK ); -if (has_error_code) -vmcs_write32 (VM_ENTRY_EXCEPTION_ERROR_CODE , error_code); }static bool vmx_exception_injected (struct kvm_vcpu *vcpu)
@@ -2234,6 +2252,24 @@ static int handle_rmode_exception(structif (((vec ==GP_VECTOR ) || (vec ==SS_VECTOR )) && err_code ==0 )if (emulate_instruction (vcpu,NULL ,0 ,0 ,0 ) ==EMULATE_DONE )return 1 ; +/* +* Forward all other exceptions that are valid in real mode. +* FIXME: Breaks guest debugging in real mode, need to be fixed with +* the required debugging infrastructure rework. +*/ +switch (vec) { +case DF_VECTOR : +case SS_VECTOR : +case GP_VECTOR : +kvm_queue_exception_e (vcpu, vec, err_code); +return 1 ; +break ; + case DE_VECTOR ... NM_VECTOR: +case MF_VECTOR : +case MC_VECTOR : +kvm_queue_exception (vcpu, vec); +return 1 ; + }return 0 ; }
include/asm-x86/kvm_host.h +2 -0
@@ -57,6 +57,7 @@#define DE_VECTOR 0#define DB_VECTOR 1 +#define BP_VECTOR 3#define UD_VECTOR 6#define NM_VECTOR 7#define DF_VECTOR 8
@@ -65,6 +66,7 @@#define SS_VECTOR 12#define GP_VECTOR 13#define PF_VECTOR 14 +#define MF_VECTOR 16#define MC_VECTOR 18#define SELECTOR_TI_MASK (1 << 2)
Quoted 40 lines · Jan Kiszka
As we execute real mode guests in VM86 mode, exception have to be reinjected appropriately when the guest triggered them. For this purpose the patch adopts the real-mode injection pattern used in
vmx_inject_irqtovmx_queue_exception, additionally taking care that the IP is set correctly for #BP exceptions. Furthermore it extendshandle_rmode_exceptionto reinject all those exceptions that can be raised in real mode.This fixes the execution of himem.exe from FreeDOS and also makes its debug.com work properly.
Note that guest debugging in real mode is broken now. This has to be fixed by the scheduled debugging infrastructure rework (will be done once base patches for QEMU have been accepted).
Signed-off-by Jan Kiszka <[email protected]>--- arch/x86/kvm/vmx.c | 40 ++++++++++++++++++++++++++++++++++++++-- include/asm-x86/kvm_host.h | 2 ++ 2 files changed, 40 insertions(+), 2 deletions(-)Index:
b/arch/x86/kvm/vmx.c
===================================================================arch/x86/kvm/vmx.c +11
-0@@ -735,12 +735,30 @@ static void skip_emulated_instruction(ststatic void vmx_queue_exception (struct kvm_vcpu *vcpu,unsigned nr,bool has_error_code,u32 error_code) { +struct vcpu_vmx *vmx =to_vmx (vcpu); + +if (has_error_code) +vmcs_write32 (VM_ENTRY_EXCEPTION_ERROR_CODE , error_code); + +if (vcpu->arch.rmode.active) { + vmx->rmode.irq.pending = true; + vmx->rmode.irq.vector = nr; + vmx->rmode.irq.rip =kvm_rip_read (vcpu); +if (nr ==BP_VECTOR ) + vmx->rmode.irq.rip++;
arch/x86/kvm/vmx.c static void skip_emulated_instruction(st · line 758
Quoted 10 lines
arch/x86/kvm/vmx.c +9
-0+vmcs_write32 (VM_ENTRY_INTR_INFO_FIELD , + nr |INTR_TYPE_SOFT_INTR + | (has_error_code ?INTR_INFO_DELIVER_CODE_MASK :0 ) + |INTR_INFO_VALID_MASK ); +vmcs_write32 (VM_ENTRY_INSTRUCTION_LEN ,1 ); +kvm_rip_write (vcpu, vmx->rmode.irq.rip -1 ); +return ; + } +
It's a little sad that this duplicates vmx_inject_irq. But we can live with it.
Quoted 14 lines
arch/x86/kvm/vmx.c +0
-2vmcs_write32 (VM_ENTRY_INTR_INFO_FIELD , nr |INTR_TYPE_EXCEPTION | (has_error_code ?INTR_INFO_DELIVER_CODE_MASK :0 ) |INTR_INFO_VALID_MASK ); -if (has_error_code) -vmcs_write32 (VM_ENTRY_EXCEPTION_ERROR_CODE , error_code); }static bool
vmx_exception_injected(struct kvm_vcpu *vcpu)arch/x86/kvm/vmx.c +1
-0@@ -2234,6 +2252,24 @@ static int handle_rmode_exception(structif (((vec ==GP_VECTOR ) || (vec ==SS_VECTOR )) && err_code ==0 )if (emulate_instruction (vcpu,NULL ,0 ,0 ,0 ) ==EMULATE_DONE )return 1 ; +/*
arch/x86/kvm/vmx.c static int handle_rmode_exception(struct · line 2265
Quoted 10 lines
arch/x86/kvm/vmx.c +9
-0+* Forward all other exceptions that are valid in real mode. +* FIXME: Breaks guest debugging in real mode, need to be fixed with +* the required debugging infrastructure rework. +*/ +switch (vec) { +case DF_VECTOR : +case SS_VECTOR : +case GP_VECTOR : +kvm_queue_exception_e (vcpu, vec, err_code);
These don't actually queue an error code in real mode. Compare the 'Real-Address Mode Exceptions' section with the 'Protected Mode Exceptions' section for most instructions in the Intel manual.
arch/x86/kvm/vmx.c static int handle_rmode_exception(struct · line 2275
Quoted 4 lines
arch/x86/kvm/vmx.c +3
-0+return 1 ; +break ; + case DE_VECTOR ... NM_VECTOR:
Please spell out explicitly. Also, NM_VECTOR is used by the host for managing the guest fpu, so some NM_VECTORs should not be reflected. I suggest simply dropping NM_VECTOR until this is worked out, as many real-mode operating systems don't implement lazy fpu switching.
Also, NMI shouldn't be handled here.
arch/x86/kvm/vmx.c static int handle_rmode_exception(struct · line 2275
Quoted 3 lines
arch/x86/kvm/vmx.c +2
-0+case MF_VECTOR : +case MC_VECTOR :
I don't think #MC should be handled here. Machine checks have to be handled by the host.
Quoted 6 lines
arch/x86/kvm/vmx.c +3
-0+kvm_queue_exception (vcpu, vec); +return 1 ; + }return 0;
}
Signature · 1 line
error compiling committee.c: too many arguments to function
Quoted 1 line · Avi Kivity
Jan Kiszka wrote:
...
Quoted 11 lines
Quoted 11 lines
(quoted diff) +7
-0@@ -2234,6 +2252,24 @@ static int handle_rmode_exception(struct if (((vec == GP_VECTOR) || (vec == SS_VECTOR)) && err_code == 0) if (emulate_instruction(vcpu, NULL, 0, 0, 0) == EMULATE_DONE) return 1; + /* + * Forward all other exceptions that are valid in real mode. + * FIXME: Breaks guest debugging in real mode, need to be fixed with + * the required debugging infrastructure rework. + */ + switch (vec) { + case DF_VECTOR:
Quoted 8 lines
Review static int handle_rmode_exception(struct · line 2265
Quoted 4 lines
(quoted diff) +3
-0+ case SS_VECTOR: + case GP_VECTOR: + kvm_queue_exception_e(vcpu, vec, err_code);These don't actually queue an error code in real mode. Compare the 'Real-Address Mode Exceptions' section with the 'Protected Mode Exceptions' section for most instructions in the Intel manual.
Unless you can points out a better reference, I prefer following chapter 5.15 of the System Programming Guide on this. And that one doesn't make a difference when it says, e.g., "Exception Error Code: Zero. The processor always pushes an error code of 0 onto the stack of the doublefault handler."
Quoted 10 lines
Review static int handle_rmode_exception(struct · line 2269
Quoted 5 lines
(quoted diff) +3
-0+ return 1; + break; + case DE_VECTOR ... NM_VECTOR:Please spell out explicitly. Also,
NM_VECTORis used by the host for managing the guest fpu, so someNM_VECTORsshould not be reflected. I suggest simply droppingNM_VECTORuntil this is worked out, as many real-mode operating systems don't implement lazy fpu switching.
OK.
Quoted 2 lines
Also, NMI shouldn't be handled here.
Yep.
Quoted 7 lines
Review static int handle_rmode_exception(struct · line 2272
Quoted 4 lines
(quoted diff) +2
-0+ case MF_VECTOR: + case MC_VECTOR:I don't think #MC should be handled here. Machine checks have to be handled by the host.
OK, update below.
-------------
As we execute real mode guests in VM86 mode, exception have to be reinjected appropriately when the guest triggered them. For this purpose the patch adopts the real-mode injection pattern used in vmx_inject_irq to vmx_queue_exception, additionally taking care that the IP is set correctly for #BP exceptions. Furthermore it extends handle_rmode_exception to reinject all those exceptions that can be raised in real mode.
This fixes the execution of himem.exe from FreeDOS and also makes its debug.com work properly.
Note that guest debugging in real mode is broken now. This has to be fixed by the scheduled debugging infrastructure rework (will be done once base patches for QEMU have been accepted).
--- arch/x86/kvm/vmx.c | 43 +++++++++++++++++++++++++++++++++++++++++-- include/asm-x86/kvm_host.h | 4 ++++ 2 files changed, 45 insertions(+), 2 deletions(-)
arch/x86/kvm/vmx.c +41 -2
@@ -735,12 +735,30 @@ static void skip_emulated_instruction(ststatic void vmx_queue_exception (struct kvm_vcpu *vcpu,unsigned nr,bool has_error_code,u32 error_code) { +struct vcpu_vmx *vmx =to_vmx (vcpu); + +if (has_error_code) +vmcs_write32 (VM_ENTRY_EXCEPTION_ERROR_CODE , error_code); + +if (vcpu->arch.rmode.active) { + vmx->rmode.irq.pending = true; + vmx->rmode.irq.vector = nr; + vmx->rmode.irq.rip =kvm_rip_read (vcpu); +if (nr ==BP_VECTOR ) + vmx->rmode.irq.rip++; +vmcs_write32 (VM_ENTRY_INTR_INFO_FIELD , + nr |INTR_TYPE_SOFT_INTR + | (has_error_code ?INTR_INFO_DELIVER_CODE_MASK :0 ) + |INTR_INFO_VALID_MASK ); +vmcs_write32 (VM_ENTRY_INSTRUCTION_LEN ,1 ); +kvm_rip_write (vcpu, vmx->rmode.irq.rip -1 ); +return ; + } +vmcs_write32 (VM_ENTRY_INTR_INFO_FIELD , nr |INTR_TYPE_EXCEPTION | (has_error_code ?INTR_INFO_DELIVER_CODE_MASK :0 ) |INTR_INFO_VALID_MASK ); -if (has_error_code) -vmcs_write32 (VM_ENTRY_EXCEPTION_ERROR_CODE , error_code); }static bool vmx_exception_injected (struct kvm_vcpu *vcpu)
@@ -2234,6 +2252,27 @@ static int handle_rmode_exception(structif (((vec ==GP_VECTOR ) || (vec ==SS_VECTOR )) && err_code ==0 )if (emulate_instruction (vcpu,NULL ,0 ,0 ,0 ) ==EMULATE_DONE )return 1 ; +/* +* Forward all other exceptions that are valid in real mode. +* FIXME: Breaks guest debugging in real mode, need to be fixed with +* the required debugging infrastructure rework. +*/ +switch (vec) { +case DF_VECTOR : +case SS_VECTOR : +case GP_VECTOR : +kvm_queue_exception_e (vcpu, vec, err_code); +return 1 ; +case DE_VECTOR : +case DB_VECTOR : +case BP_VECTOR : +case OF_VECTOR : +case BR_VECTOR : +case UD_VECTOR : +case MF_VECTOR : +kvm_queue_exception (vcpu, vec); +return 1 ; + }return 0 ; }
include/asm-x86/kvm_host.h +4 -0
@@ -57,6 +57,9 @@#define DE_VECTOR 0#define DB_VECTOR 1 +#define BP_VECTOR 3 +#define OF_VECTOR 4 +#define BR_VECTOR 5#define UD_VECTOR 6#define NM_VECTOR 7#define DF_VECTOR 8
@@ -65,6 +68,7 @@#define SS_VECTOR 12#define GP_VECTOR 13#define PF_VECTOR 14 +#define MF_VECTOR 16#define MC_VECTOR 18#define SELECTOR_TI_MASK (1 << 2)
Quoted 27 lines · Jan Kiszka
Quoted 2 lines · Avi Kivity
Jan Kiszka wrote:
...
Quoted 11 lines
Quoted 11 lines
arch/x86/kvm/vmx.c +7
-0@@ -2234,6 +2252,24 @@ static int handle_rmode_exception(structif (((vec ==GP_VECTOR ) || (vec ==SS_VECTOR )) && err_code ==0 )if (emulate_instruction (vcpu,NULL ,0 ,0 ,0 ) ==EMULATE_DONE )return 1 ; +/* +* Forward all other exceptions that are valid in real mode. +* FIXME: Breaks guest debugging in real mode, need to be fixed with +* the required debugging infrastructure rework. +*/ +switch (vec) { +case DF_VECTOR :Quoted 9 lines
arch/x86/kvm/vmx.c static int handle_rmode_exception(struct
Quoted 5 lines
arch/x86/kvm/vmx.c +3
-0+case SS_VECTOR : +case GP_VECTOR : +kvm_queue_exception_e (vcpu, vec, err_code);These don't actually queue an error code in real mode. Compare the 'Real-Address Mode Exceptions' section with the 'Protected Mode Exceptions' section for most instructions in the Intel manual.
Quoted 7 lines
Unless you can points out a better reference, I prefer following chapter 5.15 of the System Programming Guide on this. And that one doesn't make a difference when it says, e.g., "Exception Error Code: Zero. The processor always pushes an error code of 0 onto the stack of the doublefault handler."
Well, xen and bochs do not push an error code for real mode #GP. I tried running the attached test program but it doesn't work on real hardware (it does work on bochs).
Signature · 1 line
error compiling committee.c: too many arguments to function
all: real-mode-exception.iso
real-mode-exception.o: real-mode-exception.S
as -o $@ $^
real-mode-exception.boot: real-mode-exception.o real-mode-exception.ld
ld -T real-mode-exception.ld -o $@ real-mode-exception.o dd < /dev/zero >> $@ count=2879
real-mode-exception.iso: real-mode-exception.boot
mkisofs -o $@ -b $^ $^
OUTPUT_FORMAT(binary)
SECTIONS
{
. = 0x7c00;
stext = .;
.text : { *(.init) *(.text) }
. = ALIGN(4K);
.data : { *(.data) }
. = ALIGN(16);
.bss : { *(.bss) }
. = ALIGN(4K);
edata = .;
}.code16
start:
ljmp $0, $restart
restart:
mov $0x39, %al mov $10, %ah mov $0, %bx mov $20, %cx int $0x10 mov $0, %ax mov %ax, %ds movw $gp_handler, 13*4 mov %cs, 13*4+2 mov %sp, %dx addr32 testb $0, 0x100000
loop: jmp loop
gp_handler:
sub %sp, %dx shr $1, %dx add $48, %dl mov %dl, %al mov $10, %ah mov $0, %bx mov $10, %cx int $0x10 jmp loop
. = 0x1fe
.byte 0x55, 0xaa
Quoted 5 lines · Avi Kivity
Well, xen and bochs do not push an error code for real mode #GP. I tried running the attached test program but it doesn't work on real hardware (it does work on bochs).
Jun, perhaps you can clarify? do #GP exceptions in real-mode push an error code?
Signature · 1 line
error compiling committee.c: too many arguments to function
Quoted 9 lines · Avi Kivity
Quoted 5 lines · Avi Kivity
Well, xen and bochs do not push an error code for real mode #GP. I tried running the attached test program but it doesn't work on real hardware (it does work on bochs).
Jun, perhaps you can clarify? do #GP exceptions in real-mode push an error code?
Avi,
Exceptions in real-mode do not push an error code in the stack. In vm86 mode #GP exceptions push an error code, triggering a protected-mode handler in the monitor, as you know. Is it possible that the guest is actually using vm86 mode?
Quoted 4 lines
--
error compilingcommittee.c: too many arguments to function
.
Jun Nakajima | Intel Open Source Technology Center
Quoted 13 lines · Jun
Quoted 9 lines · Avi Kivity
Quoted 5 lines · Avi Kivity
Well, xen and bochs do not push an error code for real mode #GP. I tried running the attached test program but it doesn't work on real hardware (it does work on bochs).
Jun, perhaps you can clarify? do #GP exceptions in real-mode push an error code?
Avi,
Quoted 9 lines
Exceptions in real-mode do not push an error code in the stack. In vm86 mode #GP exceptions push an error code, triggering a protected-mode handler in the monitor, as you know. Is it possible that the guest is actually using vm86 mode?
Quoted 4 lines
--
error compilingcommittee.c: too many arguments to function.Jun Nakajima | Intel Open Source Technology Center
Yes it is. FreeDOS runs in real mode, and KVM uses vm86 mode instead of fully emulating real mode. If you check the register dump caused by the exception you'll find the VM bit set in the guest's eflags.
Quoted 9 lines · Jun
Quoted 7 lines · Avi Kivity
Quoted 5 lines · Avi Kivity
Well, xen and bochs do not push an error code for real mode #GP. I tried running the attached test program but it doesn't work on real hardware (it does work on bochs).
Quoted 7 lines
Quoted 3 lines
Jun, perhaps you can clarify? do #GP exceptions in real-mode push an error code?
Avi,
Exceptions in real-mode do not push an error code in the stack.
Thanks. You might consider updating the documentation, for example #DF states that an error code of 0 is always pushed.
Quoted 2 lines
In vm86 mode #GP exceptions push an error code, triggering a protected-mode handler in the monitor, as you know. Is it possible that the guest is actually using vm86 mode?
No, it's a real mode guest. It's emulated using vm86, of course, but it thinks it's in real mode. The question was, when we inject a #GP, #SS, or #DF exception, should we also inject an error code, and according to your clarification, the answer is no.
Signature · 1 line
error compiling committee.c: too many arguments to function
Quoted 26 lines · Avi Kivity
Quoted 9 lines · Jun
Quoted 7 lines · Avi Kivity
Quoted 5 lines · Avi Kivity
Well, xen and bochs do not push an error code for real mode #GP. I tried running the attached test program but it doesn't work on real hardware (it does work on bochs).
Quoted 7 lines
Quoted 3 lines
Jun, perhaps you can clarify? do #GP exceptions in real-mode push an error code?
Avi,
Exceptions in real-mode do not push an error code in the stack.
Thanks. You might consider updating the documentation, for example #DF states that an error code of 0 is always pushed.
Quoted 4 lines
In vm86 mode #GP exceptions push an error code, triggering a protected-mode handler in the monitor, as you know. Is it possible that the guest is actually using vm86 mode?
Quoted 4 lines
No, it's a real mode guest. It's emulated using vm86, of course, but it thinks it's in real mode. The question was, when we inject a #GP, #SS, or #DF exception, should we also inject an error code, and according to your clarification, the answer is no.
Meanwhile I found a clearer statement in the spec as well in chapter 15.1.4: "Exceptions do not return error codes in real-address mode." So here is the update:
-----------
As we execute real mode guests in VM86 mode, exception have to be reinjected appropriately when the guest triggered them. For this purpose the patch adopts the real-mode injection pattern used in vmx_inject_irq to vmx_queue_exception, additionally taking care that the IP is set correctly for #BP exceptions. Furthermore it extends handle_rmode_exception to reinject all those exceptions that can be raised in real mode.
This fixes the execution of himem.exe from FreeDOS and also makes its debug.com work properly.
Note that guest debugging in real mode is broken now. This has to be fixed by the scheduled debugging infrastructure rework (will be done once base patches for QEMU have been accepted).
--- arch/x86/kvm/vmx.c | 41 +++++++++++++++++++++++++++++++++++++++-- include/asm-x86/kvm_host.h | 4 ++++ 2 files changed, 43 insertions(+), 2 deletions(-)
arch/x86/kvm/vmx.c +39 -2
@@ -735,12 +735,30 @@ static void skip_emulated_instruction(ststatic void vmx_queue_exception (struct kvm_vcpu *vcpu,unsigned nr,bool has_error_code,u32 error_code) { +struct vcpu_vmx *vmx =to_vmx (vcpu); + +if (has_error_code) +vmcs_write32 (VM_ENTRY_EXCEPTION_ERROR_CODE , error_code); + +if (vcpu->arch.rmode.active) { + vmx->rmode.irq.pending = true; + vmx->rmode.irq.vector = nr; + vmx->rmode.irq.rip =kvm_rip_read (vcpu); +if (nr ==BP_VECTOR ) + vmx->rmode.irq.rip++; +vmcs_write32 (VM_ENTRY_INTR_INFO_FIELD , + nr |INTR_TYPE_SOFT_INTR + | (has_error_code ?INTR_INFO_DELIVER_CODE_MASK :0 ) + |INTR_INFO_VALID_MASK ); +vmcs_write32 (VM_ENTRY_INSTRUCTION_LEN ,1 ); +kvm_rip_write (vcpu, vmx->rmode.irq.rip -1 ); +return ; + } +vmcs_write32 (VM_ENTRY_INTR_INFO_FIELD , nr |INTR_TYPE_EXCEPTION | (has_error_code ?INTR_INFO_DELIVER_CODE_MASK :0 ) |INTR_INFO_VALID_MASK ); -if (has_error_code) -vmcs_write32 (VM_ENTRY_EXCEPTION_ERROR_CODE , error_code); }static bool vmx_exception_injected (struct kvm_vcpu *vcpu)
@@ -2231,6 +2249,25 @@ static int handle_rmode_exception(structif (((vec ==GP_VECTOR ) || (vec ==SS_VECTOR )) && err_code ==0 )if (emulate_instruction (vcpu,NULL ,0 ,0 ,0 ) ==EMULATE_DONE )return 1 ; +/* +* Forward all other exceptions that are valid in real mode. +* FIXME: Breaks guest debugging in real mode, needs to be fixed with +* the required debugging infrastructure rework. +*/ +switch (vec) { +case DE_VECTOR : +case DB_VECTOR : +case BP_VECTOR : +case OF_VECTOR : +case BR_VECTOR : +case UD_VECTOR : +case DF_VECTOR : +case SS_VECTOR : +case GP_VECTOR : +case MF_VECTOR : +kvm_queue_exception (vcpu, vec); +return 1 ; + }return 0 ; }
include/asm-x86/kvm_host.h +4 -0
@@ -57,6 +57,9 @@#define DE_VECTOR 0#define DB_VECTOR 1 +#define BP_VECTOR 3 +#define OF_VECTOR 4 +#define BR_VECTOR 5#define UD_VECTOR 6#define NM_VECTOR 7#define DF_VECTOR 8
@@ -65,6 +68,7 @@#define SS_VECTOR 12#define GP_VECTOR 13#define PF_VECTOR 14 +#define MF_VECTOR 16#define MC_VECTOR 18#define SELECTOR_TI_MASK (1 << 2)
Avi Kivity
AppliedQuoted 8 lines · Jan Kiszka
As we execute real mode guests in VM86 mode, exception have to be reinjected appropriately when the guest triggered them. For this purpose the patch adopts the real-mode injection pattern used in
vmx_inject_irqtovmx_queue_exception, additionally taking care that the IP is set correctly for #BP exceptions. Furthermore it extendshandle_rmode_exceptionto reinject all those exceptions that can be raised in real mode.
Quoted 8 lines
This fixes the execution of himem.exe from FreeDOS and also makes its debug.com work properly.
Note that guest debugging in real mode is broken now. This has to be fixed by the scheduled debugging infrastructure rework (will be done once base patches for QEMU have been accepted).
Applied, thanks.
Signature · 1 line
error compiling committee.c: too many arguments to function
Quoted 13 lines · Avi Kivity
Quoted 12 lines · Jun
Quoted 9 lines · Avi Kivity
Quoted 4 lines · Avi Kivity
Well, xen and bochs do not push an error code for real mode #GP. I tried running the attached test program but it doesn't work on real hardware (it does work on bochs).
Jun, perhaps you can clarify? do #GP exceptions in real-mode push an error code?
Quoted 7 lines
Quoted 3 lines
Avi,
Exceptions in real-mode do not push an error code in the stack.
Thanks. You might consider updating the documentation, for example #DF states that an error code of 0 is always pushed.
If you are looking at the description of Chapter 5, at the top it says "This chapter describes the interrupt and exception-handling mechanism when operating in protected mode on an Intel 64 or IA-32 processor. ... Chapter 15, "8086 Emulation," describes information specific to interrupt and exception mechanisms in real-address and virtual-8086 mode.".
.
Jun Nakajima | Intel Open Source Technology Center