Re: [PATCH 0/3] Change XEN_DOMCTL_setvcpuaffinity interface

[Jan Beulich <jbeulich@suse.com>]

On 01.07.2026 15:08, Jürgen Groß wrote:
> On 01.07.26 13:39, Jan Beulich wrote:
>> On 01.07.2026 13:16, Juergen Gross wrote:
>>> Today the XEN_DOMCTL_setvcpuaffinity hypercall will not only change the
>>> affinity settings of a vcpu, it will return the new effective settings,
>>> too.
>>>
>>> In case an error happens during this hypercall, the expectation of the
>>> caller is that the affinity of the vcpu didn't change. This isn't true,
>>> however, if passing the new effective affinity back to the user is
>>> failing.
>>
>> That'll be the caller's fault though. Any -EFAULT coming back are an
>> indication that the caller needs fixing.
>>
>>> Instead of making error handling in the hypervisor even more complex,
>>> just change the interface by NOT passing back the new affinity. It can
>>> easily be obtained by another XEN_DOMCTL_getvcpuaffinity call if
>>> needed.
>>
>> At the expense of further increasing the pressure on the domctl lock.
>> When making the recent error code change in this area, I was actually
>> wondering in how far these two sub-ops might also be candidates for
>> moving out of the locked region. Yet with vcpu_affinity_domctl() not
>> using any locking that didn't look entirely straightforward to answer.
> 
> The calling hierarchy for the XEN_DOMCTL_setvcpuaffinity case is:
> 
> vcpu_affinity_domctl()
>    vcpu_set_hard_affinity()
>      vcpu_set_affinity()
>    vcpu_set_affinity()
> 
> vcpu_set_affinity() does the correct locking (takes the unit lock).

But that's not sufficient: The two involved vcpu_set_affinity() calls
want to stay together, i.e. not race with another domctl.

Jan