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

[Suzuki K Poulose]

On 11/03/2026 19:10, Marc Zyngier wrote:
> On Mon, 02 Mar 2026 15:23:44 +0000,
> Steven Price <steven.price@xxxxxxx> 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.