Guillaume Thouvenin wrote: > Hello, > > This patch should solve the problem observed during protected mode > transitions that appears for example during the installation of > openSuse-10.3. Unfortunately there is an issue that crashes > kvm-userspace. I'm not sure if it's a problem introduced by the > patch or if the patch is good and raises a new issue. > > Here is what I'm doing: > > 1) Remove the SS patching that modifies SS_SELECTOR in enter_pmode() > to see vmentry failure. > 2) Add the handler that catches the VMentry failure. It is called > handle_vmentry_failure() > 3) while CS.RPL != SS.RPL, emulate the instruction. > 4) Add the emulation of "ljmp", "mov r, imm", "mov sreg, r/m16" and > "mov r/m16, sreg" that have respectively opcode 0xea, 0xb8, 0x8e and > 0x8c. > > Normally, it should be sufficient to boot openSuse-10.3 because > instructions that need to be emulated are: > > 0x0000000000046e53: ljmp $0x18,$0x6e18 > 0x0000000000046e58: mov $0x20,%ax > 0x0000000000046e5c: mov %eax,%ds > 0x0000000000046e5e: mov %ss,%eax > 0x0000000000046e60: and $0xffff,%esp > 0x0000000000046e66: shl $0x4,%eax > 0x0000000000046e69: add %eax,%esp > 0x0000000000046e6b: mov $0x8,%ax > 0x0000000000046e6f: mov %eax,%ss > > At this point, cs.rpl is equal to ss.rpl. > > I added trace in handle_vmentry_failure() and also in writeback() to > see what functions are emulated and I observe: >
<snip trace> > > So everything seems ok but after the emulation of "mov %eax,%ss" > instruction, it seems that cs.rpl == ss.rpl but the guest is still in a > VT-unfriendly state because I have the following error in kvm-userspace: > > [EMAIL PROTECTED]/local/kvm-userspace.git/bin]$ ./qemu-system-x86_64 > -hda ~/disk_images/hd_50G.qcow2 > -cdrom /images_iso/openSUSE-10.3-GM-x86_64-mini.iso -boot d -s -m 1024 > > exception 13 (33) > rax 0000000000000673 rbx 0000000000800000 rcx 0000000000000000 > rdx 00000000000013ca rsi 0000000000055e1c rdi 0000000000055e1d > rsp 00000000fffa0080 rbp 000000000000200b r8 0000000000000000 > r9 0000000000000000 r10 0000000000000000 r11 0000000000000000 > r12 0000000000000000 r13 0000000000000000 r14 0000000000000000 > r15 0000000000000000 rip 000000000000b071 rflags 00033092 > cs 4004 (00040040/0000ffff p 1 dpl 3 db 0 s 1 type 3 l 0 g 0 avl 0) > ds 4004 (00040040/0000ffff p 1 dpl 3 db 0 s 1 type 3 l 0 g 0 avl 0) > es 00ff (00000ff0/0000ffff p 1 dpl 3 db 0 s 1 type 3 l 0 g 0 avl 0) > ss ff11 (000ff110/0000ffff p 1 dpl 3 db 0 s 1 type 3 l 0 g 0 avl 0) > fs 3002 (00030020/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 40920/47 idt 0/ffff cr0 10 cr2 0 cr3 0 cr4 0 cr8 0 efer 0 > code: 17 06 29 4b 01 18 eb 18 a8 25 aa 19 28 4c 01 28 4d 01 01 17 --> > 0f 17 0f 01 17 0f 17 12 01 17 2c 25 4b 19 21 00 02 17 1a 94 0a 76 67 61 > 3d 30 78 25 78 20 Aborted My memory of x86 protected mode is flaky so I apologise if this is wasted time. Are we looking at the runtime registers for the VM or the registers for the host? Isn't PE clear in CR0 (which I think is real mode and there should be no cpl or rpl). If this is in protected mode (or cpl/rpl are a carried over as a side effect of big real mode), are you sure cs.rpl == ss.rpl? I think I read cs.rpl == 0 and ss.rpl == 1. The opcode with the exception is pop %ss I believe (assuming 32 bit code). Is the value dumped for ss the value loaded by the pop or the value from before the pop? I think cpl is zero and I thought it was ok for code at some cpl to use selectors with rpls equal to its cpl or lower (higher rpl number). That made me wonder if the loaded ss is not the value shown but the value that would have been loaded by the pop. In which case I wonder if it would be a selector for an invalid descriptor. It's a shame we don't see the stack. Beyond that I risk confusion so I'll leave it there, I hope it helps. --- David Mair. ------------------------------------------------------------------------- This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone _______________________________________________ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
