From: Jason Gunthorpe <jgg@nvidia.com>
To: "Aneesh Kumar K.V (Arm)" <aneesh.kumar@kernel.org>
Cc: 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>, Nicolin Chen <nicolinc@nvidia.com>,
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 00/16] coco/TSM: Implement host-side support for Arm CCA TDISP setup
Date: Mon, 31 Aug 2026 15:08:55 -0300 [thread overview]
Message-ID: <20260831180855.GA2171358@nvidia.com> (raw)
In-Reply-To: <20260427085344.941627-1-aneesh.kumar@kernel.org>
On Mon, Apr 27, 2026 at 02:23:28PM +0530, Aneesh Kumar K.V (Arm) wrote:
>
> This patch series implements the host-side changes needed for end-to-end
> Arm CCA TDISP setup. It adds the RMI/RHI plumbing required to create and
> manage Realm vdev objects, service device-attestation object requests, and
> complete the KVM/RMM flows needed for device run-time transitions.
So this is enough for the realm to see a physical PCI device inside it
without any vSMMU inside the realm?
It is really weird to see a viommu for a case where there is no
viommu..
It doesn't do anything except manage memory for the RMM..
It feels wrong that the arm-cca-guest module is calling
RMI_PDEV_CREATE and RMI_VDEV_CREATE while the viommu is allocating STE
memory for the PDEV. That doesn't make alot of sense? The STE is
needed before VDEV_CREATE, right? So why not place it there in the
flow?
If that's changed then the only thing the viommu does is manage the
PSMMU, which again, seems like something VDEV_CREATE needs, so why is
a viommu involved at all?
The smmu driver involvment would be much smaller if it was only the
interrupt routing and some helper to return the psmmu addr for a
struct device that the arm-cc-guest module can call to manage the
psmmu?
But I'm also sitting here scratching my head a bit, did the tsm_ops
design go the wrong way? Should we have run more of that through a
viommu instead of tsm_ops? Bind is sort of an illogical operation
without a viommu, even if it is a nop viommu.
I suppose it depends what it looks like when a real vsmmu is
created.. That probably needs a special viommu object, and do we get
into order problems if the lifecylce becomes split to tsm and viommu?
> RHI v1.0 BET1 specification [5].
>
> At a high level, the series adds support for:
> - host-side vdev communication and lifecycle management
> - host handling of RHI DA object read/size requests
> - host-side fetching and caching of interface reports and measurements
> - KVM handling of vdev request/complete exits
> - KVM handling of map/validation exits and teardown on granule destroy
> - vdev transition to TDISP RUN state
> - enabling DA in Realm create parameters
>
> The series builds upon the TSM framework patches posted at [2] and depends on
> the KVM CCA patchset [3]. A git repository containing all related changes is
> available at [4]. kvmtool repo is at [6]
It looks like it also needs the series that adds bind to iommufd too
Jason
next prev parent reply other threads:[~2026-08-31 18:09 UTC|newest]
Thread overview: 54+ 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 23:56 ` Jason Gunthorpe
2026-09-03 5:48 ` Aneesh Kumar K.V
2026-09-03 17:17 ` Jason Gunthorpe
2026-09-07 9:45 ` Aneesh Kumar K.V
2026-09-07 12:52 ` Jason Gunthorpe
2026-09-09 10:09 ` Aneesh Kumar K.V
2026-09-09 12:46 ` Jason Gunthorpe
2026-09-10 9:52 ` Tian, Kevin
2026-09-10 12:46 ` Jason Gunthorpe
2026-09-02 19:30 ` Jason Gunthorpe
2026-09-03 5:28 ` Aneesh Kumar K.V
2026-09-03 14:47 ` Jason Gunthorpe
2026-09-03 15:13 ` Suzuki K Poulose
2026-09-03 17:19 ` Jason Gunthorpe
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 ` Jason Gunthorpe [this message]
2026-09-01 12:44 ` [RFC PATCH v4 00/16] coco/TSM: Implement host-side support for Arm CCA TDISP setup 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=20260831180855.GA2171358@nvidia.com \
--to=jgg@nvidia.com \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.