From mboxrd@z Thu Jan 1 00:00:00 1970 From: Hollis Blanchard Date: Mon, 28 Jan 2008 21:38:45 +0000 Subject: Re: [kvm-ppc-devel] [PATCH 4/5] Refactor TLB codes about 44x Message-Id: <1201556325.8969.139.camel@basalt> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: kvm-ppc@vger.kernel.org On Fri, 2008-01-25 at 15:12 +0800, Zhang Wei wrote: > Signed-off-by: Zhang Wei > --- > arch/powerpc/kvm/44x_tlb.c | 309 +++++++++++++++++------------------------ > arch/powerpc/kvm/44x_tlb.h | 5 - > arch/powerpc/kvm/Makefile | 2 +- > arch/powerpc/kvm/emulate.c | 4 +- > arch/powerpc/kvm/powerpc.c | 34 ++--- > arch/powerpc/kvm/tlb.c | 226 ++++++++++++++++++++++++++++++ > arch/powerpc/kvm/tlb.h | 54 +++++++ > include/asm-powerpc/kvm_asm.h | 2 +- > 8 files changed, 426 insertions(+), 210 deletions(-) > create mode 100644 arch/powerpc/kvm/tlb.c > create mode 100644 arch/powerpc/kvm/tlb.h My ideas in this area are not complete, but let me explain my current thinking. Basically there are two different sets of code in 44x_tlb.c right now: 440 host code and 440 guest code. Every *host* module exports a common MMU API, so that *guest* modules can use them without knowing what the host is. That API right now is: * kvmppc_mmu_map(vcpu, u64 gvaddr, gfn_t gfn, u64 asid, u32 flags) * kvmppc_mmu_invalidate(vcpu, u64 eaddr, u64 asid) * kvmppc_mmu_priv_switch(vcpu, int usermode) The 440 host module implements these using 440-specific code, such as iterating over vcpu->shadow_tlb. On an e600, for example, there would be no such thing as a shadow TLB, so they would be implemented differently, probably in terms of a shadow HTAB. The other piece of 44x_tlb.c is about emulating the guest MMU. This is used in two places: instruction emulation and interrupt handling. 1. I had been thinking that various parts of emulate_instruction would be contingent on the vcpu type, so that every switch statement in emulate.c would end in something like... switch (get_xop(inst)) { ... default: emulated = vcpu->emulate_xop(inst); printk("unknown: op %d xop %d\n", get_op(inst), get_xop(inst)); } This would also allow us to run multiple guest types at the same time. emul_tlbwe() would move into that vcpu callback, since e500's tlbwe looks very different from 440's. 2. As for the interrupt handling side, I guess we might also need callbacks there. For example, the kvmppc_handle_exit() calls kvmppc_44x_dtlb_search() directly. Instead it should do something like if (!vcpu->is_mapped(eaddr)) { vcpu->dtlb_miss(eaddr); r = RESUME_GUEST; break; } (In both these cases, we could look at doing preprocessor magic to replace the indirect function calls, something like if (BOOKE_CALL(is_mapped(eaddr)) which could translate to if (e500_is_mapped(eaddr)) and if (440_is_mapped(eaddr)) In that case, we would need build magic to produce two "guest BookE" modules, booke_e500 and booke_440.) In conclusion, I don't think this patch fits into the model I've described. Does this all make sense? I'm open to any ideas or suggestions... -- Hollis Blanchard IBM Linux Technology Center ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ kvm-ppc-devel mailing list kvm-ppc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-ppc-devel