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;
From:   "Tian, Kevin" <kevin.tian@intel.com>
To:     Jason Gunthorpe <jgg@nvidia.com>, "Lu, Baolu" <baolu.lu@intel.com>
CC:     Jean-Philippe Brucker <jean-philippe@linaro.org>,
        Alex Williamson <alex.williamson@redhat.com>,
        "Liu, Yi L" <yi.l.liu@intel.com>, "hch@lst.de" <hch@lst.de>,
        "jasowang@redhat.com" <jasowang@redhat.com>,
        "joro@8bytes.org" <joro@8bytes.org>,
        "parav@mellanox.com" <parav@mellanox.com>,
        "lkml@metux.net" <lkml@metux.net>,
        "pbonzini@redhat.com" <pbonzini@redhat.com>,
        "lushenming@huawei.com" <lushenming@huawei.com>,
        "eric.auger@redhat.com" <eric.auger@redhat.com>,
        "corbet@lwn.net" <corbet@lwn.net>,
        "Raj, Ashok" <ashok.raj@intel.com>,
        "yi.l.liu@linux.intel.com" <yi.l.liu@linux.intel.com>,
        "Tian, Jun J" <jun.j.tian@intel.com>, "Wu, Hao" <hao.wu@intel.com>,
        "Jiang, Dave" <dave.jiang@intel.com>,
        "jacob.jun.pan@linux.intel.com" <jacob.jun.pan@linux.intel.com>,
        "kwankhede@nvidia.com" <kwankhede@nvidia.com>,
        "robin.murphy@arm.com" <robin.murphy@arm.com>,
        "kvm@vger.kernel.org" <kvm@vger.kernel.org>,
        "iommu@lists.linux-foundation.org" <iommu@lists.linux-foundation.org>,
        "dwmw2@infradead.org" <dwmw2@infradead.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "baolu.lu@linux.intel.com" <baolu.lu@linux.intel.com>,
        "david@gibson.dropbear.id.au" <david@gibson.dropbear.id.au>,
        "nicolinc@nvidia.com" <nicolinc@nvidia.com>
Subject: RE: [RFC 10/20] iommu/iommufd: Add IOMMU_DEVICE_GET_INFO
Thread-Topic: [RFC 10/20] iommu/iommufd: Add IOMMU_DEVICE_GET_INFO
Thread-Index: AQHXrSGNbNtRgavabUSKJjvt8l12BauwlhaAgAAouwCAACufAIAAgyUAgAAUFACAAAdkgIAAB/8AgArAWrA=
Date:   Thu, 30 Sep 2021 08:49:03 +0000
Message-ID: <BN9PR11MB5433F33CB7CFBCD41BE2F5C68CAA9@BN9PR11MB5433.namprd11.prod.outlook.com>
References: <20210919063848.1476776-1-yi.l.liu@intel.com>
 <20210919063848.1476776-11-yi.l.liu@intel.com>
 <20210922152407.1bfa6ff7.alex.williamson@redhat.com>
 <20210922234954.GB964074@nvidia.com>
 <BN9PR11MB543333AD3C81312115686AAA8CA39@BN9PR11MB5433.namprd11.prod.outlook.com>
 <YUxTvCt1mYDntO8z@myrica> <20210923112716.GE964074@nvidia.com>
 <BN9PR11MB5433BCFCF3B0CB657E9BFE898CA39@BN9PR11MB5433.namprd11.prod.outlook.com>
 <20210923122220.GL964074@nvidia.com>
