vfio/spapr: Postpone default window creation
authorAlexey Kardashevskiy <aik@ozlabs.ru>
Wed, 30 Nov 2016 06:52:03 +0000 (17:52 +1100)
committerMichael Ellerman <mpe@ellerman.id.au>
Fri, 2 Dec 2016 03:38:32 +0000 (14:38 +1100)
commitd9c728949ddc9de5734bf3b12ea906ca8a77f2a0
treebe2f59c181c28e423b00f0908f0923617ec3c993
parent6f01cc692a16405235d5c34056455b182682123c
vfio/spapr: Postpone default window creation

We are going to allow the userspace to configure container in
one memory context and pass container fd to another so
we are postponing memory allocations accounted against
the locked memory limit. One of previous patches took care of
it_userspace.

At the moment we create the default DMA window when the first group is
attached to a container; this is done for the userspace which is not
DDW-aware but familiar with the SPAPR TCE IOMMU v2 in the part of memory
pre-registration - such client expects the default DMA window to exist.

This postpones the default DMA window allocation till one of
the folliwing happens:
1. first map/unmap request arrives;
2. new window is requested;
This adds noop for the case when the userspace requested removal
of the default window which has not been created yet.

Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
Acked-by: Alex Williamson <alex.williamson@redhat.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
drivers/vfio/vfio_iommu_spapr_tce.c