[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