From: Jonathan Cameron <jonathan.cameron@huawei.com>
To: "Aneesh Kumar K.V (Arm)" <aneesh.kumar@kernel.org>
Cc: <linux-coco@lists.linux.dev>, <kvmarm@lists.linux.dev>,
<linux-pci@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
<dan.j.williams@intel.com>, <aik@amd.com>, <lukas@wunner.de>,
Samuel Ortiz <sameo@rivosinc.com>,
Xu Yilun <yilun.xu@linux.intel.com>,
Jason Gunthorpe <jgg@ziepe.ca>,
Suzuki K Poulose <Suzuki.Poulose@arm.com>,
Steven Price <steven.price@arm.com>,
Bjorn Helgaas <helgaas@kernel.org>,
Catalin Marinas <catalin.marinas@arm.com>,
Marc Zyngier <maz@kernel.org>, Will Deacon <will@kernel.org>,
Oliver Upton <oliver.upton@linux.dev>
Subject: Re: [PATCH v2 06/11] coco: guest: arm64: Add support for reading cached objects from host
Date: Thu, 20 Nov 2025 17:31:57 +0000 [thread overview]
Message-ID: <20251120173157.00007fc4@huawei.com> (raw)
In-Reply-To: <20251117140007.122062-7-aneesh.kumar@kernel.org>
On Mon, 17 Nov 2025 19:30:02 +0530
"Aneesh Kumar K.V (Arm)" <aneesh.kumar@kernel.org> wrote:
> Teach rsi_device_start() to pull the interface report and device
> certificate from the host by querying size, sharing a decrypted buffer
> for the read, copying the payload to private memory. Also track the
> fetched blobs in struct cca_guest_dsc so later stages can hand them to
> the attestation flow.
>
> Signed-off-by: Aneesh Kumar K.V (Arm) <aneesh.kumar@kernel.org>
> ---
> arch/arm64/include/asm/rhi.h | 7 +++
> drivers/virt/coco/arm-cca-guest/rhi-da.c | 80 ++++++++++++++++++++++++
> drivers/virt/coco/arm-cca-guest/rhi-da.h | 1 +
> drivers/virt/coco/arm-cca-guest/rsi-da.h | 8 +++
> 4 files changed, 96 insertions(+)
>
> diff --git a/arch/arm64/include/asm/rhi.h b/arch/arm64/include/asm/rhi.h
> index ce2ed8a440c3..738470dfb869 100644
> --- a/arch/arm64/include/asm/rhi.h
> +++ b/arch/arm64/include/asm/rhi.h
> @@ -39,6 +39,13 @@
> RHI_DA_FEATURE_VDEV_SET_TDI_STATE)
> #define RHI_DA_FEATURES SMC_RHI_CALL(0x004B)
>
> +#define RHI_DA_OBJECT_CERTIFICATE 0x1
> +#define RHI_DA_OBJECT_MEASUREMENT 0x2
> +#define RHI_DA_OBJECT_INTERFACE_REPORT 0x3
> +#define RHI_DA_OBJECT_VCA 0x4
> +#define RHI_DA_OBJECT_SIZE SMC_RHI_CALL(0x004C)
> +#define RHI_DA_OBJECT_READ SMC_RHI_CALL(0x004D)
> +
> #define RHI_DA_VDEV_CONTINUE SMC_RHI_CALL(0x0051)
> #define RHI_DA_VDEV_GET_INTERFACE_REPORT SMC_RHI_CALL(0x0052)
>
> diff --git a/drivers/virt/coco/arm-cca-guest/rhi-da.c b/drivers/virt/coco/arm-cca-guest/rhi-da.c
> index aa17bb3ee562..d29aee0fca58 100644
> --- a/drivers/virt/coco/arm-cca-guest/rhi-da.c
> +++ b/drivers/virt/coco/arm-cca-guest/rhi-da.c
> @@ -248,3 +248,83 @@ int rhi_update_vdev_measurements_cache(struct pci_dev *pdev,
>
> return ret;
> }
> +
> +int rhi_read_cached_object(int vdev_id, int da_object_type, void **object, int *object_size)
> +{
> + int ret;
> + int max_data_len;
> + struct page *shared_pages;
> + void *data_buf_shared, *data_buf_private;
> + struct rsi_host_call *rhicall;
> +
> + rhicall = kmalloc(sizeof(struct rsi_host_call), GFP_KERNEL);
> + if (!rhicall)
> + return -ENOMEM;
> +
> + rhicall->imm = 0;
> + rhicall->gprs[0] = RHI_DA_OBJECT_SIZE;
> + rhicall->gprs[1] = vdev_id;
> + rhicall->gprs[2] = da_object_type;
> +
> + ret = rsi_host_call(virt_to_phys(rhicall));
> + if (ret != RSI_SUCCESS) {
> + ret = -EIO;
> + goto err_return;
> + }
> +
> + if (rhicall->gprs[0] != RHI_DA_SUCCESS) {
> + ret = -EIO;
> + goto err_return;
> + }
> +
> + /* validate against the max cache object size used on host. */
> + max_data_len = rhicall->gprs[1];
> + if (max_data_len > MAX_CACHE_OBJ_SIZE || max_data_len == 0) {
> + ret = -EIO;
> + goto err_return;
> + }
> + *object_size = max_data_len;
I raise this below, but not sure why this is set way before setting
*object. Can set it later and use max_data_len which I think is
clearer naming anyway.
> +
> + data_buf_private = kmalloc(*object_size, GFP_KERNEL);
> + if (!data_buf_private) {
> + ret = -ENOMEM;
> + goto err_return;
> + }
> +
> + shared_pages = alloc_shared_pages(NUMA_NO_NODE, GFP_KERNEL, max_data_len);
> + if (!shared_pages) {
> + ret = -ENOMEM;
> + goto err_shared_alloc;
> + }
> + data_buf_shared = page_address(shared_pages);
> +
> + rhicall->imm = 0;
> + rhicall->gprs[0] = RHI_DA_OBJECT_READ;
> + rhicall->gprs[1] = vdev_id;
> + rhicall->gprs[2] = da_object_type;
> + rhicall->gprs[3] = 0; /* offset within the data buffer */
> + rhicall->gprs[4] = max_data_len;
> + rhicall->gprs[5] = virt_to_phys(data_buf_shared);
> + ret = rsi_host_call(virt_to_phys(rhicall));
> + if (ret != RSI_SUCCESS || rhicall->gprs[0] != RHI_DA_SUCCESS) {
> + ret = -EIO;
> + goto err_rhi_call;
> + }
> +
> + memcpy(data_buf_private, data_buf_shared, *object_size);
Given data_buf_private() only seems useful if we aren't in an error
condition, why not move allocation to here and use kmemdup() ?
> + free_shared_pages(shared_pages, max_data_len);
> +
> + *object = data_buf_private;
> + kfree(rhicall);
> + return 0;
> +
> +err_rhi_call:
> + free_shared_pages(shared_pages, max_data_len);
> +err_shared_alloc:
> + kfree(data_buf_private);
> +err_return:
> + *object = NULL;
Is it necessary to zero the passed in variable given this function never
touched it and is returning an error. If it is, can you do that unconditionally
at start of function and override only on success?
> + *object_size = 0;
Likewise for the size - I'm not sure why you set that much earlier
than *object.
With those two gone, this feels like it would be well suited for
some __free magic to handle everything here.
You will need to deal with the free_shared_pages() though which will
require an extra structure definition and helpers to wrap up what
is allocated - similar to what tdx_page_array_alloc does (though without
the bulk aspects of that)
http://lore.kernel.org/all/20251117022311.2443900-7-yilun.xu@linux.intel.com/
Or given the shared page stuff is the inner most aspect anyway you could
just do a helper function from alloc_shared_pages to free_shared_pages
calls so that you can call that free_shared_pages unconditionally before
checking return value.
Note that if you do go with DEFINE_FREE() you 'could' pass in the storage.
I objected to that elsewhere but there is precedence. So have a
struct shared_pages {
struct page *page;
size_t order;
}
define one on the stack and pass it in so that you avoid an extra allocation.
Not a pattern I particularly like though and this isn't expected to be
a particularly fast path so I'd just dynamically allocate a struct shared_pages
inside alloc_shared_pages.
> + kfree(rhicall);
> + return ret;
> +}
next prev parent reply other threads:[~2025-11-20 17:32 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-11-17 13:59 [PATCH v2 00/11] TSM: Implement ->lock()/->accept() callbacks for ARM CCA TDISP setup Aneesh Kumar K.V (Arm)
2025-11-17 13:59 ` [PATCH v2 01/11] coco: guest: arm64: Guest TSM callback and realm device lock support Aneesh Kumar K.V (Arm)
2025-11-19 15:22 ` Jonathan Cameron
2025-11-24 4:40 ` Aneesh Kumar K.V
2025-11-17 13:59 ` [PATCH v2 02/11] coco: guest: arm64: Add Realm Host Interface and guest DA helper Aneesh Kumar K.V (Arm)
2025-11-19 15:32 ` Jonathan Cameron
2025-11-24 5:07 ` Aneesh Kumar K.V
2025-11-17 13:59 ` [PATCH v2 03/11] coco: guest: arm64: Add support for guest initiated TDI bind/unbind Aneesh Kumar K.V (Arm)
2025-11-19 15:50 ` Jonathan Cameron
2026-01-08 15:32 ` Will Deacon
2025-11-17 14:00 ` [PATCH v2 04/11] coco: guest: arm64: Add support for updating interface reports from device Aneesh Kumar K.V (Arm)
2025-11-19 15:54 ` Jonathan Cameron
2025-11-24 5:42 ` Aneesh Kumar K.V
2025-11-17 14:00 ` [PATCH v2 05/11] coco: guest: arm64: Add support for updating measurements " Aneesh Kumar K.V (Arm)
2025-11-20 15:22 ` Jonathan Cameron
2025-11-24 6:18 ` Aneesh Kumar K.V
2025-11-17 14:00 ` [PATCH v2 06/11] coco: guest: arm64: Add support for reading cached objects from host Aneesh Kumar K.V (Arm)
2025-11-20 17:31 ` Jonathan Cameron [this message]
2025-11-24 6:52 ` Aneesh Kumar K.V
2025-11-17 14:00 ` [PATCH v2 07/11] coco: guest: arm64: Validate Realm MMIO mappings from TDISP report Aneesh Kumar K.V (Arm)
2025-11-20 17:43 ` Jonathan Cameron
2025-11-17 14:00 ` [PATCH v2 08/11] coco: guest: arm64: Add support for fetching and verifying device info Aneesh Kumar K.V (Arm)
2025-11-20 17:54 ` Jonathan Cameron
2025-11-24 8:28 ` Aneesh Kumar K.V
2025-11-17 14:00 ` [PATCH v2 09/11] coco: guest: arm64: Wire Realm TDISP RUN/STOP transitions into guest driver Aneesh Kumar K.V (Arm)
2025-11-20 17:55 ` Jonathan Cameron
2025-11-17 14:00 ` [PATCH v2 10/11] coco: arm64: dma: Update force_dma_unencrypted for accepted devices Aneesh Kumar K.V (Arm)
2025-11-20 17:58 ` Jonathan Cameron
2025-11-17 14:00 ` [PATCH v2 11/11] coco: guest: arm64: Enable vdev DMA after attestation Aneesh Kumar K.V (Arm)
2025-11-20 17:59 ` Jonathan Cameron
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=20251120173157.00007fc4@huawei.com \
--to=jonathan.cameron@huawei.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=helgaas@kernel.org \
--cc=jgg@ziepe.ca \
--cc=kvmarm@lists.linux.dev \
--cc=linux-coco@lists.linux.dev \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=lukas@wunner.de \
--cc=maz@kernel.org \
--cc=oliver.upton@linux.dev \
--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;
as well as URLs for NNTP newsgroup(s).