Re: [RFC] dom0less vcpu affinity bindings

[Stefano Stabellini <sstabellini@xxxxxxxxxx>]

On Wed, 12 Feb 2025, Julien Grall wrote:
> Hi Stefano,
> 
> On 11/02/2025 01:56, Stefano Stabellini wrote:
> > We have received requests to introduce Dom0less vCPU affinity bindings
> > to allow configuring which pCPUs a given vCPU is allowed to run on.
> > 
> > After considering different approaches, I am thinking of using the
> > following binding format:
> > 
> >      vcpu0 {
> >             compatible = "xen,vcpu-affinity"; // compatible string
> >             id = <0>;  // vcpu id
> >             hard-affinity = "1,4-7"; // pcpu ranges
> 
> This would be CPU logical ID, right? This is a value assigned by Xen based on
> how pCPU are brought up. So in theory it could change between Xen version as
> the order is not guaranteed. I know this is what the toolstack is currently
> using.
> 
> However, as we define a new binding, I wonder whether it would be better to
> instead have a phandle to the CPU device-tree node or just plain MPIDRs? This
> would guarantee that the vCPU will always land on a given pCPU (this could be
> important when taking into account the cache topology).

Yes I can see that your suggestions would make the configuration more
precise. I was hoping to be able to make the binding arch-neutral so
that it could be used the same way on x86 (and also on RISC-V).

I would prefer to avoid the link to the pCPU device tree node because
hyperlaunch doesn't have the pCPU nodes, and also even for ARM and
RISC-V I think it would be inconveniet to manage the phandle. But maybe
we can find a way to support the MPIDR.

We could add support to the MPIDR either directly to hard-affinity,
because it should be possible to detect whether the input is unsigned
integers or an MPIDR, or with a second arch-specific property, such as:

vcpu0 {
       compatible = "xen,vcpu-affinity"; // compatible string
       id = <0>;  // vcpu id
       arm-mpidr = <0x80000000>; // MPIDR

What do you think?