public inbox for kvm@vger.kernel.org
 help / color / mirror / Atom feed
From: Laurent Vivier <Laurent.Vivier@bull.net>
To: Anthony Liguori <anthony@codemonkey.ws>
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 19:22:13 +0200	[thread overview]
Message-ID: <1209489733.4248.65.camel@frecb07144> (raw)
In-Reply-To: <1209488968.4248.59.camel@frecb07144>


Le mardi 29 avril 2008 à 19:09 +0200, Laurent Vivier a écrit :
> 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 ?

I can answer myself to this one:

	emulate_2op_SrcB("sal", c->src, c->dst, ctxt->eflags);

does nothing if dst.byte == 0

So next question is the good question...

> 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

  reply	other threads:[~2008-04-29 17:22 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 [this message]
2008-04-29 23:20       ` Avi Kivity
2008-04-29 18:17     ` Anthony Liguori
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=1209489733.4248.65.camel@frecb07144 \
    --to=laurent.vivier@bull.net \
    --cc=alex@csgraf.de \
    --cc=anthony@codemonkey.ws \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox