All of lore.kernel.org
 help / color / mirror / Atom feed
From: Anthony Liguori <anthony@codemonkey.ws>
To: Laurent Vivier <Laurent.Vivier@bull.net>
Cc: Rik van Riel <riel@surriel.com>,
	"kvm-devel@lists.sourceforge.net"
	<kvm-devel@lists.sourceforge.net>, Avi Kivity <avi@qumranet.com>,
	Guillaume Thouvenin <guillaume.thouvenin@ext.bull.net>,
	Alexander Graf <alex@csgraf.de>,
	Mohammed Gamal <m.gamal005@gmail.com>
Subject: Re: Protected mode transitions and big real mode... still an issue
Date: Tue, 29 Apr 2008 13:17:16 -0500	[thread overview]
Message-ID: <4817662C.2090705@codemonkey.ws> (raw)
In-Reply-To: <1209488968.4248.59.camel@frecb07144>

Laurent Vivier wrote:
> 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):
>   

You're right, it's a fair bit down the code before the ss move happens.

Regards,

Anthony Liguori

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


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

  parent reply	other threads:[~2008-04-29 18:17 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-04-29 13:02 Protected mode transitions and big real mode... still an issue Guillaume Thouvenin
2008-04-29 16:41 ` Anthony Liguori
2008-04-29 17:09   ` Laurent Vivier
2008-04-29 17:22     ` Laurent Vivier
2008-04-29 23:20       ` Avi Kivity
2008-04-29 18:17     ` Anthony Liguori [this message]
2008-04-29 16:56 ` David Mair
2008-04-29 18:16 ` Anthony Liguori
2008-05-01 19:13 ` Marcelo Tosatti
2008-05-03  8:26   ` Balaji Rao
2008-05-05 12:40     ` Guillaume Thouvenin
2008-05-05 12:44       ` Balaji Rao
2008-05-05 12:57       ` Anthony Liguori
2008-05-05 13:29         ` Mohammed Gamal
2008-05-06 13:38           ` Guillaume Thouvenin
2008-05-06 14:30             ` Anthony Liguori
2008-05-06 17:05               ` Mohammed Gamal
2008-05-14  7:29                 ` Guillaume Thouvenin
2008-05-14 21:29                   ` Marcelo Tosatti
2008-05-15  7:33                     ` Avi Kivity
2008-05-15  7:49                       ` Guillaume Thouvenin
2008-05-15 18:07                   ` Mohammed Gamal
2008-05-07  5:57               ` Guillaume Thouvenin
2008-05-05  6:27   ` Guillaume Thouvenin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4817662C.2090705@codemonkey.ws \
    --to=anthony@codemonkey.ws \
    --cc=Laurent.Vivier@bull.net \
    --cc=alex@csgraf.de \
    --cc=avi@qumranet.com \
    --cc=guillaume.thouvenin@ext.bull.net \
    --cc=kvm-devel@lists.sourceforge.net \
    --cc=m.gamal005@gmail.com \
    --cc=riel@surriel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.