Re: Protected mode transitions and big real mode... still an issue

[Laurent Vivier <Laurent.Vivier@bull.net>]

Le mardi 29 avril 2008 à 11:41 -0500, Anthony Liguori a écrit :
> 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.
> >   
> 
> You still aren't emulating the instructions correctly I think.  Running 
> your patch, I see:
> 
> [  979.755349] Failed vm entry (exit reason 0x21) invalid guest state
> [  979.755354] emulation at (46e4b) rip 6e0b: ea 10 6e 18
> [  979.755358] successfully emulated instruction
> [  979.756105] Failed vm entry (exit reason 0x21) invalid guest state
> [  979.756109] emulation at (46e50) rip 6e10: 66 b8 20 00
> [  979.756111] successfully emulated instruction
> [  979.756749] Failed vm entry (exit reason 0x21) invalid guest state
> [  979.756752] emulation at (46e54) rip 6e14: 8e d8 8c d0
> [  979.756755] successfully emulated instruction
> [  979.757427] Failed vm entry (exit reason 0x21) invalid guest state
> [  979.757430] emulation at (46e56) rip 6e16: 8c d0 81 e4
> [  979.757433] successfully emulated instruction
> [  979.758074] Failed vm entry (exit reason 0x21) invalid guest state
> [  979.758077] emulation at (46e58) rip 6e18: 81 e4 ff ff
> 
> 
> The corresponding gfxboot code is:
> 
>  16301 00006E0B EA[106E]1800                    jmp 
> pm_seg.prog_c32:switch_to_pm_20
>  16302                                  switch_to_pm_20:
>  16303                                 
>  16304                                          bits 32
>  16305                                 
>  16306 00006E10 66B82000                        mov ax,pm_seg.prog_d16
>  16307 00006E14 8ED8                            mov ds,ax
>  16308                                 
>  16309 00006E16 8CD0                            mov eax,ss
>  16310 00006E18 81E4FFFF0000                    and esp,0ffffh
>  
> 
> The VT state should be correct after executing instruction an RIP 6E16 
> (mov eax, ss).  The next instruction should not cause a vmentry 

Are you sure ? It is intel notation (opcode dst,src) , so it updates
eax, not ss. Guillaumes gives us (with gdb notation, opcode src,dst):

  0x0000000000046e53:  ljmp   $0x18,$0x6e18

  0x0000000000046e58:  mov    $0x20,%ax

%EAX = 0x20

  0x0000000000046e5c:  mov    %eax,%ds

%DS = 0x20

  0x0000000000046e5e:  mov    %ss,%eax

%EAX = %SS = 0x53E1 (in this particular case)

For me the issue is with instructions with "dst.byte = 0".
for instance:

0x0000000000046e66:  shl    $0x4,%eax

[82768.003174] emulation at (46e66) rip 6e26: c1 e0 04 01
[82768.035153]     writeback: dst.byte 0
[82768.055174]     writeback: dst.ptr  0x0000000000000000
[82768.087177]     writeback: dst.val  0x53e1
[82768.111178]     writeback: src.ptr  0x0000000000006e28
[82768.143157]     writeback: src.val  0x4

So my questions are:

Why dst.val is not 0x53e10 ?
Why dst.byte is 0 ?

> failure.  The fact that it is for you indicates that you're not updating 
> guest state correctly.
> 
> My guess would be that load_segment_descriptor is not updating the 
> values within the VMCS.
> 
> Regards,
> 
> Anthony Liguori

Regards
Laurent
-- 
------------- Laurent.Vivier@bull.net ---------------
"The best way to predict the future is to invent it."
- Alan Kay


-------------------------------------------------------------------------
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