Re: [PATCH 0/8] nitro_enclaves: Support multi-NUMA CPU pools and per-node allocation

["Arnd Bergmann" <arnd@arndb.de>]

On Thu, Jul 30, 2026, at 18:35, Graf (AWS), Alexander wrote:
> On 30.07.26 17:43, Arnd Bergmann wrote:
>> On Thu, Jul 30, 2026, at 14:53, Alexander Graf wrote:
>>
>>> I picked a per-fd target over a second NE_ADD_VCPU carrying the node on
>>> every call. NE_ADD_VCPU already reports the id it chose, so a VMM
>>> spreading an enclave over several nodes needs no new call, only the
>>> target and the count it already drains; the variant would make that
>>> same VMM learn a new ioctl for behaviour it already has.
>> I had to read this three times to understand what you are trying
>> to say, but still don't know why you picked one over the other.
>
>
> Thanks a bunch for taking the time to do so. The message is: Both work. 
> We can either have special ioctls per allocation (CPU, memory) that gets 
> a special nid property or we can have a global "allocate from this nid" 
> cookie behind the fd.
>
> I don't have a super strong preference which way to pick. The main plus 
> point for the cookie is that ADD_VCPUS is already an ioctl which we 
> would otherwise have to add a new nid-aware variant for.
>
> Do you have a preference?

I would probably have picked the other one to keep the logic simpler,
but as you say it's not a big deal either way. If you end up adding
a new variant of the existing ioctl command, you can also add a few
spare fields and use copy_struct_from_user() for both commands to
deal with the zero-padding as well as checking.

        Arnd