linux-kernel - Re: [PATCH v4] vfio/type1: Adopt fast IOTLB flush interface when unmap IOVAs

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] [day] [month] [year] [list]

Message-ID: <0fd4610a-c3ec-90f9-2d87-a7c2dd78193d@amd.com>
Date:   Thu, 1 Feb 2018 12:11:19 +0700
From:   Suravee Suthikulpanit <suravee.suthikulpanit@....com>
To:     kvm@...r.kernel.org, linux-kernel@...r.kernel.org
Cc:     alex.williamson@...hat.com, joro@...tes.org, jroedel@...e.de
Subject: Re: [PATCH v4] vfio/type1: Adopt fast IOTLB flush interface when
 unmap IOVAs

Alex,

On 1/31/18 4:45 PM, Suravee Suthikulpanit wrote:
> Currently, VFIO IOMMU type1 unmaps IOVA pages synchronously, which requires
> IOTLB flush for every IOVA unmap. This results in a large number of IOTLB
> flushes during initialization of pass-through devices.
> 
> This can be avoided using the asynchronous (fast) IOTLB flush interface.
> 
> Cc: Alex Williamson<alex.williamson@...hat.com>
> Cc: Joerg Roedel<joro@...tes.org>
> Signed-off-by: Suravee Suthikulpanit<suravee.suthikulpanit@....com>
> ---
> 
> Changes from v3 (https://lkml.org/lkml/2018/1/21/244)
>   * Refactor the code to unmap_unpin_fast() and unmap_unpin_slow()
>     to improve code readability.
>   * Fix logic in vfio_unmap_unpin() to fallback to unmap_unpin_slow()
>     only for the failing iova unmapping, and continue the next unmapping
>     with the unmap_unpin_fast(). (per Alex)
>   * Fix error handling in case of failing to do fast unmapping to warn
>     only once.
>   * Remove reference to GPU in the commit message.

Please ignore v4. I found an issue in error handling logic. Also, I need to change
the return value back to size_t (as this was in a discussed in a separate thread).

Sorry for confusion. I'll clean up and send out v5.

Thanks,
Suravee