In-Reply-To: <20210923122220.GL964074@nvidia.com>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?2moWwzX1xIWu3/6sNGSLWS3MTPfxyVfjmjD5JBEFcFLGRIMNQSFBmmj5DCJN?=
 =?us-ascii?Q?ucMEyZlgp0yCcid1xSTyjA6s/K/4DD7I2JVF0lUn6bsyRcHrqC3tigiSaRRl?=
 =?us-ascii?Q?iUGy8/tjCeYldppO61Ylj17LzVpu6nfoC+GDbTC2Z7lzPVG+ixJT2SqQS86/?=
 =?us-ascii?Q?iEEnKzqjdUxaEUDMlaZhL1ahrRY2wMAmGGkVe6lMSRD4ieVdPJnEfDe4OP39?=
 =?us-ascii?Q?Jj5wK4TkIer1acb9MX/29IRZNgZomyU84D/GhMqLVO04d+CdRSToUP1zUwau?=
 =?us-ascii?Q?ELcF2N0hyQDWJHU5uvkFoQ8rIhKS33tMryrMyE+9esekojHX4TUszqF98mQZ?=
 =?us-ascii?Q?0W8CaEHgUiNP4j/SNBMqw/c/40aUXDo+cKMFsgj3vW0yOxPkvTLwTYVGVqx4?=
 =?us-ascii?Q?uzHrWJdGcEeYT9HiUNFBI/Wku8coajhA0gXwJrKEaVmVeKy5T/QEhfBWB2Us?=
 =?us-ascii?Q?uiKKI6QB478quT2qUTmb+9cuOQcDDe4zlmj8lRzOVEogwqTex2qroYjLWyBh?=
 =?us-ascii?Q?rrhUtIiRsomMU5elkeV/zCWpy1LwLDfpY7NcCe0uYEKCn0igLChmjvLSLci4?=
 =?us-ascii?Q?yNV/F2corlLo7y/2MgTKCTPSCGD3BZGyNG5GCb2pj8a3tfcoKXRxnc5oOf8f?=
 =?us-ascii?Q?eDUeZhcK8QjeRtJw2XwjLKdWnttscA9C8HmeB50FqZLTEsYNFEQ5mRdFXN/J?=
 =?us-ascii?Q?CvuY/Uls3xBwXuIYe5vO1blfIojbaDEdB/FIq35G5kIGuTqNeAPiopIL4aoD?=
 =?us-ascii?Q?GvXrVXtQ9zMEYXnbquQU7f0sT6J0E2COd2jDtLJs2M2gEh8fEIaWvzEeo3CK?=
 =?us-ascii?Q?YGvlqo2EOJhNu0iWUKmQoLpkVIAeco3syPgf5P4/4eLenKbs+EZKg10d63mT?=
 =?us-ascii?Q?pp+be2GZwAGIZMDu0GA8A5v1/e8Myps0rnnsJq1l0G1xYXYMggW7MUKdkjbf?=
 =?us-ascii?Q?uK9egLQslusWBETTpkcrsU6vr+ahAEvcGU6mSmKjBpxayy3/6E/kN8Zjvbk+?=
 =?us-ascii?Q?qC1oREXYFxF0NdaSVkQUr7HrK+dPvwlPmdMZwrzqbsnjEF/lzzFiQPCCcFQX?=
 =?us-ascii?Q?zCCRWvcROy/9j26wQJrxknyD5uvzglcjKAjruqIxD7W+3/1CQnegUnIUljY7?=
 =?us-ascii?Q?XPannS9IjDgpNDUtlWpGxkDO1r4qbgoGulPHT+ZffhfjXDeC7o6eG56rYr/D?=
 =?us-ascii?Q?qTZn0yHLDHsjuTqtTY1//rhvJsPJejo5czHXM9DBfrUlrVkCfSOEl3iwXEJv?=
 =?us-ascii?Q?PFbhuhMav+Kv9NZlHtwUGez/z94+NnJbXH1JYQ0kWHuPdJgZ5EHdjh479c8E?=
 =?us-ascii?Q?2sKMYk4seMNs2opXcj1deMpK?=
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: BN9PR11MB5433.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: a9ee9a22-cfb1-43c2-2d72-08d983ef27b8
X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Sep 2021 08:49:03.5255
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 46c98d88-e344-4ed4-8496-4ed7712e255d
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: vjS2p4SHKj55HAS3qBrcTF1uj5Snc7NLwN8lpLyROR3Ak4cu5Rn65H1JdJS95Udhgk8P2ufIs1F5BtUvj4Y3Dg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN8PR11MB3764
X-OriginatorOrg: intel.com
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

> From: Jason Gunthorpe <jgg@nvidia.com>
> Sent: Thursday, September 23, 2021 8:22 PM
>=20
> > > These are different things and need different bits. Since the ARM pat=
h
> > > has a lot more code supporting it, I'd suggest Intel should change
> > > their code to use IOMMU_BLOCK_NO_SNOOP and abandon
> IOMMU_CACHE.
> >
> > I didn't fully get this point. The end result is same, i.e. making the =
DMA
> > cache-coherent when IOMMU_CACHE is set. Or if you help define the
> > behavior of IOMMU_CACHE, what will you define now?
>=20
> It is clearly specifying how the kernel API works:
>=20
>  !IOMMU_CACHE
>    must call arch cache flushers
>  IOMMU_CACHE -
>    do not call arch cache flushers
>  IOMMU_CACHE|IOMMU_BLOCK_NO_SNOOP -
>    dot not arch cache flushers, and ignore the no snoop bit.

Who will set IOMMU_BLOCK_NO_SNOOP? I feel this is arch specific
knowledge about how cache coherency is implemented, i.e.=20
when IOMMU_CACHE is set intel-iommu driver just maps it to
blocking no-snoop. It's not necessarily to be an attribute in=20
the same level as IOMMU_CACHE?

>=20
> On Intel it should refuse to create a !IOMMU_CACHE since the HW can't
> do that.=20

Agree. In reality I guess this is not hit because all devices are marked
coherent on Intel platforms...

Baolu, any insight here?

Thanks
Kevin