linux-kernel - Re: [PATCH 0/9] RFC: NVME VFIO mediated device

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 20 Mar 2019 11:03:25 -0600
From:   Alex Williamson <alex.williamson@...hat.com>
To:     Maxim Levitsky <mlevitsk@...hat.com>
Cc:     Bart Van Assche <bvanassche@....org>,
        linux-nvme@...ts.infradead.org, Fam Zheng <fam@...hon.net>,
        Jens Axboe <axboe@...com>, Sagi Grimberg <sagi@...mberg.me>,
        kvm@...r.kernel.org, Wolfram Sang <wsa@...-dreams.de>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Liang Cunming <cunming.liang@...el.com>,
        Nicolas Ferre <nicolas.ferre@...rochip.com>,
        linux-kernel@...r.kernel.org,
        Liu Changpeng <changpeng.liu@...el.com>,
        Keith Busch <keith.busch@...el.com>,
        Kirti Wankhede <kwankhede@...dia.com>,
        Christoph Hellwig <hch@....de>,
        Paolo Bonzini <pbonzini@...hat.com>,
        Mauro Carvalho Chehab <mchehab+samsung@...nel.org>,
        John Ferlan <jferlan@...hat.com>,
        "Paul E . McKenney" <paulmck@...ux.ibm.com>,
        Amnon Ilan <ailan@...hat.com>,
        "David S . Miller" <davem@...emloft.net>
Subject: Re: [PATCH 0/9] RFC: NVME VFIO mediated device

On Wed, 20 Mar 2019 18:42:02 +0200
Maxim Levitsky <mlevitsk@...hat.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