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>,
        Jean-Philippe Brucker <jean-philippe@linaro.org>
CC:     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: AQHXrSGNbNtRgavabUSKJjvt8l12BauwlhaAgAAouwCAACufAIAAgyUAgAAUFACAAAdkgA==
Date:   Thu, 23 Sep 2021 12:05:29 +0000
Message-ID: <BN9PR11MB5433BCFCF3B0CB657E9BFE898CA39@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>
In-Reply-To: <20210923112716.GE964074@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?DJcUO2xxmfYetE8r7jy81D3ZzgH7Fk9AU3gEX/ArMT5lADqYpjvkN+SeLvGg?=
 =?us-ascii?Q?sg64t+lphg5v/BKb2WDcpd0HvEKgFiCHTVRgoh6LapKb0WPGthGn3eK9UqzC?=
 =?us-ascii?Q?MDia8+t/n0LIKzZ9u3CCyYecwIblG6pgIcTqtqgkBlWcRBRYp8c4B05B1u9E?=
 =?us-ascii?Q?/8mLgPNW56jp+FAcbNjxJkVbmUMtl2UWmxpTLQB26cNOEjOsmsUmLZJhK2d3?=
 =?us-ascii?Q?x75nCEV/3/I14dnMnyd4mvoIaBTdG6G5iPgPUN0fdHN54RCJpw2Zo/7Enl3k?=
 =?us-ascii?Q?qAYduCt3B5YzMwo9wo8cqncvVtmqyF42XW8rc0/a1PxbADnRlgClitMiESN/?=
 =?us-ascii?Q?DuMpkJJi0b/7Xxd9Yyg0uNy9DFnl7CR6Y+nrtakObnbquwDQ3SySqGKr+KJA?=
 =?us-ascii?Q?8xTuqUH8vA1WaeJTVxEseg3MzT4jvw49APLSJ+OXcsmHs15TwZ1wJqtyuue5?=
 =?us-ascii?Q?6+LJU1r4LRtRfeCbsY9HNXNxQcxg2zA7mB8uW1Os58Edq88tFaw0omZFp+XU?=
 =?us-ascii?Q?yk7BOPvABqq2ZbCmI0x0IawRlXjOfV/RCqYjYo9j+/PrpOPk63VEZHz/di9e?=
 =?us-ascii?Q?5KvD8KjsuR3yMwyvyxU1uxV+L1evGZ6QvOCj1YjZBFJTKIEdsDMFkvrF2heu?=
 =?us-ascii?Q?AdF886szsGYAXRN9ihHP+jCHfd8am3G61FT6X+x0k05nvob5owzzojdp9fhP?=
 =?us-ascii?Q?ZAuODdGuPo9wEma/JjQ15ljK1QVitD7NhkkJC2TcYkCbYnsTvvonD62FUyJq?=
 =?us-ascii?Q?FSqUvXMM3anzmG/WmNI7NFh55DEgUfnVpzEyM+KiOBButrtHsBap/JSvGkO7?=
 =?us-ascii?Q?ug4pS8xbc+UOO0SaeMySUE0O7+DVU83V0pjcQcHAvb4CHlzMG2XgiAy1hJoE?=
 =?us-ascii?Q?9rWFkDOouVp52WjlWUOuGNiVpA6AGg3YcDurhbEk3F4gJaIGL3baEHKU5d8d?=
 =?us-ascii?Q?td5o69ArHsGKjeGHE+00gcPZuQqSnyJBgQaOVrOq0HDq9QXtAPwGwNpwBq2X?=
 =?us-ascii?Q?ODqjVWZFPozbPfSwcl5jHEDySqXaaVntWJegpnOkPL+JitZ65HU13U8Az24B?=
 =?us-ascii?Q?FWnyxH2oXRQcLQmBa5f9sbrzETsSa4SkEXqS0710YUFO67DlexvCEzNcpabk?=
 =?us-ascii?Q?rSCWOI4PLuosEvwoXAyx2bmdXGXFiBe7t+CnMcCaSBE5/RKlUBdxB3shQnV0?=
 =?us-ascii?Q?6Pjr/pnrzM0J/sxrAZg0WIBdYxIeikruhnfqN87OfTAinUX5bH5nF3/4aJBy?=
 =?us-ascii?Q?5s0aIVOBrlIAl5GfoM6XSBDQ6ZxMQvaJeNsdim5XyqzI5CRKF0xkxK7mxRNG?=
 =?us-ascii?Q?pFtyAcnOisMno+84Cg/QTu/f?=
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: 5e57bd55-ef5f-4acf-a315-08d97e8a6fe9
X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Sep 2021 12:05:29.6212
 (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: ewJC8j3gCaD6GlJPggzbbCk+p4pxK0/j+1GdWqKAtpJTbR+0w97HDNuyyBGaWKHhiN0IvOarW6ops+ncPsfUuw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN7PR11MB2595
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 7:27 PM
>=20
> On Thu, Sep 23, 2021 at 11:15:24AM +0100, Jean-Philippe Brucker wrote:
>=20
> > So we can only tell userspace "No_snoop is not supported" (provided we
> > even want to allow them to enable No_snoop). Users in control of stage-=
1
> > tables can create non-cacheable mappings through MAIR attributes.
>=20
> My point is that ARM is using IOMMU_CACHE to control the overall
> cachability of the DMA
>=20
> ie not specifying IOMMU_CACHE requires using the arch specific DMA
> cache flushers.
>=20
> Intel never uses arch specifc DMA cache flushers, and instead is
> abusing IOMMU_CACHE to mean IOMMU_BLOCK_NO_SNOOP on DMA that
> is always
> cachable.

it uses IOMMU_CACHE to force all DMAs to snoop, including those which
has non_snoop flag and wouldn't snoop cache if iommu is disabled. Nothing
is blocked.

but why do you call it abuse? IOMMU_CACHE was first introduced for
Intel platform:

commit 9cf0669746be19a4906a6c48920060bcf54c708b
Author: Sheng Yang <sheng@linux.intel.com>
Date:   Wed Mar 18 15:33:07 2009 +0800

    intel-iommu: VT-d page table to support snooping control bit

    The user can request to enable snooping control through VT-d page table=
.

    Signed-off-by: Sheng Yang <sheng@linux.intel.com>
    Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>

>=20
> These are different things and need different bits. Since the ARM path
> 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
> Which clarifies what to do here as uAPI - these things need to have
> different bits and Intel's should still have NO SNOOP in the
> name. What the no-snoop bit is called on other busses can be clarified
> in comments if that case ever arises.
>=20
> Jason