Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Date:   Wed, 20 Mar 2019 11:03:25 -0600
From:   Alex Williamson <alex.williamson@redhat.com>
To:     Maxim Levitsky <mlevitsk@redhat.com>
Cc:     Bart Van Assche <bvanassche@acm.org>,
        linux-nvme@lists.infradead.org, Fam Zheng <fam@euphon.net>,
        Jens Axboe <axboe@fb.com>, Sagi Grimberg <sagi@grimberg.me>,
        kvm@vger.kernel.org, Wolfram Sang <wsa@the-dreams.de>,
        Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        Liang Cunming <cunming.liang@intel.com>,
        Nicolas Ferre <nicolas.ferre@microchip.com>,
        linux-kernel@vger.kernel.org,
        Liu Changpeng <changpeng.liu@intel.com>,
        Keith Busch <keith.busch@intel.com>,
        Kirti Wankhede <kwankhede@nvidia.com>,
        Christoph Hellwig <hch@lst.de>,
        Paolo Bonzini <pbonzini@redhat.com>,
        Mauro Carvalho Chehab <mchehab+samsung@kernel.org>,
        John Ferlan <jferlan@redhat.com>,
        "Paul E . McKenney" <paulmck@linux.ibm.com>,
        Amnon Ilan <ailan@redhat.com>,
        "David S . Miller" <davem@davemloft.net>
Subject: Re: [PATCH 0/9] RFC: NVME VFIO mediated device
Message-ID: <20190320110325.465c1dff@x1.home>
In-Reply-To: <8994f43d26ebf6040b9d5d5e3866ee81abcf1a1c.camel@redhat.com>
References: <20190319144116.400-1-mlevitsk@redhat.com>
        <1553095686.65329.36.camel@acm.org>
        <8994f43d26ebf6040b9d5d5e3866ee81abcf1a1c.camel@redhat.com>
Organization: Red Hat
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Wed, 20 Mar 2019 18:42:02 +0200
Maxim Levitsky <mlevitsk@redhat.com> wrote:

> On Wed, 2019-03-20 at 08:28 -0700, Bart Van Assche wrote:
> > On Tue, 2019-03-19 at 16:41 +0200, Maxim Levitsky wrote:  
> > > *  All guest memory is mapped into the physical nvme device 
> > >    but not 1:1 as vfio-pci would do this.
> > >    This allows very efficient DMA.
> > >    To support this, patch 2 adds ability for a mdev device to listen on 
> > >    guest's memory map events. 
> > >    Any such memory is immediately pinned and then DMA mapped.
> > >    (Support for fabric drivers where this is not possible exits too,
> > >     in which case the fabric driver will do its own DMA mapping)  
> > 
> > Does this mean that all guest memory is pinned all the time? If so, are you
> > sure that's acceptable?  
> I think so. The VFIO pci passthrough also pins all the guest memory.
> SPDK also does this (pins and dma maps) all the guest memory.
> 
> I agree that this is not an ideal solution but this is a fastest and simplest
> solution possible.

FWIW, the pinned memory request up through the vfio iommu driver count
against the user's locked memory limits, if that's the concern.  Thanks,

Alex