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]

Date:   Sat, 18 Jun 2022 23:41:30 -0700
From:   Nicolin Chen <nicolinc@...dia.com>
To:     Christoph Hellwig <hch@...radead.org>, <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 Sat, Jun 18, 2022 at 11:18:17PM -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.  
> > 
> > Would you mind explaining the use case for pinning memory that
> > isn't page backed? And do we have such use case so far?
> 
> Sorry, I should have deleted that sentence.  I wrote it before spending
> some more time to dig through the code and all the locked memory has
> page backing.  There just seem to be a lot of checks left inbetween
> if a pfn is page backed, mostly due to the pfn based calling convetions.

OK. We'd be safe to move on then. Thanks for the clarification.

> > I can do that. I tried once, but there were just too much changes
> > inside type1 code that felt like a chain reaction. If we plan to
> > eventually replace with IOMMUFD implementations, these changes in
> > type1 might not be necessary, I thought.
> 
> To make sure we keep full compatibility I suspect the final iommufd
> implementation has to be gradutally created from the existing code
> anyway.

Hmm. I think Jason can give some insight. Meanwhile, I will try
to add a patch to type1 code, in case we'd end up with what you
suspected.