From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.3 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE, SPF_PASS,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 13D03C636CA for ; Fri, 16 Jul 2021 12:20:29 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id F10E6613CF for ; Fri, 16 Jul 2021 12:20:28 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S238468AbhGPMXW (ORCPT ); Fri, 16 Jul 2021 08:23:22 -0400 Received: from szxga02-in.huawei.com ([45.249.212.188]:11436 "EHLO szxga02-in.huawei.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232024AbhGPMXS (ORCPT ); Fri, 16 Jul 2021 08:23:18 -0400 Received: from dggemv704-chm.china.huawei.com (unknown [172.30.72.55]) by szxga02-in.huawei.com (SkyGuard) with ESMTP id 4GR9GR0bgyzcdbs; Fri, 16 Jul 2021 20:17:03 +0800 (CST) Received: from dggpemm500022.china.huawei.com (7.185.36.162) by dggemv704-chm.china.huawei.com (10.3.19.47) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2176.2; Fri, 16 Jul 2021 20:20:22 +0800 Received: from [10.174.185.67] (10.174.185.67) by dggpemm500022.china.huawei.com (7.185.36.162) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2176.2; Fri, 16 Jul 2021 20:20:21 +0800 Subject: Re: [RFC v2] /dev/iommu uAPI proposal To: "Tian, Kevin" CC: Jason Gunthorpe , "Raj, Ashok" , "Alex Williamson (alex.williamson@redhat.com)" , Jean-Philippe Brucker , David Gibson , Jason Wang , "parav@mellanox.com" , "Enrico Weigelt, metux IT consult" , Paolo Bonzini , Joerg Roedel , Eric Auger , Jonathan Corbet , "Liu, Yi L" , "Wu, Hao" , "Jiang, Dave" , Jacob Pan , Kirti Wankhede , "Robin Murphy" , "kvm@vger.kernel.org" , "iommu@lists.linux-foundation.org" , "David Woodhouse" , LKML , "Lu Baolu" , "wanghaibin.wang@huawei.com" References: <20210715124813.GC543781@nvidia.com> <20210715135757.GC590891@otc-nc-03> <20210715152325.GF543781@nvidia.com> <20210715162141.GA593686@otc-nc-03> <20210715171826.GG543781@nvidia.com> <20210715174836.GB593686@otc-nc-03> <20210715175336.GH543781@nvidia.com> <20210715180545.GD593686@otc-nc-03> <20210715181327.GI543781@nvidia.com> From: Shenming Lu Message-ID: <013e240d-f627-3565-aba1-71b2d6f514b4@huawei.com> Date: Fri, 16 Jul 2021 20:20:20 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.2.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8" Content-Language: en-US Content-Transfer-Encoding: 7bit X-Originating-IP: [10.174.185.67] X-ClientProxiedBy: dggems706-chm.china.huawei.com (10.3.19.183) To dggpemm500022.china.huawei.com (7.185.36.162) X-CFilter-Loop: Reflected Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2021/7/16 9:20, Tian, Kevin wrote: > To summarize, for vIOMMU we can work with the spec owner to > define a proper interface to feedback such restriction into the guest > if necessary. For the kernel part, it's clear that IOMMU fd should > disallow two devices attached to a single [RID] or [RID, PASID] slot > in the first place. > > Then the next question is how to communicate such restriction > to the userspace. It sounds like a group, but different in concept. > An iommu group describes the minimal isolation boundary thus all > devices in the group can be only assigned to a single user. But this > case is opposite - the two mdevs (both support ENQCMD submission) > with the same parent have problem when assigned to a single VM > (in this case vPASID is vm-wide translated thus a same pPASID will be > used cross both mdevs) while they instead work pretty well when > assigned to different VMs (completely different vPASID spaces thus > different pPASIDs). > > One thought is to have vfio device driver deal with it. In this proposal > it is the vfio device driver to define the PASID virtualization policy and > report it to userspace via VFIO_DEVICE_GET_INFO. The driver understands > the restriction thus could just hide the vPASID capability when the user > calls GET_INFO on the 2nd mdev in above scenario. In this way the > user even doesn't need to know such restriction at all and both mdevs > can be assigned to a single VM w/o any problem. > The restriction only probably happens when two mdevs are assigned to one VM, how could the vfio device driver get to know this info to accurately hide the vPASID capability for the 2nd mdev when VFIO_DEVICE_GET_INFO? There is no need to do this in other cases. Thanks, Shenming From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.3 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 5CCBAC636CB for ; Fri, 16 Jul 2021 12:20:30 +0000 (UTC) Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id E3CB4613E9 for ; Fri, 16 Jul 2021 12:20:29 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org E3CB4613E9 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=huawei.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=iommu-bounces@lists.linux-foundation.org Received: from localhost (localhost [127.0.0.1]) by smtp1.osuosl.org (Postfix) with ESMTP id B72D18444A; Fri, 16 Jul 2021 12:20:29 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from smtp1.osuosl.org ([127.0.0.1]) by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IV3B2TMe1xTD; Fri, 16 Jul 2021 12:20:29 +0000 (UTC) Received: from lists.linuxfoundation.org (lf-lists.osuosl.org [IPv6:2605:bc80:3010:104::8cd3:938]) by smtp1.osuosl.org (Postfix) with ESMTPS id B134884316; Fri, 16 Jul 2021 12:20:28 +0000 (UTC) Received: from lf-lists.osuosl.org (localhost [127.0.0.1]) by lists.linuxfoundation.org (Postfix) with ESMTP id 8BABFC0010; Fri, 16 Jul 2021 12:20:28 +0000 (UTC) Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138]) by lists.linuxfoundation.org (Postfix) with ESMTP id E5A11C000E for ; Fri, 16 Jul 2021 12:20:27 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp1.osuosl.org (Postfix) with ESMTP id D3DA78443C for ; Fri, 16 Jul 2021 12:20:27 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from smtp1.osuosl.org ([127.0.0.1]) by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UyOQ38wWzOb6 for ; Fri, 16 Jul 2021 12:20:26 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0 Received: from szxga02-in.huawei.com (szxga02-in.huawei.com [45.249.212.188]) by smtp1.osuosl.org (Postfix) with ESMTPS id 3385484316 for ; Fri, 16 Jul 2021 12:20:26 +0000 (UTC) Received: from dggemv704-chm.china.huawei.com (unknown [172.30.72.55]) by szxga02-in.huawei.com (SkyGuard) with ESMTP id 4GR9GR0bgyzcdbs; Fri, 16 Jul 2021 20:17:03 +0800 (CST) Received: from dggpemm500022.china.huawei.com (7.185.36.162) by dggemv704-chm.china.huawei.com (10.3.19.47) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2176.2; Fri, 16 Jul 2021 20:20:22 +0800 Received: from [10.174.185.67] (10.174.185.67) by dggpemm500022.china.huawei.com (7.185.36.162) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2176.2; Fri, 16 Jul 2021 20:20:21 +0800 Subject: Re: [RFC v2] /dev/iommu uAPI proposal To: "Tian, Kevin" References: <20210715124813.GC543781@nvidia.com> <20210715135757.GC590891@otc-nc-03> <20210715152325.GF543781@nvidia.com> <20210715162141.GA593686@otc-nc-03> <20210715171826.GG543781@nvidia.com> <20210715174836.GB593686@otc-nc-03> <20210715175336.GH543781@nvidia.com> <20210715180545.GD593686@otc-nc-03> <20210715181327.GI543781@nvidia.com> From: Shenming Lu Message-ID: <013e240d-f627-3565-aba1-71b2d6f514b4@huawei.com> Date: Fri, 16 Jul 2021 20:20:20 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.2.2 MIME-Version: 1.0 In-Reply-To: Content-Language: en-US X-Originating-IP: [10.174.185.67] X-ClientProxiedBy: dggems706-chm.china.huawei.com (10.3.19.183) To dggpemm500022.china.huawei.com (7.185.36.162) X-CFilter-Loop: Reflected Cc: "kvm@vger.kernel.org" , Jason Wang , Kirti Wankhede , Jean-Philippe Brucker , "Jiang, Dave" , "Raj, Ashok" , Jonathan Corbet , Jason Gunthorpe , "wanghaibin.wang@huawei.com" , "parav@mellanox.com" , "Alex Williamson \(alex.williamson@redhat.com\)" , "Enrico Weigelt, metux IT consult" , David Gibson , Robin Murphy , LKML , "iommu@lists.linux-foundation.org" , Paolo Bonzini , David Woodhouse X-BeenThere: iommu@lists.linux-foundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Development issues for Linux IOMMU support List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: iommu-bounces@lists.linux-foundation.org Sender: "iommu" On 2021/7/16 9:20, Tian, Kevin wrote: > To summarize, for vIOMMU we can work with the spec owner to > define a proper interface to feedback such restriction into the guest > if necessary. For the kernel part, it's clear that IOMMU fd should > disallow two devices attached to a single [RID] or [RID, PASID] slot > in the first place. > > Then the next question is how to communicate such restriction > to the userspace. It sounds like a group, but different in concept. > An iommu group describes the minimal isolation boundary thus all > devices in the group can be only assigned to a single user. But this > case is opposite - the two mdevs (both support ENQCMD submission) > with the same parent have problem when assigned to a single VM > (in this case vPASID is vm-wide translated thus a same pPASID will be > used cross both mdevs) while they instead work pretty well when > assigned to different VMs (completely different vPASID spaces thus > different pPASIDs). > > One thought is to have vfio device driver deal with it. In this proposal > it is the vfio device driver to define the PASID virtualization policy and > report it to userspace via VFIO_DEVICE_GET_INFO. The driver understands > the restriction thus could just hide the vPASID capability when the user > calls GET_INFO on the 2nd mdev in above scenario. In this way the > user even doesn't need to know such restriction at all and both mdevs > can be assigned to a single VM w/o any problem. > The restriction only probably happens when two mdevs are assigned to one VM, how could the vfio device driver get to know this info to accurately hide the vPASID capability for the 2nd mdev when VFIO_DEVICE_GET_INFO? There is no need to do this in other cases. Thanks, Shenming _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu