qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 0/9] spapr: Clean up pagesize handling


From: David Gibson
Subject: Re: [Qemu-devel] [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

Attachment: signature.asc
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]