[libvirt] [PATCH 6/6] qemu: Add ppc64-specific math to qemuDomainGetMlockLimitBytes()

[Peter Krempa]

On Wed, Nov 18, 2015 at 15:13:20 +0100, Andrea Bolognani wrote:
> The amount of memory a ppc64 domain might need to lock is different
> than that of a equally-sized x86 domain, so we need to check the
> domain's architecture and act accordingly.
> 
> Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1273480
> ---
>  src/qemu/qemu_domain.c | 80 +++++++++++++++++++++++++++++++++++++++++++++++++-
>  1 file changed, 79 insertions(+), 1 deletion(-)
> 
> diff --git a/src/qemu/qemu_domain.c b/src/qemu/qemu_domain.c
> index 2c0f5af..1e92b9d 100644
> --- a/src/qemu/qemu_domain.c
> +++ b/src/qemu/qemu_domain.c

[...]

> +        /* baseLimit := maxMemory / 128                                  (a)
> +         *              + 4 MiB * #PHBs + 8 MiB                          (b)
> +         *
> +         * (a) is the hash table
> +         *
> +         * (b) is accounting for the 32-bit DMA window - it could be either the
> +         * KVM accelerated TCE tables for emulated devices, or the VFIO
> +         * userspace view. The 4 MiB per-PHB (including the default one) covers
> +         * a 2GiB DMA window: default is 1GiB, but it's possible it'll be
> +         * increased to help performance. The 8 MiB extra should be plenty for
> +         * the TCE table index for any reasonable number of PHBs and several
> +         * spapr-vlan or spapr-vscsi devices (512kB + a tiny bit each) */
> +        baseLimit = maxMemory / 128 +
> +                    4096 * nPCIHostBridges +
> +                    8192;
> +
> +        /* passthroughLimit := max( 2 GiB * #PHBs,                       (c)
> +         *                          memory                               (d)
> +         *                          + memory * 1/512 * #PHBs + 8 MiB )   (e)
> +         *
> +         * (c) is the pre-DDW VFIO DMA window accounting. We're allowing 2 GiB
> +         * rather than 1 GiB
> +         *
> +         * (d) is the with-DDW (and memory pre-registration and related
> +         * features) DMA window accounting - assuming that we only account RAM
> +         * once, even if mapped to multiple PHBs
> +         *
> +         * (e) is the with-DDW userspace view and overhead for the 64-bit DMA
> +         * window. This is based a bit on expected guest behaviour, but there
> +         * really isn't a way to completely avoid that. We assume the guest
> +         * requests a 64-bit DMA window (per PHB) just big enough to map all
> +         * its RAM. 4 kiB page size gives the 1/512; it will be less with 64
> +         * kiB pages, less still if the guest is mapped with hugepages (unlike
> +         * the default 32-bit DMA window, DDW windows can use large IOMMU
> +         * pages). 8 MiB is for second and further level overheads, like (b) */
> +        passthroughLimit = MAX(2 * 1024 * 1024 * nPCIHostBridges,
> +                               memory +
> +                               memory / 512 * nPCIHostBridges + 8192);
> +
> +        if (usesVFIO)
> +            memKB = baseLimit + passthroughLimit;
> +        else
> +            memKB = baseLimit;

Is there any public documentation where you were taking the info from?
Should we link it to the code?

Peter
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20151118/bfb039a4/attachment-0001.sig>