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 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id A28E6C0219D for ; Thu, 6 Feb 2025 18:19:27 +0000 (UTC) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tg6SG-0007XK-3E; Thu, 06 Feb 2025 13:18:24 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tg6SD-0007Wr-P2; Thu, 06 Feb 2025 13:18:22 -0500 Received: from frasgout.his.huawei.com ([185.176.79.56]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tg6SB-0006Gu-FL; Thu, 06 Feb 2025 13:18:21 -0500 Received: from mail.maildlp.com (unknown [172.18.186.31]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4Yplf6092gz67Cwc; Fri, 7 Feb 2025 02:15:58 +0800 (CST) Received: from frapeml100006.china.huawei.com (unknown [7.182.85.201]) by mail.maildlp.com (Postfix) with ESMTPS id 81DB21402C4; Fri, 7 Feb 2025 02:18:15 +0800 (CST) Received: from frapeml500008.china.huawei.com (7.182.85.71) by frapeml100006.china.huawei.com (7.182.85.201) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2507.39; Thu, 6 Feb 2025 19:18:15 +0100 Received: from frapeml500008.china.huawei.com ([7.182.85.71]) by frapeml500008.china.huawei.com ([7.182.85.71]) with mapi id 15.01.2507.039; Thu, 6 Feb 2025 19:18:15 +0100 To: Jason Gunthorpe CC: =?iso-8859-1?Q?Daniel_P=2E_Berrang=E9?= , "qemu-arm@nongnu.org" , "qemu-devel@nongnu.org" , "eric.auger@redhat.com" , "peter.maydell@linaro.org" , "nicolinc@nvidia.com" , "ddutile@redhat.com" , Linuxarm , "Wangzhou (B)" , jiangkunkun , Jonathan Cameron , "zhangfei.gao@linaro.org" , "nathanc@nvidia.com" Subject: RE: [RFC PATCH 0/5] hw/arm/virt: Add support for user-creatable nested SMMUv3 Thread-Topic: [RFC PATCH 0/5] hw/arm/virt: Add support for user-creatable nested SMMUv3 Thread-Index: AQHbMeB0+Q5BEZc9JkeH/U6Jz+dF4rMv66IAgAA0HqCAAb2VAIAIsUnQgAADD4CAAB6MsIAAJxaAgAATMvCAABLUAIAAAjUAgAAKIYCAAAJIgIAAAQ2AgAARRyD///K+AIAAERgA Date: Thu, 6 Feb 2025 18:18:14 +0000 Message-ID: <02a0080a4a1642d69b7f5dd4707a5b3d@huawei.com> References: <71116749d1234ab48a205fd2588151ec@huawei.com> <20250206170238.GG2960738@nvidia.com> <20250206174647.GA3480821@nvidia.com> <20250206175843.GI2960738@nvidia.com> <13b1d8b97a314cb28b87563fa9b45299@huawei.com> <20250206181306.GK2960738@nvidia.com> In-Reply-To: <20250206181306.GK2960738@nvidia.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.48.156.189] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Received-SPF: pass client-ip=185.176.79.56; envelope-from=shameerali.kolothum.thodi@huawei.com; helo=frasgout.his.huawei.com X-Spam_score_int: -41 X-Spam_score: -4.2 X-Spam_bar: ---- X-Spam_report: (-4.2 / 5.0 requ) BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, RCVD_IN_VALIDITY_SAFE_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-to: Shameerali Kolothum Thodi From: Shameerali Kolothum Thodi via Errors-To: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Sender: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org > -----Original Message----- > From: Jason Gunthorpe > Sent: Thursday, February 6, 2025 6:13 PM > To: Shameerali Kolothum Thodi > Cc: Daniel P. Berrang=E9 ; qemu-arm@nongnu.org; > qemu-devel@nongnu.org; eric.auger@redhat.com; > peter.maydell@linaro.org; nicolinc@nvidia.com; ddutile@redhat.com; > Linuxarm ; Wangzhou (B) > ; jiangkunkun ; > Jonathan Cameron ; > zhangfei.gao@linaro.org; nathanc@nvidia.com > Subject: Re: [RFC PATCH 0/5] hw/arm/virt: Add support for user-creatable > nested SMMUv3 >=20 > On Thu, Feb 06, 2025 at 06:04:57PM +0000, Shameerali Kolothum Thodi > wrote: > > > Some kind of hot plug smmu would have to create a vSMMU without > any > > > kernel backing and then later bind it to a kernel implementation. > > > > Not sure I get the problem with associating vSMMU with a pSMMU. > Something > > like an iommu instance id mentioned before, > > > > -device arm-smmuv3-accel,id=3Dsmmuv2,bus=3Dpcie.2,host-smmu=3Diommu.1 > > > > This can realize the vSMMU without actually creating a vIOMMU in kernel= . > > And when the dev gets attached/realized, check (GET_HW_INFO)the > specified > > iommu instance id matches or not. > > > > Or the concern here is exporting an iommu instance id to user space? >=20 > Philisophically we do not permit any HW access through iommufd without > a VFIO fd to "prove" the process has rights to touch hardware. >=20 > We don't have any way to prove the process has rights to touch the > iommu hardware seperately from VFIO. It is not. Qemu just instantiates a vSMMU and assigns the IOMMU=20 instance id to it. >=20 > So even if you invent an iommu ID we cannot accept it as a handle to > create viommu in iommufd. Creating the vIOMMU only happens when the user does a cold/hot plug of a VFIO device. At that time Qemu checks whether the assigned id matches with whatever the kernel tell it.=20 Thanks, Shameer