[PATCH v12 06/46] arm64: RMI: Define the user ABI

Suzuki K Poulose suzuki.poulose at arm.com
Thu Mar 12 02:28:16 PDT 2026


On 11/03/2026 19:10, Marc Zyngier wrote:
> On Mon, 02 Mar 2026 15:23:44 +0000,
> Steven Price <steven.price at arm.com> wrote:
>>
>>>> +  struct kvm_arm_rmi_populate {
>>>> +	__u64 base;
>>>> +	__u64 size;
>>>> +	__u64 source_uaddr;
>>>> +	__u32 flags;
>>>> +	__u32 reserved;
>>>> +  };
>>>> +
>>>> +Populate a region of protected address space by copying the data from the user
>>>> +space pointer provided. This is only valid before any VCPUs have been run.
>>>> +The ioctl might not populate the entire region and user space may have to
>>>> +repeatedly call it (with updated pointers) to populate the entire region.
>>>
>>> size as a __u64 is odd, as the return value from the ioctl is a signed
>>> int. This implies that you can't really report how many bytes you have
>>> copied.  Some form of consistency wouldn't hurt.
>>
>> Good spot. In practice this works because >2GB in one operation is
>> highly unlikely to be processed in one go. But I guess I'll change this
>> to have an output size argument. I guess I could make the kernel update
>> all of base,size,source_uaddr which would simplify user space.
> 
> In a conversation with Suzuki, I suggested that splice(2) could be a
> nicer way to express this, and allow asynchronous use with io-uring.
> 
> After all, having a guestmem backend for CCA is not exactly
> outlandish, and having a splice implementation realistic enough.
> 
> Thoughts?

One issue that I realised, is about the "flags" for the populate.
Data can be loaded as measured vs unmeasured in CCA (and in TDX
and SNP). I don't see a way to convey this with splice.

Suzuki

> 
> 	M.
> 




More information about the linux-arm-kernel mailing list