Re: [PATCH kernel v6 5/7] vfio/spapr: Postpone default window creation

[David Gibson <david@gibson.dropbear.id.au>]

[-- Attachment #1: Type: text/plain, Size: 1653 bytes --]

On Fri, Nov 25, 2016 at 05:38:26PM +1100, Alexey Kardashevskiy wrote:
> On 25/11/16 15:39, David Gibson wrote:
> > On Thu, Nov 24, 2016 at 04:48:08PM +1100, Alexey Kardashevskiy wrote:
> >> 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>
> > 
> > Hmm.. it just occurred to me: why do you even need to delay creation
> > of the default window?
> 
> 
> Because I want to account the memory it uses in locked_vm of the mm which
> will later be used for map/unmap.

Ah, good point.  How is the locked vm accounted for the non ddw case.

-- 
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 #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]