From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Yang, Sheng" Subject: Re: [PATCH] KVM: emulator: Only allow VMCALL/VMMCALL trapped by #UD Date: Mon, 7 Jan 2008 19:21:53 +0800 Message-ID: <200801071921.54294.sheng.yang@intel.com> References: <200801040936.08670.sheng.yang@intel.com> <200801071823.15040.sheng.yang@intel.com> <47820268.9060309@qumranet.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org, Eric Liu To: Avi Kivity Return-path: In-Reply-To: <47820268.9060309-atKUWr5tajBWk0Htik3J/w@public.gmane.org> Content-Disposition: inline List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kvm-devel-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org Errors-To: kvm-devel-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org List-Id: kvm.vger.kernel.org On Monday 07 January 2008 18:43:52 Avi Kivity wrote: > Yang, Sheng wrote: > > 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. > > I now see the source of confusion... > > >> // 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? > > In this case, we would have > > opcode_table[0x82] == Group | Grp1 (c->group == Grp1 == 1) > opcode_table[0xc0] == Group | Grp2 (c->group == Grp2 == 2) > group_table[Grp1 * 8 + 6] == ByteOp | DstMem | SrcImm | ModRM > group_table[Grp2 * 8 + 0] == ByteOp | DstMem | SrcImm | ModRM > > If Group is set in opcode_table, the rest of the value is the group > number, with the reg part used to pick the final decode flags. Faint... Yeah, I think that's pretty good. Sorry for misunderstanding... -- 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/