linux-kernel - Re: [RFT][PATCH v1 6/6] vfio: Replace phys_pfn with phys_page for vfio_pin

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <YrI8eYsXemPgNBa2@Asurada-Nvidia>
Date:   Tue, 21 Jun 2022 14:47:37 -0700
From:   Nicolin Chen <nicolinc@...dia.com>
To:     Christoph Hellwig <hch@...radead.org>,
        Jason Gunthorpe <jgg@...dia.com>
CC:     <kwankhede@...dia.com>, <corbet@....net>, <hca@...ux.ibm.com>,
        <gor@...ux.ibm.com>, <agordeev@...ux.ibm.com>,
        <borntraeger@...ux.ibm.com>, <svens@...ux.ibm.com>,
        <zhenyuw@...ux.intel.com>, <zhi.a.wang@...el.com>,
        <jani.nikula@...ux.intel.com>, <joonas.lahtinen@...ux.intel.com>,
        <rodrigo.vivi@...el.com>, <tvrtko.ursulin@...ux.intel.com>,
        <airlied@...ux.ie>, <daniel@...ll.ch>, <farman@...ux.ibm.com>,
        <mjrosato@...ux.ibm.com>, <pasic@...ux.ibm.com>,
        <vneethv@...ux.ibm.com>, <oberpar@...ux.ibm.com>,
        <freude@...ux.ibm.com>, <akrowiak@...ux.ibm.com>,
        <jjherne@...ux.ibm.com>, <alex.williamson@...hat.com>,
        <cohuck@...hat.com>, <kevin.tian@...el.com>,
        <jchrist@...ux.ibm.com>, <kvm@...r.kernel.org>,
        <linux-doc@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
        <linux-s390@...r.kernel.org>,
        <intel-gvt-dev@...ts.freedesktop.org>,
        <intel-gfx@...ts.freedesktop.org>,
        <dri-devel@...ts.freedesktop.org>
Subject: Re: [RFT][PATCH v1 6/6] vfio: Replace phys_pfn with phys_page for
 vfio_pin_pages()

On Mon, Jun 20, 2022 at 12:36:28PM -0300, Jason Gunthorpe wrote:
> On Sun, Jun 19, 2022 at 11:37:47PM -0700, Christoph Hellwig wrote:
> > On Sun, Jun 19, 2022 at 10:51:47PM -0700, Christoph Hellwig wrote:
> > > On Mon, Jun 20, 2022 at 12:00:46AM -0300, Jason Gunthorpe wrote:
> > > > On Fri, Jun 17, 2022 at 01:54:05AM -0700, Christoph Hellwig wrote:
> > > > > There is a bunch of code an comments in the iommu type1 code that
> > > > > suggest we can pin memory that is not page backed.  
> > > > 
> > > > AFAIK you can.. The whole follow_pte() mechanism allows raw PFNs to be
> > > > loaded into the type1 maps and the pin API will happily return
> > > > them. This happens in almost every qemu scenario because PCI MMIO BAR
> > > > memory ends up routed down this path.
> > > 
> > > Indeed, my read wasn't deep enough.  Which means that we can't change
> > > the ->pin_pages interface to return a struct pages array, as we don't
> > > have one for those.
> > 
> > Actually.  gvt requires a struct page, and both s390 seem to require
> > normal non-I/O, non-remapped kernel pointers.  So I think for the
> > vfio_pin_pages we can assume that we only want page backed memory and
> > remove the follow_fault_pfn case entirely.   But we'll probably have
> > to keep it for the vfio_iommu_replay case that is not tied to
> > emulated IOMMU drivers.
> 
> Right, that is my thinking - since all drivers actually need a struct
> page we should have the API return a working struct page and have the
> VFIO layer isolate the non-struct page stuff so it never leaks out of
> this API.
> 
> This nicely fixes the various problems in all the drivers if io memory
> comes down this path.
> 
> It is also why doing too much surgery deeper into type 1 probably
> isn't too worthwhile as it still needs raw pfns in its data
> structures for iommu modes.

Christoph, do you agree with Jason's remark on not doing too much
surgery into type1 code? Or do you still want this series to change
type1 like removing follow_fault_pfn() that you mentioned above?