Commit Graph

11 Commits

Author SHA1 Message Date
Blue Swirl
6575c289f8 target-ppc: make some functions static
Signed-off-by: Blue Swirl <blauwirbel@gmail.com>
Acked-by: Alexander Graf <agraf@suse.de>
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2012-11-01 19:49:45 +01:00
Peter Maydell
21b2f13ae2 Drop unnecessary check of TARGET_PHYS_ADDR_SPACE_BITS
For all our PPC targets the physical address space is at least
36 bits, so drop an unnecessary preprocessor conditional check
on TARGET_PHYS_ADDR_SPACE_BITS (erroneously introduced as part
of the change from target_phys_addr_t to hwaddr). This brings
this bit of code into line with the way we handle the other
cases which were originally checking TARGET_PHYS_ADDR_BITS in
order to avoid compiler complaints about overflowing a 32 bit type.

Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Alexander Graf <agraf@suse.de>
2012-10-29 11:45:53 +01:00
Avi Kivity
a8170e5e97 Rename target_phys_addr_t to hwaddr
target_phys_addr_t is unwieldly, violates the C standard (_t suffixes are
reserved) and its purpose doesn't match the name (most target_phys_addr_t
addresses are not target specific).  Replace it with a finger-friendly,
standards conformant hwaddr.

Outstanding patchsets can be fixed up with the command

  git rebase -i --exec 'find -name "*.[ch]"
                        | xargs s/target_phys_addr_t/hwaddr/g' origin

Signed-off-by: Avi Kivity <avi@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
2012-10-23 08:58:25 -05:00
Avi Kivity
4be403c815 Make target_phys_addr_t 64 bits unconditionally
The hassle and compile time overhead of maintaining both 32-bit and 64-bit
capable source isn't worth the tiny performance advantage which is seen on
a minority of configurations.  Switch to compiling libhw only once, with
target_phys_addr_t unconditionally typedefed to uint64_t.

Signed-off-by: Avi Kivity <avi@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
2012-10-04 19:46:18 -05:00
Benjamin Herrenschmidt
4656e1f012 ppc64: Rudimentary Support for extra page sizes on server CPUs
More recent Power server chips (i.e. based on the 64 bit hash MMU)
support more than just the traditional 4k and 16M page sizes.  This
can get quite complicated, because which page sizes are supported,
which combinations are supported within an MMU segment and how these
page sizes are encoded both in the SLB entry and the hash PTE can vary
depending on the CPU model (they are not specified by the
architecture).  In addition the firmware or hypervisor may not permit
use of certain page sizes, for various reasons.  Whether various page
sizes are supported on KVM, for example, depends on whether the PR or
HV variant of KVM is in use, and on the page size of the memory
backing the guest's RAM.

This patch adds information to the CPUState and cpu defs to describe
the supported page sizes and encodings.  Since TCG does not yet
support any extended page sizes, we just set this to NULL in the
static CPU definitions, expanding this to the default 4k and 16M page
sizes when we initialize the cpu state.  When using KVM, however, we
instead determine available page sizes using the new
KVM_PPC_GET_SMMU_INFO call.  For old kernels without that call, we use
some defaults, with some guesswork which should do the right thing for
existing HV and PR implementations.  The fallback might not be correct
for future versions, but that's ok, because they'll have
KVM_PPC_GET_SMMU_INFO.

Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Signed-off-by: Alexander Graf <agraf@suse.de>
2012-06-24 01:04:44 +02:00
Fabien Chouteau
77c2cf33fe booke_206_tlbwe: Discard invalid bits in MAS2
The size of EPN field in MAS2 depends on page size. This patch adds a
mask to discard invalid bits in EPN field.

Definition of EPN field from e500v2 RM:
EPN Effective page number: Depending on page size, only the bits
associated with a page boundary are valid. Bits that represent offsets
within a page are ignored and should be cleared.

There is a similar (but more complicated) definition in PowerISA V2.06.

Signed-off-by: Fabien Chouteau <chouteau@adacore.com>
Signed-off-by: Alexander Graf <agraf@suse.de>
2012-06-24 01:04:44 +02:00
Blue Swirl
9aa5b15848 ppc: Cleanup MMU merge
Remove useless wrappers. In some cases 'int' parameters are
changed to uint32_t.

Make internal functions static.

Signed-off-by: Blue Swirl <blauwirbel@gmail.com>
[agraf: fix kvm compilation]
Signed-off-by: Alexander Graf <agraf@suse.de>
Signed-off-by: Andreas Färber <afaerber@suse.de>
Signed-off-by: Alexander Graf <agraf@suse.de>
2012-06-24 01:04:42 +02:00
Blue Swirl
8cbbe3851c ppc: Move MMU helpers from helper.c to mmu_helper.c
Move more MMU helpers from helper.c to mmu_helper.c.

Signed-off-by: Blue Swirl <blauwirbel@gmail.com>
Signed-off-by: Alexander Graf <agraf@suse.de>
Signed-off-by: Andreas Färber <afaerber@suse.de>
[update to current helper.c state]
Signed-off-by: Alexander Graf <agraf@suse.de>
2012-06-24 01:04:42 +02:00
Blue Swirl
4cc2cc0855 ppc: Avoid a warning with the next patch
When the code is moved together by the next patch, compiler
detects a possible uninitialized variable use. Avoid the warning
by initializing the variables.

Signed-off-by: Blue Swirl <blauwirbel@gmail.com>
Signed-off-by: Alexander Graf <agraf@suse.de>
Signed-off-by: Andreas Färber <afaerber@suse.de>
Signed-off-by: Alexander Graf <agraf@suse.de>
2012-06-24 01:04:42 +02:00
Blue Swirl
c6c7cf05e1 ppc: Avoid AREG0 for MMU etc. helpers
Add an explicit CPUPPCState parameter instead of relying on AREG0.

Signed-off-by: Blue Swirl <blauwirbel@gmail.com>
Signed-off-by: Alexander Graf <agraf@suse.de>
Signed-off-by: Andreas Färber <afaerber@suse.de>
Signed-off-by: Alexander Graf <agraf@suse.de>
2012-06-24 01:04:42 +02:00
Blue Swirl
ec19c4d146 ppc: Split MMU etc. helpers from op_helper.c
Move MMU, TLB, SLB and BAT ops to mmu_helper.c.

Signed-off-by: Blue Swirl <blauwirbel@gmail.com>
Signed-off-by: Alexander Graf <agraf@suse.de>
Signed-off-by: Andreas Färber <afaerber@suse.de>
Signed-off-by: Alexander Graf <agraf@suse.de>
2012-06-24 01:04:41 +02:00