From patchwork Wed Jun 26 15:12:42 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Shameerali Kolothum Thodi X-Patchwork-Id: 11018077 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id D54336C5 for ; Wed, 26 Jun 2019 15:13:46 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id BFC1F28553 for ; Wed, 26 Jun 2019 15:13:46 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id B406F2897F; Wed, 26 Jun 2019 15:13:46 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-7.9 required=2.0 tests=BAYES_00,MAILING_LIST_MULTI, RCVD_IN_DNSWL_HI autolearn=ham version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 3E75928553 for ; Wed, 26 Jun 2019 15:13:45 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728092AbfFZPNl (ORCPT ); Wed, 26 Jun 2019 11:13:41 -0400 Received: from szxga04-in.huawei.com ([45.249.212.190]:19082 "EHLO huawei.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726157AbfFZPNk (ORCPT ); Wed, 26 Jun 2019 11:13:40 -0400 Received: from DGGEMS406-HUB.china.huawei.com (unknown [172.30.72.59]) by Forcepoint Email with ESMTP id 3E7BB3290C7B21BAE097; Wed, 26 Jun 2019 23:13:37 +0800 (CST) Received: from S00345302A-PC.china.huawei.com (10.202.227.237) by DGGEMS406-HUB.china.huawei.com (10.3.19.206) with Microsoft SMTP Server id 14.3.439.0; Wed, 26 Jun 2019 23:13:29 +0800 From: Shameer Kolothum To: , , CC: , , , , , , , Shameer Kolothum Subject: [PATCH v7 0/6] vfio/type1: Add support for valid iova list management Date: Wed, 26 Jun 2019 16:12:42 +0100 Message-ID: <20190626151248.11776-1-shameerali.kolothum.thodi@huawei.com> X-Mailer: git-send-email 2.12.0.windows.1 MIME-Version: 1.0 X-Originating-IP: [10.202.227.237] X-CFilter-Loop: Reflected Sender: kvm-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: kvm@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP This is to revive this series which almost made to 4.18 but got dropped as Alex found an issue[1] with IGD and USB devices RMRR region being reported as reserved regions. Thanks to Eric for his work here[2]. It provides a way to exclude these regions while reporting the valid iova regions and this respin make use of that. Please note that I don't have a platform to verify the reported RMRR issue and appreciate testing on those platforms. Thanks, Shameer [1] https://lkml.org/lkml/2018/6/5/760 [2] https://lore.kernel.org/patchwork/cover/1083072/ v6-->v7 -Rebased to 5.2-rc6 + Eric's patches -Added logic to exclude IOMMU_RESV_DIRECT_RELAXABLE reserved memory region type(patch #2). -Dropped patch #4 of v6 as it is already part of mainline. -Addressed "container with only an mdev device will have an empty list" case(patches 4/6 & 5/6 - Suggested by Alex) Old ---- This series introduces an iova list associated with a vfio iommu. The list is kept updated taking care of iommu apertures, and reserved regions. Also this series adds checks for any conflict with existing dma mappings whenever a new device group is attached to the domain. User-space can retrieve valid iova ranges using VFIO_IOMMU_GET_INFO ioctl capability chains. Any dma map request outside the valid iova range will be rejected. v5 --> v6 -Rebased to 4.17-rc1 -Changed the ordering such that previous patch#7 "iommu/dma: Move PCI window region reservation back...") is now patch #4. This will avoid any bisection issues pointed out by Alex. -Added Robins's Reviewed-by tag for patch#4 v4 --> v5 Rebased to next-20180315. -Incorporated the corner case bug fix suggested by Alex to patch #5. -Based on suggestions by Alex and Robin, added patch#7. This moves the PCI window reservation back in to DMA specific path. This is to fix the issue reported by Eric[1]. v3 --> v4 Addressed comments received for v3. -dma_addr_t instead of phys_addr_t -LIST_HEAD() usage. -Free up iova_copy list in case of error. -updated logic in filling the iova caps info(patch #5) RFCv2 --> v3 Removed RFC tag. Addressed comments from Alex and Eric: - Added comments to make iova list management logic more clear. - Use of iova list copy so that original is not altered in case of failure. RFCv1 --> RFCv2 Addressed comments from Alex: -Introduced IOVA list management and added checks for conflicts with existing dma map entries during attach/detach. Shameer Kolothum (6): vfio/type1: Introduce iova list and add iommu aperture validity check vfio/type1: Check reserve region conflict and update iova list vfio/type1: Update iova list on detach vfio/type1: check dma map request is within a valid iova range vfio/type1: Add IOVA range capability support vfio/type1: remove duplicate retrieval of reserved regions drivers/vfio/vfio_iommu_type1.c | 510 +++++++++++++++++++++++++++++++- include/uapi/linux/vfio.h | 23 ++ 2 files changed, 520 insertions(+), 13 deletions(-)