Re: [PATCH] KVM: emulator: Only allow VMCALL/VMMCALL trapped by #UD

["Yang, Sheng" <sheng.yang-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>]

On Monday 07 January 2008 17:22:43 Avi Kivity wrote:
> Yang, Sheng wrote:
> >> I have a vague plan for improving decode; basically extend the decode
> >> tables to add group decoding.  We add a bit to opcode_table and
> >> twobyte_table that is set for all instructions which need group
> >> decoding.  When the bit is set, the rest of the value in opcode_table is
> >> interpreted as an index (together with modrm_reg) into a new
> >> group_table, so we can have different decoding for such instructions.
> >
> > I also have tried to propose a table for Grp opcode, but can't find a
> > easy way. Using the rest of the value in opcode_table is a good idea, but
> > I'm afraid the same value for different group exists, e.g. 0x82(Grp1) and
> > 0xc0 (Grp2) got the same value as: ByteOp | DstMem | SrcImm | ModRM. If
> > we add more factors to this, it would become unclear and more tricky, the
> > table also may become larger...
> >
> > Currently, if we want to using group_table, I think the straightforward
> > way is better: another big "switch"... The only exception is 1a, and we
> > may use 0 instead of it.
>
> Not sure what you mean.  I thought of adding code like
>
>
>     if (c->d & Group) {
>           c->group = c->d & GroupMask;

I meant the c->d & GroupMask is not sufficient to indicate different group. 
For example, 0x82(Grp1) and 0xc0(Grp2) have same c->d & GroupMask = ByteOp | 
DstMem | SrcImm | ModRM.

>           // fetch modrm_reg
>           c->d = group_table[c->group * 8 + modrm_reg];

In this case, how can you deal with c->group =  ByteOp | DstMem | SrcImm | 
ModRM, and modrm_reg = 6. Is it a XOR or nothing?

>     }
>
> Instruction execution could continue to be in the regular switch, but
> the decode flags can be different for every instruction in the group.



-- 
Thanks
Yang, Sheng

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/