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

[Graf (AWS), Alexander]

Hey Arnd!

On 30.07.26 17:43, Arnd Bergmann wrote:
> On Thu, Jul 30, 2026, at 14:53, Alexander Graf wrote:
>
> Hi Alex
>
>> 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 wrote this series with an AI coding assistant, which drafted the code
>> and the changelogs, this cover letter included; I reviewed and reworked
>> all of it before sending, and each commit carries an Assisted-by:
>> trailer. All eight commits were built detached in three configurations
>> (x86_64 defconfig with CONFIG_NITRO_ENCLAVES=m, the same with
>> CONFIG_NUMA=n, and allmodconfig) for 24 warning-free driver builds, and
>> scripts/checkpatch.pl --strict is clean on all eight.
> The patches look fine to me overall, I only have some very minor
> comments on them. The autogenerated changelogs seem actively
> counterproductive though, despite your attempts to to rewrite
> them into something readable. This seems to have just made the
> series harder to review. Instead of telling the reader a
> consistent story about what each change is for, the generated
> text has too much useless detail about the implementation.


I agree. And that's after I massaged it many times already :(. Maybe in 
the next set, I'll just write it myself again :). Or I'll find a way to 
generate actually readable ones.


Alex