From: Gleb Natapov <gleb@redhat.com>
To: Marcelo Tosatti <mtosatti@redhat.com>
Cc: Avi Kivity <avi.kivity@gmail.com>, kvm <kvm@vger.kernel.org>
Subject: Re: KVM: VMX: fix incorrect cached cpl value with real/v8086 modes
Date: Fri, 4 Jan 2013 13:16:38 +0200 [thread overview]
Message-ID: <20130104111638.GA6547@redhat.com> (raw)
In-Reply-To: <20130103131918.GA28678@amt.cnet>
On Thu, Jan 03, 2013 at 11:19:18AM -0200, Marcelo Tosatti wrote:
> On Thu, Jan 03, 2013 at 10:11:53AM +0200, Gleb Natapov wrote:
> > > FreeBSD 9.1 with -smp 2.
> > I cannot reproduce. I do see boot failure on the next branch with 9.[01]
> > 64 bit -smp 2 here, but it is caused but segment registers been all
> > incorrect on a secondary vcpu and this patch does not help. Applying
> > http://comments.gmane.org/gmane.comp.emulators.kvm.devel/102593 fixes
> > it.
> >
> > > >
> > > > > > The question is how does it happen that we enter real mode while cache
> > > > > > is set to 3. It should never be 3 during boot since boot process never
> > > > > > enters the userspace.
> > > > >
> > > > > Its transition _to_ real mode (from protected).
> > > > But in protected mode CPL should be 0 during boot.
> > >
> > > BTX (FreeBSD's bootloader) does:
> > >
> > > http://people.freebsd.org/~jhb/docs/loader.txt.
> > Crazy. Regardless, I think your patch is correct and the current code
> > that uses cpl cache during emulation is wrong and it remains wrong even
> > after your patch. What if last time cpl cache was updated was while vcpu
> > ran in cpl 3? Commit message says that it tries to fix the case when
> > CS.selector&3 != 0 during transition to protected mode, but this can be
> > fixed by setting cpl cache to 0 in vmx_set_cr0() instead of clearing it.
>
> Yes, i suppose so, can be done by a separatch patch, though.
>
Yes. I will send the patch.
> > Two things about the patch itself. Get rid of __vmx_get_cpl() and call
> > to vmx_read_guest_seg_selector() directly from vmx_get_cpl() and drop
> > __clear_bit(VCPU_EXREG_CPL) from vmx_set_rflags() and vmx_set_cr0()
> > since vmx->cpl no longer depends on rflags and cr0.
>
> You still want to invalidate vmx->cpl cache on cr0 writes:
> think protected -> real -> protected transition.
If CS.selector didn't change during the transition vmx->cpl will be set
to the same value and if it changes cpl cache will be cleared either by
vmx_set_segment() or vmexit.
> And as for EFLAGS, agreed. Sending new patch.
--
Gleb.
next prev parent reply other threads:[~2013-01-04 11:16 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-12-19 13:29 KVM: VMX: fix incorrect cached cpl value with real/v8086 modes Marcelo Tosatti
[not found] ` <CAEbWair0awmpB9QXFGXJmooSsHg3B6P3uZrmLcyzs=T70TS7VA@mail.gmail.com>
2012-12-25 12:48 ` Gleb Natapov
2012-12-25 21:37 ` Marcelo Tosatti
2012-12-26 5:25 ` Gleb Natapov
2012-12-26 13:25 ` Marcelo Tosatti
2012-12-26 13:33 ` Gleb Natapov
2013-01-01 23:36 ` Marcelo Tosatti
2013-01-03 8:11 ` Gleb Natapov
2013-01-03 13:19 ` Marcelo Tosatti
2013-01-04 11:16 ` Gleb Natapov [this message]
2013-01-01 23:41 ` Marcelo Tosatti
2013-01-03 13:49 ` KVM: VMX: fix incorrect cached cpl value with real/v8086 modes (v2) Marcelo Tosatti
2013-01-07 21:27 ` KVM: VMX: fix incorrect cached cpl value with real/v8086 modes (v3) Marcelo Tosatti
2013-01-08 10:56 ` Gleb Natapov
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=20130104111638.GA6547@redhat.com \
--to=gleb@redhat.com \
--cc=avi.kivity@gmail.com \
--cc=kvm@vger.kernel.org \
--cc=mtosatti@redhat.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