From: Jason Gunthorpe <jgg@ziepe.ca>
To: "Aneesh Kumar K.V" <aneesh.kumar@kernel.org>
Cc: Nicolin Chen <nicolinc@nvidia.com>,
linux-coco@lists.linux.dev, kvmarm@lists.linux.dev,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, Alexey Kardashevskiy <aik@amd.com>,
Catalin Marinas <catalin.marinas@arm.com>,
Dan Williams <dan.j.williams@intel.com>,
Joerg Roedel <joro@8bytes.org>,
Jonathan Cameron <jic23@kernel.org>,
Marc Zyngier <maz@kernel.org>,
Pranjal Shrivastava <praan@google.com>,
Robin Murphy <robin.murphy@arm.com>,
Samuel Ortiz <sameo@rivosinc.com>,
Steven Price <steven.price@arm.com>,
Suzuki K Poulose <Suzuki.Poulose@arm.com>,
Will Deacon <will@kernel.org>,
Xu Yilun <yilun.xu@linux.intel.com>
Subject: Re: [RFC PATCH v4 03/16] iommu/arm-smmu-v3: Add initial pSMMU realm viommu plumbing
Date: Wed, 2 Sep 2026 16:30:14 -0300 [thread overview]
Message-ID: <20260902193014.GF2890729@ziepe.ca> (raw)
In-Reply-To: <yq5aik4nztdt.fsf@kernel.org>
On Wed, Sep 02, 2026 at 06:45:42PM +0530, Aneesh Kumar K.V wrote:
> 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 thinking we'd make sure the KVM is associated with the viommu
and/or possibly the S2 domain. That was always sort of broadly the
idea in this space. There are several topics unrelated to CC that
needed this.
In any case, when you create the iommufd viommu you should also do
VSMMU_CREATE which needs the RD. It seems reasonable to assume the RD
is available during vdevice create.
[There is an aside here I will mention: several other use cases need
this idea of an "external" domain where the HWPT would be created but
not controlled by iommufd or the iommu subsystem. Xen and Hyperv for
example. There is probably some merit in thinking more about exactly
what the nested parent domain should be for this viommu, but it isn't
critical.]
> From the RMM's perspective, the sequence is as follows:
>
> viommu alloc
>
> [ rmm ] SMC_RMI_PSMMU_ACTIVATE 2b400000 8819bb000 > RMI_INCOMPLETE 0 10008
> [ rmm ] SMC_RMI_OP_MEM_DONATE 0 881bac098 1 > RMI_INCOMPLETE 2 10004
> [ rmm ] SMC_RMI_OP_MEM_DONATE 0 881bac098 1 > RMI_INCOMPLETE 1 10004
> [ rmm ] SMC_RMI_OP_MEM_DONATE 0 881bac098 1 > RMI_INCOMPLETE 1 0
> [ rmm ] L1 StrTab: PA 0x881baa000 VA 0x80003c0000 size 0x2000
> [ rmm ] CMDQ: PA 0x88066a000 VA 0x80003c2000
> [ rmm ] EVTQ: PA 0x8815c5000 VA 0x80003c3000
> [ rmm ] PSMMU 0x2b400000 activated
> [ rmm ] SMC_RMI_OP_CONTINUE 0 0 > RMI_SUCCESS 0 0
>
> [ rmm ] SMC_RMI_PSMMU_ST_L2_CREATE 2b400000 300 > RMI_INCOMPLETE 0 10004
> [ rmm ] SMC_RMI_OP_MEM_DONATE 0 881bac098 1 > RMI_INCOMPLETE 1 0
> [ rmm ] smmu->strtab_base[12] 0x0 @0x80003c0060
> [ rmm ] L1STD[12] 0x8819bb007 for SID 0x300: L2 table VA 0x80003d0000 PA 0x8819bb000
> [ rmm ] SMC_RMI_OP_CONTINUE 0 0 > RMI_SUCCESS 0 0
What was this one for during viommu alloc?
> vdevice alloc
>
> [ rmm ] SMC_RMI_PSMMU_ST_L2_CREATE 2b400000 200 > RMI_INCOMPLETE 0 10004
> [ rmm ] SMC_RMI_OP_MEM_DONATE 0 882648098 1 > RMI_INCOMPLETE 1 0
> [ rmm ] smmu->strtab_base[8] 0x0 @0x80003c0040
> [ rmm ] L1STD[8] 0x882506007 for SID 0x200: L2 table VA 0x80003cc000 PA 0x882506000
> [ rmm ] SMC_RMI_OP_CONTINUE 0 0 > RMI_SUCCESS 0 0
>
> RD gets allocated here
>
> [ rmm ] SMC_RMI_REALM_CREATE 881b03000 8819a1000 > RMI_INCOMPLETE 0 24
> [ rmm ] SMC_RMI_OP_MEM_DONATE 0 881605098 9 > RMI_INCOMPLETE 9 0
> [ rmm ] SMC_RMI_OP_CONTINUE 0 0 > RMI_SUCCESS 0 0
Why? The VMM needs to create the kvm before starting the iommu stuff.
I would expect that KVM knows it is going to a realm very early on? I
had assumed the RD would also be created early by KVM?
What triggers RD creation? Why can't the VMM do it earlier?
Your followup said:
- The realm is created during viommu allocation, ensuring that the
vSMMU can be created here.
Do you mean the SMMUv3 driver triggers RD creation? That feels
wrong. Did you mean the VMM just does it earlier?
The draft in the next message looks promising, did you discover any
other gotchas when exploring it?
When you repost this can you take some care to explain the general
idea of this modelling in the commit messages so AMD and Intel can
confirm they can use it for both their non-viommu and viommu cases?
Thanks,
Jason
next prev parent reply other threads:[~2026-09-02 19:30 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-27 8:53 [RFC PATCH v4 00/16] coco/TSM: Implement host-side support for Arm CCA TDISP setup Aneesh Kumar K.V (Arm)
2026-04-27 8:53 ` [RFC PATCH v4 01/16] iommu/arm-smmu-v3: Discover RME support and realm IRQ topology Aneesh Kumar K.V (Arm)
2026-08-29 18:22 ` Nicolin Chen
2026-09-01 8:46 ` Aneesh Kumar K.V
2026-09-01 14:32 ` Jason Gunthorpe
2026-04-27 8:53 ` [RFC PATCH v4 02/16] iommu/arm-smmu-v3: Save the programmed MSI message in msi_desc Aneesh Kumar K.V (Arm)
2026-04-27 8:53 ` [RFC PATCH v4 03/16] iommu/arm-smmu-v3: Add initial pSMMU realm viommu plumbing Aneesh Kumar K.V (Arm)
2026-08-29 20:00 ` Nicolin Chen
2026-09-01 9:17 ` Aneesh Kumar K.V
2026-09-01 10:06 ` Aneesh Kumar K.V
2026-09-01 14:34 ` Jason Gunthorpe
2026-09-01 17:13 ` Nicolin Chen
2026-09-01 17:18 ` Nicolin Chen
2026-09-01 17:45 ` Jason Gunthorpe
2026-09-01 17:42 ` Jason Gunthorpe
2026-09-01 19:08 ` Nicolin Chen
2026-09-02 0:21 ` Nicolin Chen
2026-09-02 1:51 ` Jason Gunthorpe
2026-09-02 13:10 ` Aneesh Kumar K.V
2026-09-02 9:00 ` Aneesh Kumar K.V
2026-09-02 12:17 ` Jason Gunthorpe
2026-09-02 13:15 ` Aneesh Kumar K.V
2026-09-02 16:39 ` Aneesh Kumar K.V
2026-09-02 19:30 ` Jason Gunthorpe [this message]
2026-09-01 17:36 ` Nicolin Chen
2026-04-27 8:53 ` [RFC PATCH v4 04/16] iommu/arm-smmu-v3: Track realm pSMMU users with refcount_t Aneesh Kumar K.V (Arm)
2026-04-27 8:53 ` [RFC PATCH v4 05/16] coco: host: arm64: Add support for virtual device communication Aneesh Kumar K.V (Arm)
2026-04-27 8:53 ` [RFC PATCH v4 06/16] coco: host: arm64: Add support for RMM vdev objects Aneesh Kumar K.V (Arm)
2026-04-27 8:53 ` [RFC PATCH v4 07/16] coco: host: arm64: Add pdev stream key refresh and purge helpers Aneesh Kumar K.V (Arm)
2026-04-27 8:53 ` [RFC PATCH v4 08/16] coco: host: arm64: Add helpers to unlock and destroy RMM vdev Aneesh Kumar K.V (Arm)
2026-04-27 8:53 ` [RFC PATCH v4 09/16] coco: host: arm64: Add support for da object read RHI handling Aneesh Kumar K.V (Arm)
2026-04-27 8:53 ` [RFC PATCH v4 10/16] coco: host: arm64: Add helper for cached object fetches Aneesh Kumar K.V (Arm)
2026-04-27 8:53 ` [RFC PATCH v4 11/16] coco: host: arm64: Fetch interface report via RMI Aneesh Kumar K.V (Arm)
2026-04-27 8:53 ` [RFC PATCH v4 12/16] coco: host: arm64: Fetch device measurements " Aneesh Kumar K.V (Arm)
2026-04-27 8:53 ` [RFC PATCH v4 13/16] coco: host: KVM: arm64: Handle vdev validate-mapping exits Aneesh Kumar K.V (Arm)
2026-04-27 8:53 ` [RFC PATCH v4 14/16] KVM: arm64: Unmap device mappings when a private granule is destroyed Aneesh Kumar K.V (Arm)
2026-04-27 8:53 ` [RFC PATCH v4 15/16] coco: host: arm64: Transition vdevs to TDISP RUN state Aneesh Kumar K.V (Arm)
2026-04-27 8:53 ` [RFC PATCH v4 16/16] KVM: arm64: CCA: enable DA in realm create parameters Aneesh Kumar K.V (Arm)
2026-08-31 18:08 ` [RFC PATCH v4 00/16] coco/TSM: Implement host-side support for Arm CCA TDISP setup Jason Gunthorpe
2026-09-01 12:44 ` Aneesh Kumar K.V
2026-09-01 13:07 ` Jason Gunthorpe
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260902193014.GF2890729@ziepe.ca \
--to=jgg@ziepe.ca \
--cc=Suzuki.Poulose@arm.com \
--cc=aik@amd.com \
--cc=aneesh.kumar@kernel.org \
--cc=catalin.marinas@arm.com \
--cc=dan.j.williams@intel.com \
--cc=jic23@kernel.org \
--cc=joro@8bytes.org \
--cc=kvmarm@lists.linux.dev \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-coco@lists.linux.dev \
--cc=linux-kernel@vger.kernel.org \
--cc=maz@kernel.org \
--cc=nicolinc@nvidia.com \
--cc=praan@google.com \
--cc=robin.murphy@arm.com \
--cc=sameo@rivosinc.com \
--cc=steven.price@arm.com \
--cc=will@kernel.org \
--cc=yilun.xu@linux.intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox