Re: [kvm-ppc-devel] [PATCH 4/5] Refactor TLB codes about 44x

Re: [kvm-ppc-devel] [PATCH 4/5] Refactor TLB codes about 44x

[Hollis Blanchard]

On Fri, 2008-01-25 at 15:12 +0800, Zhang Wei wrote:
> Signed-off-by: Zhang Wei <wei.zhang@freescale.com>
> ---
>  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