From: Gleb Natapov <gleb@redhat.com>
To: Kevin Wolf <kwolf@redhat.com>
Cc: kvm@vger.kernel.org, joerg.roedel@amd.com,
yoshikawa.takuya@oss.ntt.co.jp, avi@redhat.com,
mtosatti@redhat.com
Subject: Re: [PATCH v2 0/3] Fix task switches into/out of VM86
Date: Mon, 30 Jan 2012 12:47:11 +0200 [thread overview]
Message-ID: <20120130104711.GB23536@redhat.com> (raw)
In-Reply-To: <4F267254.7040900@redhat.com>
On Mon, Jan 30, 2012 at 11:35:00AM +0100, 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.
>
> 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.
>
I think you made my point (that cpl in svm should be updated on rflags
update) by pointing me to this part of the spec:
The processor tests the VM flag under three general conditions:
• When loading segment registers, to determine whether to use 8086-style address translation.
• When decoding instructions, to determine which instructions are not supported in
virtual-8086 mode and which instructions are sensitive to IOPL.
• When checking privileged instructions, on page accesses, or when performing
other permission checks. (Virtual-8086 mode always executes at CPL 3.)
Bullet 3 clearly proves it.
Furthermore task switch loads eflags and segment selector at stage 12.
After that CPU runs on a new task, but since segment descriptors are
still not loaded CS dpl is not updated yet, but task is in CPL3 already.
> > BTW does load_state_from_tss16() need the same fix?
>
> The manual says "Do not use a 16-bit TSS to implement a virtual-8086
> task." Actually, I don't think you could do that, even if you wanted,
> with a 16-bit flags field.
>
Yes. May be there are other reasons to update flags earlier like spec
specifies, but I can think of any. Will fix them when we find them.
--
Gleb.
prev parent reply other threads:[~2012-01-30 10:47 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-01-27 19:23 [PATCH v2 0/3] Fix task switches into/out of VM86 Kevin Wolf
2012-01-27 19:23 ` [PATCH v2 1/3] KVM: x86 emulator: Fix task switch privilege checks Kevin Wolf
2012-01-30 10:39 ` Avi Kivity
2012-01-30 11:12 ` Kevin Wolf
2012-01-27 19:23 ` [PATCH v2 2/3] KVM: x86 emulator: VM86 segments must have DPL 3 Kevin Wolf
2012-01-27 19:23 ` [PATCH v2 3/3] KVM: x86 emulator: Allow PM/VM86 switch during task switch Kevin Wolf
2012-01-30 10:24 ` Avi Kivity
2012-01-30 10:56 ` Gleb Natapov
2012-01-30 12:02 ` Avi Kivity
2012-01-30 12:04 ` Gleb Natapov
2012-01-30 13:24 ` Avi Kivity
2012-01-30 11:05 ` Kevin Wolf
2012-01-30 11:09 ` Gleb Natapov
2012-01-30 13:23 ` Avi Kivity
2012-01-30 14:01 ` Kevin Wolf
2012-01-30 14:32 ` Avi Kivity
2012-01-30 15:26 ` Kevin Wolf
2012-01-30 15:44 ` Avi Kivity
2012-01-30 15:55 ` Takuya Yoshikawa
2012-01-31 9:37 ` Gleb Natapov
2012-01-31 10:26 ` Avi Kivity
2012-01-27 19:52 ` [PATCH v2 0/3] Fix task switches into/out of VM86 Gleb Natapov
2012-01-30 8:48 ` Kevin Wolf
2012-01-30 8:55 ` Gleb Natapov
2012-01-30 10:22 ` Gleb Natapov
2012-01-30 10:35 ` Kevin Wolf
2012-01-30 10:45 ` Avi Kivity
2012-01-30 10:50 ` Gleb Natapov
2012-01-30 11:59 ` Avi Kivity
2012-01-30 12:16 ` Gleb Natapov
2012-01-30 13:27 ` Avi Kivity
2012-01-30 12:31 ` Gleb Natapov
2012-01-30 13:28 ` Avi Kivity
2012-01-30 13:29 ` Gleb Natapov
2012-01-30 13:39 ` Avi Kivity
2012-01-30 10:47 ` Gleb Natapov [this message]
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=20120130104711.GB23536@redhat.com \
--to=gleb@redhat.com \
--cc=avi@redhat.com \
--cc=joerg.roedel@amd.com \
--cc=kvm@vger.kernel.org \
--cc=kwolf@redhat.com \
--cc=mtosatti@redhat.com \
--cc=yoshikawa.takuya@oss.ntt.co.jp \
/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;
as well as URLs for NNTP newsgroup(s).