Unhandled vm exit with old protected mode test

Hi,

running some oldish 286 protected mode demo in kvm, I came across this bug of kvm-52:

unhandled vm exit: 0x80000021 vcpu_id 0
rax 0000000060000010 rbx 0000000000000000 rcx 0000000000000000 rdx 0000000000000003 rsi 00000000ffff0400 rdi 000000000008042e rsp 00000000000001fa rbp 000000000000091e r8 0000000000000000 r9 0000000000000000 r10 0000000000000000 r11 0000000000000000 r12 0000000000000000 r13 0000000000000000 r14 0000000000000000 r15 0000000000000000 rip 000000000000015b rflags 00023002
cs 320e (000320e0/0000ffff p 1 dpl 3 db 0 s 1 type 3 l 0 g 0 avl 0)
ds 0000 (00100000/0000ffff p 1 dpl 3 db 0 s 1 type 3 l 0 g 0 avl 0)
es 31cb (00031cb0/0000ffff p 1 dpl 3 db 0 s 1 type 3 l 0 g 0 avl 0)
ss 3226 (00032260/0000ffff p 1 dpl 3 db 0 s 1 type 3 l 0 g 0 avl 0)
fs 0000 (00000000/0000ffff p 1 dpl 3 db 0 s 1 type 3 l 0 g 0 avl 0)
gs 0000 (00000000/0000ffff p 1 dpl 3 db 0 s 1 type 3 l 0 g 0 avl 0)
tr 0000 (fffbd000/00002088 p 1 dpl 0 db 0 s 0 type b l 0 g 0 avl 0) ldt 0000 (00000000/0000ffff p 1 dpl 0 db 0 s 0 type 2 l 0 g 0 avl 0) gdt 31cb0/27
idt 0/3ff
cr0 60000010 cr2 0 cr3 0 cr4 0 cr8 0 efer 0

The executed code is from [1] and was running over a FreeDOS image [2]. I found out that the crash happens on leaving the protected mode again. Anyone any ideas already? I can't dig into this on my own right now, but maybe it is simple to fix for people reading such dumps every day... ;)

Thanks,
Jan

[1] http://www.x86.org/articles/pmbasics/tspec_a1_doc.htm
[2] http://fabrice.bellard.free.fr/qemu/download.html

Siemens AG, Corporate Technology, CT SE 2
Corporate Competence Center Embedded Linux

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

ds.base must equal ds.sel<<4 when entering real-mode on Intel. See fix_rmode_seg() in vmx.c which clearly doesn't handle cases where ds.base >= 0x100000. You might try forcing bits 20+ of ds.base to zero in there. This may fix the problem or move it elsewhere.

error compiling committee.c: too many arguments to function


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

Yeah, this actually fixed my test case:

Ensure that segment.base == segment.selector << 4 when entering the real mode on Intel so that the CPU will not bark at us.

---
 kernel/vmx.c |    6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

Index: kvm-52/kernel/vmx.c
===================================================================
@@ -1159,12 +1159,14 @@ static gva_t rmode_tss_base(struct kvm *
 static void fix_rmode_seg(int seg, struct kvm_save_segment *save)
 {
 	struct kvm_vmx_segment_field *sf = &kvm_vmx_segment_fields[seg];
+	unsigned base;
 
 	save->selector = vmcs_read16(sf->selector);
-	save->base = vmcs_readl(sf->base);
+	save->base = base = vmcs_readl(sf->base);
 	save->limit = vmcs_read32(sf->limit);
 	save->ar = vmcs_read32(sf->ar_bytes);
-	vmcs_write16(sf->selector, vmcs_readl(sf->base) >> 4);
+	vmcs_write16(sf->selector, base >> 4);
+	vmcs_write32(sf->base, base & 0xfffff);
 	vmcs_write32(sf->limit, 0xffff);
 	vmcs_write32(sf->ar_bytes, 0xf3);
 }

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

Applied (after de-optimizing), thanks.

error compiling committee.c: too many arguments to function


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/