Received: by 2002:a05:6a11:4021:0:0:0:0 with SMTP id ky33csp557986pxb; Wed, 29 Sep 2021 05:10:11 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwQmnAfeZSxeKnysFuw4o6hLJvcwU6dm4HgpMEiuWCPz9B8NWguFR/xOTKA2xLddmku4y3i X-Received: by 2002:a65:6a0f:: with SMTP id m15mr9265976pgu.298.1632917411633; Wed, 29 Sep 2021 05:10:11 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1632917411; cv=none; d=google.com; s=arc-20160816; b=SCBrBT3rPzk0V248vN4cb7Qv2T36sVA1EyPBNR2FhEeBGHKxnJnqABLIIFAdv94yFF 6XRiYWwd7mFKeTPQWCXLwo03ektN8Ee7Yds9u4myUPoYMJTCLU73/x1aKwYUu3e+5lSM qH73x67FJBXDE3ylFMl6RXpxEaqL7RklUuIwlW8I02w5JUGQ2av+QaCdtITukSI7gS+Q 1FvA9FjuhPdLAXX8fCbXL65PqkKbyBcGMEdCIBwh7HhaaNmUfTALA7pe0lQ+CBnRd05D ekg9fj3oWRkA6j0IAzHiuEyMRpr3cvMnBEXAJULgJPwMFywBlyPgEWOEHz6U/2gVxH40 Cn4g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=iyf25v6ccH6pcjIZwVpHGzum+qBnQrA4I/SRUwhCtyo=; b=L6jY4SOR6phzOb2K2842gWKtIRUonLdBLXyoCZJeUkomMNhNs+nHcGDcXDx81p4xGo bT8ayEdN9ixfH4Gc+lzDq3Opu17CP74Z2MZG5R37QM1yLK3/DbvbOhBhIj7tkYcmHH1T kZKMEk//XTPq1CT83/GXe9OAuP/qIwO08w9Wy6clWTgIBaU+HTC8e26OFdnD5i5wEO1D 2/vvqQXtEmHfr+yn4FOtmQieLqtU8Aey8ZcA1szz6L6w0MBgpKblILEbNdVaUsBzC2hd Q41mIY8QV25dJGpPeGRRai0Gpai78ZcJJwpQkFqQyqv89qbCNVrLYZJUzM6wB440sGBk p2FQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=T8zIfXge; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id j3si2555814pgq.501.2021.09.29.05.09.35; Wed, 29 Sep 2021 05:10:11 -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; dkim=pass header.i=@linaro.org header.s=google header.b=T8zIfXge; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1343540AbhI2MKG (ORCPT + 99 others); Wed, 29 Sep 2021 08:10:06 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:38782 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S244801AbhI2MKC (ORCPT ); Wed, 29 Sep 2021 08:10:02 -0400 Received: from mail-wr1-x42a.google.com (mail-wr1-x42a.google.com [IPv6:2a00:1450:4864:20::42a]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A3941C06161C for ; Wed, 29 Sep 2021 05:08:20 -0700 (PDT) Received: by mail-wr1-x42a.google.com with SMTP id x20so3835030wrg.10 for ; Wed, 29 Sep 2021 05:08:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=iyf25v6ccH6pcjIZwVpHGzum+qBnQrA4I/SRUwhCtyo=; b=T8zIfXgeaPrEEdWOzvwNTpI4xwVcEDwynYkx5VAeTJ7rV02Hb29+luk4+do/R4tlYM WHxuynFzb2jIPamYr5joLM1NbqFkLNQ0oXsf3Cq1vMqmpxFgE+EvcDk2f7Ua7SsG6agX W5014cw1JRdT8BGfZPqE1nw7yLc3PKzbdYCmg8bHyHxkqJIC7qlZAsC3mMiRPMmQ1Q6B /n70Y9v5VrEqVNrQ4oRHi2obyy5TfM1Zz0e7jjuVuSsi1WBQAwvr1/X1uZYPwnsN9sCC VxAv5M5BafhvPiWSTATDETbfoIlTsGYDjGkhoPQ0oWwEIQbt2gGpFvIj8HH9WyqbKgW3 VCtg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=iyf25v6ccH6pcjIZwVpHGzum+qBnQrA4I/SRUwhCtyo=; b=5Io2vDsrUD8+GXijCSuM2559xjhFVKRXzwpygN/zMaNFCAEEYgnIaYvS5NWV+ZY0w0 XMZapvyPb4Wad0ABWXHl3+OLWZPkhlEkhc9xvncbZ4nBZdtWyMKhozhC3hYGFf1oH/+N gX4iUQw5DE5w3LVIgL4lN9bHLuG20jRn0jKFGclhVyxg3VgSsJDWCxJ1BQ0zx7/U9iuq z44KYKFcxr+lLlCGldHU+7tNzxWfKpIcMyA5tzQSgStNeT6DQQ8P4rPy+whq68Prj+N6 k7XwecVznfQ3NBBZENCDG5Tt7q9KxUHYYYjBAjhD81sdqME8q67jB9Jo2EFAV5gBqgar YHJg== X-Gm-Message-State: AOAM531zowYIrQWYhxHJad3PaXu0yQGpgtpvGulqdyGLsC3C3R+Pt6Vt PqQJTsge0aIWB1fbslLxejGTDw== X-Received: by 2002:adf:fe8c:: with SMTP id l12mr6440976wrr.210.1632917299207; Wed, 29 Sep 2021 05:08:19 -0700 (PDT) Received: from myrica (cpc92880-cmbg19-2-0-cust679.5-4.cable.virginm.net. [82.27.106.168]) by smtp.gmail.com with ESMTPSA id i27sm1502404wmb.40.2021.09.29.05.08.17 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 29 Sep 2021 05:08:18 -0700 (PDT) Date: Wed, 29 Sep 2021 13:07:56 +0100 From: Jean-Philippe Brucker To: "Liu, Yi L" Cc: "alex.williamson@redhat.com" , "jgg@nvidia.com" , "hch@lst.de" , "jasowang@redhat.com" , "joro@8bytes.org" , "Tian, Kevin" , "parav@mellanox.com" , "lkml@metux.net" , "pbonzini@redhat.com" , "lushenming@huawei.com" , "eric.auger@redhat.com" , "corbet@lwn.net" , "Raj, Ashok" , "yi.l.liu@linux.intel.com" , "Tian, Jun J" , "Wu, Hao" , "Jiang, Dave" , "jacob.jun.pan@linux.intel.com" , "kwankhede@nvidia.com" , "robin.murphy@arm.com" , "kvm@vger.kernel.org" , "iommu@lists.linux-foundation.org" , "dwmw2@infradead.org" , "linux-kernel@vger.kernel.org" , "baolu.lu@linux.intel.com" , "david@gibson.dropbear.id.au" , "nicolinc@nvidia.com" Subject: Re: [RFC 17/20] iommu/iommufd: Report iova range to userspace Message-ID: References: <20210919063848.1476776-1-yi.l.liu@intel.com> <20210919063848.1476776-18-yi.l.liu@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Sep 29, 2021 at 10:44:01AM +0000, Liu, Yi L wrote: > > From: Jean-Philippe Brucker > > Sent: Wednesday, September 22, 2021 10:49 PM > > > > On Sun, Sep 19, 2021 at 02:38:45PM +0800, Liu Yi L wrote: > > > [HACK. will fix in v2] > > > > > > IOVA range is critical info for userspace to manage DMA for an I/O address > > > space. This patch reports the valid iova range info of a given device. > > > > > > Due to aforementioned hack, this info comes from the hacked vfio type1 > > > driver. To follow the same format in vfio, we also introduce a cap chain > > > format in IOMMU_DEVICE_GET_INFO to carry the iova range info. > > [...] > > > diff --git a/include/uapi/linux/iommu.h b/include/uapi/linux/iommu.h > > > index 49731be71213..f408ad3c8ade 100644 > > > --- a/include/uapi/linux/iommu.h > > > +++ b/include/uapi/linux/iommu.h > > > @@ -68,6 +68,7 @@ > > > * +---------------+------------+ > > > * ... > > > * @addr_width: the address width of supported I/O address spaces. > > > + * @cap_offset: Offset within info struct of first cap > > > * > > > * Availability: after device is bound to iommufd > > > */ > > > @@ -77,9 +78,11 @@ struct iommu_device_info { > > > #define IOMMU_DEVICE_INFO_ENFORCE_SNOOP (1 << 0) /* IOMMU > > enforced snoop */ > > > #define IOMMU_DEVICE_INFO_PGSIZES (1 << 1) /* supported page > > sizes */ > > > #define IOMMU_DEVICE_INFO_ADDR_WIDTH (1 << 2) /* > > addr_wdith field valid */ > > > +#define IOMMU_DEVICE_INFO_CAPS (1 << 3) /* info > > supports cap chain */ > > > __u64 dev_cookie; > > > __u64 pgsize_bitmap; > > > __u32 addr_width; > > > + __u32 cap_offset; > > > > We can also add vendor-specific page table and PASID table properties as > > capabilities, otherwise we'll need giant unions in the iommu_device_info > > struct. That made me wonder whether pgsize and addr_width should also > > be > > separate capabilities for consistency, but this way might be good enough. > > There won't be many more generic capabilities. I have "output address > > width" > > what do you mean by "output address width"? Is it the output address > of stage-1 translation? Yes, so the guest knows the size of GPA it can write into the page table. For Arm SMMU the GPA size is determined by both the SMMU implementation and the host kernel configuration. But maybe that could also be vendor-specific, if other architectures don't need to communicate it. > > > and "PASID width", the rest is specific to Arm and SMMU table > > formats. > > When coming to nested translation support, the stage-1 related info are > likely to be vendor-specific, and will be reported in cap chain. Agreed Thanks, Jean