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 bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (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 6DEC0C61DD6 for ; Wed, 2 Sep 2026 16:39:38 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:List-Subscribe:List-Help :List-Post:List-Archive:List-Unsubscribe:List-Id:Content-Type:MIME-Version: Message-ID:Date:References:In-Reply-To:Subject:Cc:To:From:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=z0JXN1Qg8SKT1PqQszVSTrjn1xMyP8kvqiPKrKavDZM=; b=ac7oLwjtIBWCNJrn0kWyvnNid7 TsXLJaALRh3zfHE3XILpQCaqYXjH+5vTUBymbSsQZSOcKtw3x0iGP8hQZlyXVcb9dq8cJaDkMxrt5 7BaXQQZmZXe6tHRrGpy1/QxbBVlqm7oM+4ZlNnJ8Ht/jNy0OvCCvPv5sT8F+bBLPQH2fZJ+CSmrUM NnImuMlx4gHrQUcKUrxmlprsBgSyOy1DoTmm+AYFZjpIsL3Y16AA9qnkw/haO3HCBERAyX8SsuGEC n3F/L++kEJfG0lgm/KBtTl9la1Ffj72xI58CY10ATobkrvxtWeHUkfcEuEJwRRVvEO1suNwF+BMGu 9LhYs53A==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.99.1 #2 (Red Hat Linux)) id 1x1nzm-0000000FDh0-1Rzw; Wed, 02 Sep 2026 16:39:30 +0000 Received: from tor.source.kernel.org ([2600:3c04:e001:324:0:1991:8:25]) by bombadil.infradead.org with esmtps (Exim 4.99.1 #2 (Red Hat Linux)) id 1x1nzk-0000000FDgK-3EUJ for linux-arm-kernel@lists.infradead.org; Wed, 02 Sep 2026 16:39:29 +0000 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) by tor.source.kernel.org (Postfix) with ESMTP id C7329600D1; Wed, 2 Sep 2026 16:39:27 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id BE6161F000E9; Wed, 2 Sep 2026 16:39:20 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1788367167; bh=z0JXN1Qg8SKT1PqQszVSTrjn1xMyP8kvqiPKrKavDZM=; h=From:To:Cc:Subject:In-Reply-To:References:Date; b=LDQvRkCfft8OKugaNahjcHj8SPwPbh0Lsgz1FJf2bdguoDCEOmR60ruh6hw4HoZ4f lkWCRjdQ6pdsTbghaNmiDzCl18HInwe4FMqj+Yn/gs4UyhvzpvjVFzE/9H7xOvXSPt rSl3MVuAjgd1j0lNArjOmMS8VQDPLG55oNCJuzNAj1cQFT3zMs0QEFZSHy5KstIYS4 5oqTIzogNUJSCUe/ib2V9vZ1wo1CNG/jbQar1twhHlw8zr8okeQDvl/JPTNirSKPBp b+AkHnbQLqcvkPxwgCW4rCWeQ+YKJiNl/76NHbcO8x6lfjduRo0gswP1nCsBMo5qkl /nmD2hapvphsQ== X-Mailer: emacs 31.1 (via feedmail 11-beta-1 I) From: Aneesh Kumar K.V To: Jason Gunthorpe Cc: Nicolin Chen , linux-coco@lists.linux.dev, kvmarm@lists.linux.dev, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, Alexey Kardashevskiy , Catalin Marinas , Dan Williams , Joerg Roedel , Jonathan Cameron , Marc Zyngier , Pranjal Shrivastava , Robin Murphy , Samuel Ortiz , Steven Price , Suzuki K Poulose , Will Deacon , Xu Yilun Subject: Re: [RFC PATCH v4 03/16] iommu/arm-smmu-v3: Add initial pSMMU realm viommu plumbing In-Reply-To: References: <20260427085344.941627-1-aneesh.kumar@kernel.org> <20260427085344.941627-4-aneesh.kumar@kernel.org> <20260901143445.GC56830@ziepe.ca> <20260902121700.GC2890729@ziepe.ca> Date: Wed, 02 Sep 2026 22:09:15 +0530 Message-ID: MIME-Version: 1.0 Content-Type: text/plain X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org Aneesh Kumar K.V writes: > Jason Gunthorpe writes: > >> On Wed, Sep 02, 2026 at 02:30:00PM +0530, Aneesh Kumar K.V wrote: >>> Jason Gunthorpe writes: >>> >>> > On Tue, Sep 01, 2026 at 03:36:37PM +0530, Aneesh Kumar K.V wrote: >>> > >>> >> @@ -463,14 +460,13 @@ >>> >> vsmmu->vmid = s2_parent->s2_cfg.vmid; >>> >> >>> >> if (viommu->type == IOMMU_VIOMMU_TYPE_ARM_SMMUV3) { >>> >> + if (arm_smmu_is_realm_viommu(viommu)) >>> >> + return arm_realm_smmu_v3_init(viommu, user_data); >>> >> + >>> > >>> > I think the realm vsmmu is going to require a different info struct >>> > than the normal psmmu case, isn't it? >>> > >>> > If so it needs its own enum value. >>> > >>> > It would be nice to see a draft patch showing how the real vsmmu works >>> > on top of the RMM spec for it. If we are using a viommu object then >>> > non-vsmmu case should be identical just with an option in the info >>> > struct to not create the vsmmu object. >>> >>> Based on feedback on other emails in this thread, I have now implemented >>> this without using a vdevice or viommu. This should make the CCA and >>> non-CCA cases similar. >> >> That wasn't the feedback. The feedback was to use the viommu and not >> make a bunch of new stuff.. >> > > That rework was done before I saw your discussion with Nicolin. > > To reiterate, for this configuration: > > - The viommu will use a stage-1 bypass configuration. > - A new IOMMU_VIOMMU_TYPE_ARM_REALM_SMMUV3 type will create the viommu. > The psmmu will be activated at this point to avoid creating psmmu > objects early. We will reference-count it to ensure that the same > psmmu is shared across realm guests. > - Creating a vdevice will invoke SMC_RMI_PSMMU_ST_L2_CREATE. > > I am unclear about the vdev_create suggestion. Creating a vdevice > requires an RD, which is created later in the flow above. How do you > suggest linking vdevice_alloc to vdev_create? > I was able to prototype the following flow: - The viommu uses a stage-1 bypass configuration. - A new IOMMU_VIOMMU_TYPE_ARM_REALM_SMMUV3 type creates the viommu. The pSMMU is activated at this point to avoid creating pSMMU objects early. It is reference-counted so that the same pSMMU can be shared across realm guests. - The realm is created during viommu allocation, ensuring that the vSMMU can be created here. - Creating a vdevice invokes SMC_RMI_PSMMU_ST_L2_CREATE. - This is followed by tsm_bind() if the device has an established TSM link. static int arm_realm_smmu_v3_vdevice_init(struct iommufd_vdevice *vdev) { struct device *dev = iommufd_vdevice_to_device(vdev); struct kvm *kvm = vdev->viommu->kvm_file->private_data; struct arm_smmu_device *smmu; struct arm_smmu_stream *stream; struct arm_smmu_master *master; unsigned long rmi_ret = 0; unsigned long l2_sid; int ret; if (!tsm_is_configured(dev)) return 0; master = dev_iommu_priv_get(dev); /* FIXME which stream to pick */ /* At this moment, iommufd only supports PCI device that has one SID */ stream = &master->streams[0]; smmu = master->smmu; l2_sid = ALIGN_DOWN(stream->id, STRTAB_NUM_L2_STES); { guard(mutex)(&smmu->realm.mutex); if (!arm_realm_smmu_active(smmu)) return -EINVAL; ret = rmi_psmmu_st_l2_create(smmu->base_phys, l2_sid, &rmi_ret); if (ret || rmi_ret) { if (!ret) return -EIO; if (RMI_RETURN_STATUS(rmi_ret) != RMI_ERROR_PSMMU_ST || RMI_RETURN_INDEX(rmi_ret) != 2) { dev_warn(dev, "failed to create realm stream mapping\n"); return -EIO; } /* The L2 stream table already exists. */ } } vdev->destroy = arm_realm_smmu_v3_vdevice_destroy; return tsm_bind(dev, kvm, vdev->virt_id); } - tsm_bind() calls cca_tsm_bind(), which in turn calls vdev_create(). - After boot, the guest locks the device. This generates an RHI request that reaches cca_tsm_guest_req() with RHI_DA_TDI_CONFIG_LOCKED. - cca_tsm_guest_req() now handles TSM_REQ_SET_TDI_STATE requests for the unlocked, locked, and running states. @@ -513,10 +514,16 @@ static ssize_t cca_tsm_guest_req(struct pci_tdi *tdi, if (copy_from_user((void *)&req_obj, req.user, req_len)) return -EFAULT; - if (req_obj.tdi_state != RHI_DA_TDI_CONFIG_RUN) + switch (req_obj.tdi_state) { + case RHI_DA_TDI_CONFIG_UNLOCKED: + return cca_vdev_device_unlock(pdev); + case RHI_DA_TDI_CONFIG_LOCKED: + return cca_vdev_device_lock(pdev); + case RHI_DA_TDI_CONFIG_RUN: + return cca_vdev_device_start(pdev); + default: return -EINVAL; - - return cca_vdev_device_start(pdev); + } } -aneesh