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

[Marc Zyngier]

On Thu, 12 Mar 2026 09:28:16 +0000,
Suzuki K Poulose <suzuki.poulose at arm.com> wrote:
> 
> 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.

Surely that should me a property of the memory region, and not the way
it is copied, right?

	M.

-- 
Without deviation from the norm, progress is not possible.