On Fri, 2008-09-12 at 10:59 +0800, Liu Yu-B13201 wrote: > > > @@ -222,6 +130,7 @@ int kvmppc_emulate_instruction(struct kv > > int rc; > > int rs; > > int rt; > > + int ws; > > int sprn; > > int dcrn; > > enum emulation_result emulated = EMULATE_DONE; > > @@ -630,33 +539,18 @@ int kvmppc_emulate_instruction(struct kv > > break; > > > > case 978: > > /* tlbwe */ > > - emulated = kvmppc_emul_tlbwe(vcpu, inst); > > + ra = get_ra(inst); > > + rs = get_rs(inst); > > + ws = get_ws(inst); > > + emulated = kvmppc_emul_tlbwe(vcpu, ra, rs, > ws); > > break; > > E500 has no argument in instructions tlbwe and tlbsx, different from > 44x. > So ra, rs, ws are redundant to e500. > Maybe we can keep the old interface: kvmppc_emul_tlbwe(vcpu, inst), > kvmppc_emul_tlbsx(vcpu, inst) > and move instruction operations get_ra(), get_rs(), get_ws() etc. to a > header file. I thought about that, but get_ra/rs/ws are all specific to instruction emulation, so I'd rather keep them in emulate.c. (In fact they're static inlines in that file.) Also, they are trivial to calculate (like 1 instruction each), so I don't think it's worth trying to avoid them. If the e500 implementation of kvmppc_emul_tlbwe() doesn't actually use them, so what? Basically I think the parameters to the per-core hook functions should be the union of the parameters required by every hook implementation. In places where some of those parameters are very expensive to calculate, it would make sense to avoid it, but this isn't one of those instances. Along those same lines, from our other discussion around the TLB miss handler, I would be fine with keeping two variables: TLB_index and TLB_select, where TLB_select happens always to be 0 on 440. In that particular case, it just so happens that it's very easy to combine them into a single integer, so we don't need to have two after all... but philosophically I'd be happy with it. -- Hollis Blanchard IBM Linux Technology Center -- To unsubscribe from this list: send the line "unsubscribe kvm-ppc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
