Received: by 2002:a05:6a10:22f:0:0:0:0 with SMTP id 15csp327678pxk; Wed, 23 Sep 2020 04:29:44 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwAzKiXFNA3eICQ9hoXFpCECatNlni8MrwnSHtPUDWN9HJSn7tXH77/+XOgxAfI9FsQgALp X-Received: by 2002:a17:906:6805:: with SMTP id k5mr9299976ejr.397.1600860584547; Wed, 23 Sep 2020 04:29:44 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1600860584; cv=none; d=google.com; s=arc-20160816; b=S8qxzeUbOYsweqdiABZfCXxAvjOrQRhwXjcXFUJmbwjdleCnbBOV1+e9pP4tuQ+7Vx UGHmcH4G6efPv/hVS8OGM++tr6zwkOes/n2PjcLuwVLtgT/l8Nf2cOHZ7q5W910Po6WY 7cE7V+waY1h9qPELpKITEgRjsKz2W1Mmm+vJHZI2pLv+AVM64ZTzHDW4gFS7WPw78Dl0 oEHHFNymPTpFpq7iWl3Yx5PBJnzrQkN4EnUNNX4WuwJKmJdehgiKyVE1oUucteiyJVtq bFulApCPPMQZ3xNw2zRjCyDrvlI9BqjnTZhjk6nZy4u0sY6UrX9StCx5QvAG3og6vB62 pV1Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:content-language :in-reply-to:mime-version:user-agent:date:message-id:from:references :to:subject; bh=FcU7V8JZLVRMdQOmFxDXCZ03MrFf5Sv8JYcLYRRVoMQ=; b=Ew02M3m9RCZx4eQO5cB8trVAk41Hd+cspRc9QfMBGYIjQ/ibRfEffrPmt24JQuinj5 nRAI/dI/Y0Auqw7YVIXkjKSF88VEpZi2TssRpQwCX4fSPq3kcSAReewTE3SC3sXN3tJX fdsah6ErMRiABvwtIvhH5mBfQ1GQl/Xb3JdUbeBrY2JEilPipqsO3iJbqGfu5+r0P1gt 67EvbO2T4sjSnB4bKp6SE1Mpp+4hH+s9EsS8Eq8EyWeHTtpW0suwsj2J0YEyH8We9eEN PZ86Na8R9SmfFoMIHCmUzDmAft4tzaSGmsTBJJAhIGSatmty+tfvWikD5icvaY8Uc/A1 CWoQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id ga23si11975241ejb.691.2020.09.23.04.29.20; Wed, 23 Sep 2020 04:29:44 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726581AbgIWL2A (ORCPT + 99 others); Wed, 23 Sep 2020 07:28:00 -0400 Received: from szxga07-in.huawei.com ([45.249.212.35]:59998 "EHLO huawei.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726332AbgIWL2A (ORCPT ); Wed, 23 Sep 2020 07:28:00 -0400 Received: from DGGEMS402-HUB.china.huawei.com (unknown [172.30.72.60]) by Forcepoint Email with ESMTP id E9297626864E5F774AE4; Wed, 23 Sep 2020 19:27:55 +0800 (CST) Received: from [10.174.185.226] (10.174.185.226) by DGGEMS402-HUB.china.huawei.com (10.3.19.202) with Microsoft SMTP Server id 14.3.487.0; Wed, 23 Sep 2020 19:27:47 +0800 Subject: Re: [PATCH v10 01/11] vfio: VFIO_IOMMU_SET_PASID_TABLE To: Eric Auger , , , , , , , , , , References: <20200320161911.27494-1-eric.auger@redhat.com> <20200320161911.27494-2-eric.auger@redhat.com> From: Zenghui Yu Message-ID: <2fba23af-9cd7-147d-6202-01c13fff92e5@huawei.com> Date: Wed, 23 Sep 2020 19:27:46 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: <20200320161911.27494-2-eric.auger@redhat.com> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Originating-IP: [10.174.185.226] X-CFilter-Loop: Reflected Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Eric, On 2020/3/21 0:19, Eric Auger wrote: > From: "Liu, Yi L" > > This patch adds an VFIO_IOMMU_SET_PASID_TABLE ioctl > which aims to pass the virtual iommu guest configuration > to the host. This latter takes the form of the so-called > PASID table. > > Signed-off-by: Jacob Pan > Signed-off-by: Liu, Yi L > Signed-off-by: Eric Auger [...] > diff --git a/drivers/vfio/vfio_iommu_type1.c b/drivers/vfio/vfio_iommu_type1.c > index a177bf2c6683..bfacbd876ee1 100644 > --- a/drivers/vfio/vfio_iommu_type1.c > +++ b/drivers/vfio/vfio_iommu_type1.c > @@ -2172,6 +2172,43 @@ static int vfio_iommu_iova_build_caps(struct vfio_iommu *iommu, > return ret; > } > > +static void > +vfio_detach_pasid_table(struct vfio_iommu *iommu) > +{ > + struct vfio_domain *d; > + > + mutex_lock(&iommu->lock); > + > + list_for_each_entry(d, &iommu->domain_list, next) { > + iommu_detach_pasid_table(d->domain); > + } > + mutex_unlock(&iommu->lock); > +} > + > +static int > +vfio_attach_pasid_table(struct vfio_iommu *iommu, > + struct vfio_iommu_type1_set_pasid_table *ustruct) > +{ > + struct vfio_domain *d; > + int ret = 0; > + > + mutex_lock(&iommu->lock); > + > + list_for_each_entry(d, &iommu->domain_list, next) { > + ret = iommu_attach_pasid_table(d->domain, &ustruct->config); > + if (ret) > + goto unwind; > + } > + goto unlock; > +unwind: > + list_for_each_entry_continue_reverse(d, &iommu->domain_list, next) { > + iommu_detach_pasid_table(d->domain); > + } > +unlock: > + mutex_unlock(&iommu->lock); > + return ret; > +} > + > static long vfio_iommu_type1_ioctl(void *iommu_data, > unsigned int cmd, unsigned long arg) > { > @@ -2276,6 +2313,25 @@ static long vfio_iommu_type1_ioctl(void *iommu_data, > > return copy_to_user((void __user *)arg, &unmap, minsz) ? > -EFAULT : 0; > + } else if (cmd == VFIO_IOMMU_SET_PASID_TABLE) { > + struct vfio_iommu_type1_set_pasid_table ustruct; > + > + minsz = offsetofend(struct vfio_iommu_type1_set_pasid_table, > + config); > + > + if (copy_from_user(&ustruct, (void __user *)arg, minsz)) > + return -EFAULT; > + > + if (ustruct.argsz < minsz) > + return -EINVAL; > + > + if (ustruct.flags & VFIO_PASID_TABLE_FLAG_SET) > + return vfio_attach_pasid_table(iommu, &ustruct); > + else if (ustruct.flags & VFIO_PASID_TABLE_FLAG_UNSET) { > + vfio_detach_pasid_table(iommu); > + return 0; > + } else > + return -EINVAL; Nit: What if user-space blindly set both flags? Should we check that only one flag is allowed to be set at this stage, and return error otherwise? Besides, before going through the whole series [1][2], I'd like to know if this is the latest version of your Nested-Stage-Setup work in case I had missed something. [1] https://lore.kernel.org/r/20200320161911.27494-1-eric.auger@redhat.com [2] https://lore.kernel.org/r/20200414150607.28488-1-eric.auger@redhat.com Thanks, Zenghui