[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [Qemu-ppc] [0/8] RFC: target-ppc: Start disentangling d
From: |
David Gibson |
Subject: |
Re: [Qemu-devel] [Qemu-ppc] [0/8] RFC: target-ppc: Start disentangling different MMU types |
Date: |
Sat, 23 Feb 2013 22:37:39 +1100 |
User-agent: |
Mutt/1.5.21 (2010-09-15) |
On Sat, Feb 23, 2013 at 11:35:08AM +0100, Alexander Graf wrote:
>
>
> Am 23.02.2013 um 09:28 schrieb David Gibson <address@hidden>:
>
> > On Fri, Feb 22, 2013 at 05:15:22PM +0100, Alexander Graf wrote:
> >>
> >> On 12.02.2013, at 03:00, David Gibson wrote:
> >>
> >>> The target-ppc code supports CPUs with a number of different MMU
> >>> types: there's both the 32-bit and 64-bit versions of the "classic"
> >>> hash page table based powerpc mmu and there's also the BookE and 40x
> >>> MMUs.
> >>>
> >>> Currently handling of all these has a roughly shared path in
> >>> mmu_helper.c. Although code sharing is usually a good idea, in this
> >>> case the MMUs really aren't similar enough for this to be useful.
> >>> Instead it results in checking and behaving differently at many, many
> >>> different points in the path leading to an unreadable tangle of code.
> >>>
> >>> This patch series is a first step to cleaning this up, moving to a
> >>> model where we have a single switch on the MMU family at the top-level
> >>> entry points, then have a simpler, clearer separate code path for each
> >>> MMU type. More specifically, it disentangles the path for the 64-bit
> >>> classic hash MMU into its own new file. The other MMU types keep the
> >>> existing code (minus 64-bit hash specific conditionals) for now.
> >>> Disentangling those as well would be a good idea, but would be best
> >>> done by someone with more resources to test those other platforms than
> >>> I have.
> >>>
> >>> For now, the resulting 64-bit hash path retains the same structure as
> >>> the original shared code, just the obvious conditionals on other mmu
> >>> types are removed. This path is fairly ugly in itself, but cleaning
> >>> that up is a later step, now much simpler without the other MMU types
> >>> to deal with at the same time.
> >>
> >> Looks like a nice and long overdue cleanup. A few points I'd like to see
> >> addressed:
> >>
> >> - Instead of exporting common helper functions, put them into a
> >> new mmu-hash.h as static inline. That way things can get optimized
> >> a lot better.
> >
> > The common helpers are all gone again by the end of the series, so is
> > there really any point?
>
> Oh, really? I must have missed the bit where you remove / unexport
> them then ;).
11/32 "Disentangle hash mmu helper functions"
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
signature.asc
Description: Digital signature
- Re: [Qemu-devel] [Qemu-ppc] [PATCH 8/8] target-ppc Disentangle ppc64 hash mmu path for cpu_ppc_handle_mmu_fault, (continued)
- [Qemu-devel] [PATCH 4/8] target-ppc: Disentangle 64-bit version of find_pte(), David Gibson, 2013/02/11
- [Qemu-devel] [PATCH 2/8] target-ppc: Move SLB handling into a mmu-hash64.c, David Gibson, 2013/02/11
- [Qemu-devel] [PATCH 5/8] target-ppc: Disentangle 64-bit version of get_segment(), David Gibson, 2013/02/11
- Re: [Qemu-devel] [0/8] RFC: target-ppc: Start disentangling different MMU types, Andreas Färber, 2013/02/12
- Re: [Qemu-devel] [0/8] RFC: target-ppc: Start disentangling different MMU types, Alexander Graf, 2013/02/22