pseries: Fix incorrect calculation of RMA size in certain configurations
commitf36951c19f15f3c053a31234bd2c297d86c1a052
authorDavid Gibson <david@gibson.dropbear.id.au>
Sun, 7 Apr 2013 19:08:18 +0000 (7 19:08 +0000)
committerAlexander Graf <agraf@suse.de>
Fri, 26 Apr 2013 21:02:41 +0000 (26 23:02 +0200)
treeab24b0a206802fd72670b5c5bf3df63899cf4d7d
parentc8ff5daa09516272117eb23cd00da5d188ba73eb
pseries: Fix incorrect calculation of RMA size in certain configurations

For the pseries machine, we need to advertise to the guest the size of its
RMA - that is the amount of memory it can access with the MMU off.  For HV
KVM, this is constrained by the hardware limitations on the virtual RMA of
one hash PTE per PTE group in the hash page table.  We already had code to
calculate this, but it was assuming the VRMA page size was the same as the
(host) backing page size for guest RAM.

In the case of a host kernel configured for 64k base page size, but running
on hardware (or firmware) which only allows 4k pages, the hose will do all
its allocations with a 64k page size, but still use 4k hardware pages for
actual mappings.  Usually that's transparent to things running under the
host, but in the case of the maximum VRMA size it's not.

This patch refines the RMA size calculation to instead use the largest
available hardware page size (as reported by the SMMU_INFO call) which is
less than or equal to the backing page size.  This now gives the correct
RMA size in all cases I've tested.

Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Signed-off-by: Alexander Graf <agraf@suse.de>
target-ppc/kvm.c