[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-ppc] [PATCH 0/9] spapr: Clean up pagesize handling
From: |
David Gibson |
Subject: |
Re: [Qemu-ppc] [PATCH 0/9] spapr: Clean up pagesize handling |
Date: |
Thu, 21 Jun 2018 11:08:41 +1000 |
User-agent: |
Mutt/1.10.0 (2018-05-17) |
On Mon, Jun 18, 2018 at 04:35:57PM +1000, David Gibson wrote:
> Currently the "pseries" machine type will (usually) advertise
> different pagesizes to the guest when running under KVM and TCG, which
> is not how things are supposed to work.
>
> This comes from poor handling of hardware limitations which mean that
> under KVM HV the guest is unable to use pagesizes larger than those
> backing the guest's RAM on the host side.
>
> The new scheme turns things around by having an explicit machine
> parameter controlling the largest page size that the guest is allowed
> to use. This limitation applies regardless of accelerator. When
> we're running on KVM HV we ensure that our backing pages are adequate
> to supply the requested guest page sizes, rather than adjusting the
> guest page sizes based on what KVM can supply.
>
> This means that in order to use hugepages in a PAPR guest it's
> necessary to add a "cap-hpt-max-page-size=16m" machine parameter as
> well as setting the mem-path correctly. This is a bit more work on
> the user and/or management side, but results in consistent behaviour
> so I think it's worth it.
>
> Longer term, we might also use this parameter to control IOMMU page
> sizes. But, I'm still working out how restrictions deriving from the
> guest kernel, host kernel and hardware capabilities all interact here.
>
> This applies on top of my ppc-for-3.0 tree.
Greg, Cédric, could you try to review this series pretty soon?
I'd really like to get it merged, because it's the basis for a number
of fixes for assorted problems with hugepage behaviour.
>
> Changes since RFC:
> * Add preliminary cleanups to allow us to evaluate effective
> capabilities levels earlier.
> * Don't try to remove double resetting of cpus. It doesn't quite
> work, and is no longer necessary with the above.
> * Some user-friendliness improvements: use "hpt-max-page-size"
> instead of the cryptic "hpt-mps", and take an actual page size
> (allowing k/m/g suffixies) instead of a shift
>
> David Gibson (9):
> target/ppc: Allow cpu compatiblity checks based on type, not instance
> spapr: Compute effective capability values earlier
> spapr: Add cpu_apply hook to capabilities
> target/ppc: Add kvmppc_hpt_needs_host_contiguous_pages() helper
> spapr: Maximum (HPT) pagesize property
> spapr: Use maximum page size capability to simplify memory backend
> checking
> target/ppc: Add ppc_hash64_filter_pagesizes()
> spapr: Limit available pagesizes to provide a consistent guest
> environment
> spapr: Don't rewrite mmu capabilities in KVM mode
>
> hw/ppc/spapr.c | 45 +++++++-----
> hw/ppc/spapr_caps.c | 156 ++++++++++++++++++++++++++++++++++++----
> hw/ppc/spapr_cpu_core.c | 4 ++
> include/hw/ppc/spapr.h | 11 ++-
> target/ppc/compat.c | 27 +++++--
> target/ppc/cpu.h | 4 ++
> target/ppc/kvm.c | 146 ++++++++++++++++++-------------------
> target/ppc/kvm_ppc.h | 11 ++-
> target/ppc/mmu-hash64.c | 59 +++++++++++++++
> target/ppc/mmu-hash64.h | 3 +
> 10 files changed, 349 insertions(+), 117 deletions(-)
>
--
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: PGP signature
- Re: [Qemu-ppc] [PATCH 6/9] spapr: Use maximum page size capability to simplify memory backend checking, (continued)