Re: [kvm-ppc-devel] [PATCH 3/5] Use TLB macro instead of

[Hollis Blanchard <hollisb@us.ibm.com>]

On Fri, 2008-01-25 at 15:12 +0800, Zhang Wei wrote:
> The 44x dependence MMU operations can be replaced by TLB marco,
> which modifications are prepared for adding e500 MMU macro
> to booke_interrupts.S
> 
> Signed-off-by: Zhang Wei <wei.zhang@freescale.com>
> ---
>  arch/powerpc/kvm/44x_int_asm.h      |   41 +++++++++++++++++++++
>  arch/powerpc/kvm/booke_interrupts.S |   67 ++++++++++-------------------------
>  include/asm-powerpc/kvm_asm.h       |    4 ++
>  3 files changed, 64 insertions(+), 48 deletions(-)
>  create mode 100644 arch/powerpc/kvm/44x_int_asm.h
> 
> diff --git a/arch/powerpc/kvm/44x_int_asm.h b/arch/powerpc/kvm/44x_int_asm.h
> new file mode 100644
> index 0000000..73fe2d8
> --- /dev/null
> +++ b/arch/powerpc/kvm/44x_int_asm.h
> @@ -0,0 +1,41 @@
> +#ifndef __ARCH_POWERPC_KVM_44X_INT_ASM_H__
> +#define __ARCH_POWERPC_KVM_44X_INT_ASM_H__
> +
> +/* Load TLB size to rd register */
> +.macro LOAD_TLB_SIZE rd
> +	li	\rd, PPC44x_TLB_SIZE
> +.endm
> +
> +/* TLB entry will be loaded from rd + 4 address to r_entry_idx entry */
> +.macro TLB_ENTRY_LOAD r_entry_idx, rd, ra
> +	lwzu	\rd, 4(\ra)
> +	mtspr	SPRN_MMUCR, \rd
> +	lwzu	\rd, 4(\ra)
> +	tlbwe	\rd, \r_entry_idx, PPC44x_TLB_PAGEID
> +	lwzu	\rd, 4(\ra)
> +	tlbwe	\rd, \r_entry_idx, PPC44x_TLB_XLAT
> +	lwzu	\rd, 4(\ra)
> +	tlbwe	\rd, \r_entry_idx, PPC44x_TLB_ATTRIB
> +.endm
> +
> +/* TLB entry will be saved to rd + 4 address */
> +.macro TLB_ENTRY_SAVE r_entry_idx, rd, ra
> +	mfspr	\rd, SPRN_MMUCR
> +	stwu	\rd, 4(\ra)
> +	tlbre	\rd, \r_entry_idx, PPC44x_TLB_PAGEID
> +	stwu	\rd, 4(\ra)
> +	tlbre	\rd, \r_entry_idx, PPC44x_TLB_XLAT
> +	stwu	\rd, 4(\ra)
> +	tlbre	\rd, \r_entry_idx, PPC44x_TLB_ATTRIB
> +	stwu	\rd, 4(\ra)
> +.endm
> +
> +.macro SAVE_MMUCR rd
> +	mfspr	\rd, SPRN_MMUCR
> +.endm
> +
> +.macro LOAD_MMUCR rd
> +	mtspr	SPRN_MMUCR, \rd
> +.endm
> +
> +#endif /* __ARCH_POWERPC_KVM_44X_INT_ASM_H__ */

Hmm, I assumed that e500 would need entirely new TLB miss handlers, and
in that case this patch wouldn't make sense.

In the long run, what will your lightweight and heavyweight exit paths
look like? Presumably you will need to save and restore entries from
both TLB0 and TLB1, in which case these macros aren't enough because
they don't specify a TLB. Or do you plan to encode the TLB number into
r_entry_idx?

In the latest 440 code, I leave the host's pinned entries in the TLB
while the guest is running (safe because they are AS=0, and guest runs
DS/IS=1). That way, when the guest exits, no TLB state needs to be
touched since the host is still mapped. When re-entering the guest I
must preserve the entire TLB state, since the host could have changed
any of the unpinned mappings, but in the future I plan to track all host
insertions so that we can save/restore only a few unpinned entries.

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