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

[Avi Kivity <avi-atKUWr5tajBWk0Htik3J/w@public.gmane.org>]

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;
          // fetch modrm_reg
          c->d = group_table[c->group * 8 + modrm_reg];
    }

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

-- 
error compiling committee.c: too many arguments to function


-------------------------------------------------------------------------
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/