On 03/31/2011 11:42 AM, Roedel, Joerg wrote:
On Thu, Mar 31, 2011 at 05:18:28AM -0400, Avi Kivity wrote:
> On 03/31/2011 09:14 AM, Roedel, Joerg wrote:
> > On Mon, Mar 28, 2011 at 08:28:12AM -0400, Avi Kivity wrote:
> > > The spec indicates we need to check the TSS and IOPL based permissions
> > > before the intercept (vmx agrees). With the code as is, it happens
> > > afterwards.
> > >
> > > One way to do this is to have an ExtraChecks bit in the opcode::flags.
> > > Then opcode::u.xcheck->perms() is the pre-intercept check and
> > > opcode::u.xcheck->execute() is the post-intercept execution. Should
> > > work for monitor/mwait/rdtsc(p)/rdpmc/other crap x86 throws at us.
> >
> > Okay, as you suggested, I put these checks into the instruction emulator
> > and let the hard work of implementing per-arch checks to the nested-vmx
> > people ;)
> > I doubt that this makes the opcode-tables more readable, but lets see :)
>
> I think we're miscommunicating. I'm talking about x86 checks, not virt
> vendor specific checks.
The place of the intercept check may be vendor specific. I havn't looked
at the Intel spec, though. But there are probably differences.
That's why there are three hooks: pre-ex, post-ex, post-mem. If an
intercept fits in between, use the pre-ex hook and duplicate the checks
in the intercept.
As far as I recall, everything should fit into those three, though.
> For example, the flow for IOIO would be:
>
> #UD check (lock prefix)
> PE/IOPL/CPL/VM check
> TSS bitmap check (can cause #PF)
> Intercept check
> Operand segment check
> Possible #PF
> Execution
>
> We need to make sure the TSS bitmap check happens before the intercept,
> so we need to split ->execute() into two.
Right. For the generic case, how about factor out the checks (for the
POST_EX intercept case) into a seperate excp_check-callback (similar to the
execute-callback) and execute it before the post-exception-intercept
check?
That is exactly my suggestion.
--
error compiling committee.c: too many arguments to function
--
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