On Mon, Jan 30, 2012 at 12:45:15PM +0200, Avi Kivity wrote:
> On 01/30/2012 12:35 PM, Kevin Wolf wrote:
> > Am 30.01.2012 09:55, schrieb Gleb Natapov:
> > > On Mon, Jan 30, 2012 at 09:48:33AM +0100, Kevin Wolf wrote:
> > >> Am 27.01.2012 20:52, schrieb Gleb Natapov:
> > >>> On Fri, Jan 27, 2012 at 08:23:33PM +0100, Kevin Wolf wrote:
> > >>>> I believe this should work with both VMX and SVM now. Gleb, Jörg, can
> > >>>> one of
> > >>>> you test this with SVM? I did some testing on my buggy processor and
> > >>>> it looks
> > >>>> as good as it gets, but it would be better if you could confirm.
> > >>>>
> > >>> You forgot to set cpl to 3 in vmcb in svm_set_rflags() when vm86 is
> > >>> enabled, no?
> > >>
> > >> SVM updates the CPL when the segment selector for CS is loaded. From a
> > >> svm.c POV, segment selectors are updated immediately after set_rflags,
> > >> so it wouldn't really make a difference to do it twice.
> > >>
> > > It is too subtle to rely on that. The fact is that checking cpl after
> > > set_rflags provides incorrect value. This better be fixed.
> >
> > Depends on what value you consider to be correct between reloading
> > eflags and reloading cs. I think it's logical and more consistent to say
> > that CPL only changes when cs is reloaded, but you could argue that it's
> > effective with the reload of rflags. It doesn't make a difference to
> > guests, so we can decide to choose whatever we like.
>
> It's best to make it independent (like svm, and force vmx to emulate
> this behaviour). Real mode forces cpl to 0, vm86 forces cpl to 3,
> protected mode (and I think long mode) uses cs.rpl.
This is what vmx does, not svm. svm checks vmcb->cpl that can be
outdated during emulation.
> Making it depend on
> the mode causes subtle issues during the mode switch - if you switch
> from real mode to protected mode while cs & 3 != 0 you end up with the
> wrong cpl until the jmp instruction is executed.
>
> >
> > Depending on what we decide on (Gleb and I disagree on this, so more
> > input would be helpful), either VMX or SVM need a cleanup. I think it
> > can be done independent from and on top of this fix.
>
> Right. IMO we should follow svm and make vmx be more flexible.
>
> One way to do it is to have a new variable for vmx cpl, and reconcile
> all the places where cpl is stored (cs.rpl, ss.rpl, cr0.pe, rflags.vm)
> just before entry. If we can't reconcile it, we have to emulate.
>
>
>
> --
> error compiling committee.c: too many arguments to function
--
Gleb.
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
