[PATCH 0/3] Change XEN_DOMCTL_setvcpuaffinity interface

[PATCH 0/3] Change XEN_DOMCTL_setvcpuaffinity interface

[Juergen Gross]

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.

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.

Juergen Gross (3):
  tools/libxl: don't rely on xc_vcpu_setaffinity() returned cpumaps
  xen: don't let XEN_DOMCTL_setvcpuaffinity return the new affinities
  tools/libxenctrl: rename parameters of xc_vcpu_setaffinity()

 tools/include/xenctrl.h        | 26 +++++-----------------
 tools/libs/ctrl/xc_domain.c    | 26 ++++++++++------------
 tools/libs/light/libxl_sched.c |  9 ++++++++
 xen/common/sched/core.c        | 40 ++++++++--------------------------
 xen/include/public/domctl.h    |  9 ++------
 5 files changed, 38 insertions(+), 72 deletions(-)

-- 
2.54.0

[PATCH 1/3] tools/libxl: don't rely on xc_vcpu_setaffinity() returned cpumaps

[Juergen Gross]

In order to prepare for XEN_DOMCTL_setvcpuaffinity no longer returning
the effective affinity settings, use xc_vcpu_getaffinity() for getting
the effective affinities after having set them.

Signed-off-by: Juergen Gross <jgross@suse.com>
---
 tools/libs/light/libxl_sched.c | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/tools/libs/light/libxl_sched.c b/tools/libs/light/libxl_sched.c
index 2d6635dae7..2f6a70aef5 100644
--- a/tools/libs/light/libxl_sched.c
+++ b/tools/libs/light/libxl_sched.c
@@ -69,6 +69,15 @@ static int libxl__set_vcpuaffinity(libxl_ctx *ctx, uint32_t domid,
      * is possible that Xen will use something different from what we asked
      * for various reasons. If that's the case, report it.
      */
+    if ((cpumap_hard || cpumap_soft) &&
+        xc_vcpu_getaffinity(ctx->xch, domid, vcpuid,
+                            cpumap_hard ? hard.map : NULL,
+                            cpumap_soft ? soft.map : NULL,
+                            flags & ~XEN_VCPUAFFINITY_FORCE)) {
+        LOGED(ERROR, domid, "Checking vcpu affinity");
+        rc = ERROR_FAIL;
+        goto out;
+    }
     if (cpumap_hard &&
         !libxl_bitmap_equal(cpumap_hard, &hard, 0))
         LOGD(DEBUG, domid, "New hard affinity for vcpu %d has unreachable cpus", vcpuid);
-- 
2.54.0

[PATCH 2/3] xen: don't let XEN_DOMCTL_setvcpuaffinity return the new affinities

[Juergen Gross]

There is no in-tree user of XEN_DOMCTL_setvcpuaffinity left relying on
the returned effective affinity settings.

Drop returning the new affinities, as any error occurring for that
will be reported to the user, while the affinities won't be changed
back to what they were. This would result in the caller believing
that the affinity was not modified, while it might have been.

Fix a comment typo while modifying vcpu_affinity_domctl().

Signed-off-by: Juergen Gross <jgross@suse.com>
---
 xen/common/sched/core.c     | 40 +++++++++----------------------------
 xen/include/public/domctl.h |  9 ++-------
 2 files changed, 11 insertions(+), 38 deletions(-)

diff --git a/xen/common/sched/core.c b/xen/common/sched/core.c
index 3609721426..1611e60020 100644
--- a/xen/common/sched/core.c
+++ b/xen/common/sched/core.c
@@ -1708,7 +1708,7 @@ int vcpu_affinity_domctl(struct domain *d, uint32_t cmd,
 {
     struct vcpu *v;
     const struct sched_unit *unit;
-    int ret = 0, hret = 0;
+    int ret = 0;
 
     if ( vcpuaff->vcpu >= d->max_vcpus )
         return -EINVAL;
@@ -1724,12 +1724,11 @@ int vcpu_affinity_domctl(struct domain *d, uint32_t cmd,
     if ( cmd == XEN_DOMCTL_setvcpuaffinity )
     {
         cpumask_var_t new_affinity, old_affinity;
-        cpumask_t *online = cpupool_domain_master_cpumask(v->domain);
 
         /*
          * We want to be able to restore hard affinity if we are trying
          * setting both and changing soft affinity (which happens later,
-         * when hard affinity has been succesfully chaged already) fails.
+         * when hard affinity has been successfully changed already) fails.
          */
         if ( !alloc_cpumask_var(&old_affinity) )
             return -ENOMEM;
@@ -1746,25 +1745,14 @@ int vcpu_affinity_domctl(struct domain *d, uint32_t cmd,
         if ( vcpuaff->flags & XEN_VCPUAFFINITY_FORCE )
             vcpu_temporary_affinity(v, NR_CPUS, VCPU_AFFINITY_OVERRIDE);
 
-        /*
-         * We both set a new affinity and report back to the caller what
-         * the scheduler will be effectively using.
-         */
         if ( vcpuaff->flags & XEN_VCPUAFFINITY_HARD )
         {
-            hret = xenctl_bitmap_to_bitmap(cpumask_bits(new_affinity),
+            ret = xenctl_bitmap_to_bitmap(cpumask_bits(new_affinity),
                                            &vcpuaff->cpumap_hard, nr_cpu_ids);
-            if ( !hret )
-                hret = vcpu_set_hard_affinity(v, new_affinity);
-            if ( hret )
+            if ( !ret )
+                ret = vcpu_set_hard_affinity(v, new_affinity);
+            if ( ret )
                 goto setvcpuaffinity_out;
-
-            /*
-             * For hard affinity, what we return is the intersection of
-             * cpupool's online mask and the new hard affinity.
-             */
-            cpumask_and(new_affinity, online, unit->cpu_hard_affinity);
-            hret = cpumask_to_xenctl_bitmap(&vcpuaff->cpumap_hard, new_affinity);
         }
         if ( vcpuaff->flags & XEN_VCPUAFFINITY_SOFT )
         {
@@ -1782,17 +1770,7 @@ int vcpu_affinity_domctl(struct domain *d, uint32_t cmd,
                  */
                 if ( vcpuaff->flags & XEN_VCPUAFFINITY_HARD )
                     vcpu_set_hard_affinity(v, old_affinity);
-                goto setvcpuaffinity_out;
             }
-
-            /*
-             * For soft affinity, we return the intersection between the
-             * new soft affinity, the cpupool's online map and the (new)
-             * hard affinity.
-             */
-            cpumask_and(new_affinity, new_affinity, online);
-            cpumask_and(new_affinity, new_affinity, unit->cpu_hard_affinity);
-            ret = cpumask_to_xenctl_bitmap(&vcpuaff->cpumap_soft, new_affinity);
         }
 
  setvcpuaffinity_out:
@@ -1802,14 +1780,14 @@ int vcpu_affinity_domctl(struct domain *d, uint32_t cmd,
     else
     {
         if ( vcpuaff->flags & XEN_VCPUAFFINITY_HARD )
-            hret = cpumask_to_xenctl_bitmap(&vcpuaff->cpumap_hard,
+            ret = cpumask_to_xenctl_bitmap(&vcpuaff->cpumap_hard,
                                             unit->cpu_hard_affinity);
-        if ( vcpuaff->flags & XEN_VCPUAFFINITY_SOFT )
+        if ( !ret && vcpuaff->flags & XEN_VCPUAFFINITY_SOFT )
             ret = cpumask_to_xenctl_bitmap(&vcpuaff->cpumap_soft,
                                            unit->cpu_soft_affinity);
     }
 
-    return hret ?: ret;
+    return ret;
 }
 
 bool alloc_affinity_masks(struct affinity_masks *affinity)
diff --git a/xen/include/public/domctl.h b/xen/include/public/domctl.h
index cdf350a290..906d2c59d0 100644
--- a/xen/include/public/domctl.h
+++ b/xen/include/public/domctl.h
@@ -357,13 +357,8 @@ struct xen_domctl_vcpuaffinity {
     /*
      * IN/OUT variables.
      *
-     * Both are IN/OUT for XEN_DOMCTL_setvcpuaffinity, in which case they
-     * contain effective hard or/and soft affinity. That is, upon successful
-     * return, cpumap_soft, contains the intersection of the soft affinity,
-     * hard affinity and the cpupool's online CPUs for the domain (if
-     * XEN_VCPUAFFINITY_SOFT was set in flags). cpumap_hard contains the
-     * intersection between hard affinity and the cpupool's online CPUs (if
-     * XEN_VCPUAFFINITY_HARD was set in flags).
+     * Both are IN-only for XEN_DOMCTL_setvcpuaffinity, in which case they
+     * contain effective hard or/and soft affinity.
      *
      * Both are OUT-only for XEN_DOMCTL_getvcpuaffinity, in which case they
      * contain the plain hard and/or soft affinity masks that were set during
-- 
2.54.0

[PATCH 3/3] tools/libxenctrl: rename parameters of xc_vcpu_setaffinity()

[Juergen Gross]

The cpumaps passed to xc_vcpu_setaffinity() are input-only now, so
drop the "_inout" suffix from their names and make them const.

Signed-off-by: Juergen Gross <jgross@suse.com>
---
 tools/include/xenctrl.h     | 26 ++++++--------------------
 tools/libs/ctrl/xc_domain.c | 26 ++++++++++++--------------
 2 files changed, 18 insertions(+), 34 deletions(-)

diff --git a/tools/include/xenctrl.h b/tools/include/xenctrl.h
index d5dbf69c89..96fb0cc81f 100644
--- a/tools/include/xenctrl.h
+++ b/tools/include/xenctrl.h
@@ -590,37 +590,23 @@ int xc_domain_node_getaffinity(xc_interface *xch,
  * There are two kinds of affinity. Soft affinity is on what CPUs a vcpu
  * prefers to run. Hard affinity is on what CPUs a vcpu is allowed to run.
  * If flags contains XEN_VCPUAFFINITY_SOFT, the soft affinity it is set to
- * what cpumap_soft_inout contains. If flags contains XEN_VCPUAFFINITY_HARD,
- * the hard affinity is set to what cpumap_hard_inout contains. Both flags
+ * what cpumap_soft contains. If flags contains XEN_VCPUAFFINITY_HARD,
+ * the hard affinity is set to what cpumap_hard contains. Both flags
  * can be set at the same time, in which case both soft and hard affinity are
  * set to what the respective parameter contains.
  *
- * The function also returns the effective hard or/and soft affinity, still
- * via the cpumap_soft_inout and cpumap_hard_inout parameters. Effective
- * affinity is, in case of soft affinity, the intersection of soft affinity,
- * hard affinity and the cpupool's online CPUs for the domain, and is returned
- * in cpumap_soft_inout, if XEN_VCPUAFFINITY_SOFT is set in flags. In case of
- * hard affinity, it is the intersection between hard affinity and the
- * cpupool's online CPUs, and is returned in cpumap_hard_inout, if
- * XEN_VCPUAFFINITY_HARD is set in flags. If both flags are set, both soft
- * and hard affinity are returned in the respective parameter.
- *
- * We do report it back as effective affinity is what the Xen scheduler will
- * actually use, and we thus allow checking whether or not that matches with,
- * or at least is good enough for, the caller's purposes.
- *
  * @param xch a handle to an open hypervisor interface.
  * @param domid the id of the domain to which the vcpu belongs
  * @param vcpu the vcpu id wihin the domain
- * @param cpumap_hard_inout specifies(/returns) the (effective) hard affinity
- * @param cpumap_soft_inout specifies(/returns) the (effective) soft affinity
+ * @param cpumap_hard specifies the hard affinity
+ * @param cpumap_soft specifies the soft affinity
  * @param flags what we want to set
  */
 int xc_vcpu_setaffinity(xc_interface *xch,
                         uint32_t domid,
                         int vcpu,
-                        xc_cpumap_t cpumap_hard_inout,
-                        xc_cpumap_t cpumap_soft_inout,
+                        const xc_cpumap_t cpumap_hard,
+                        const xc_cpumap_t cpumap_soft,
                         uint32_t flags);
 
 /**
diff --git a/tools/libs/ctrl/xc_domain.c b/tools/libs/ctrl/xc_domain.c
index 01c0669c88..3ee0e43ea5 100644
--- a/tools/libs/ctrl/xc_domain.c
+++ b/tools/libs/ctrl/xc_domain.c
@@ -199,15 +199,13 @@ int xc_domain_node_getaffinity(xc_interface *xch,
 int xc_vcpu_setaffinity(xc_interface *xch,
                         uint32_t domid,
                         int vcpu,
-                        xc_cpumap_t cpumap_hard_inout,
-                        xc_cpumap_t cpumap_soft_inout,
+                        const xc_cpumap_t cpumap_hard,
+                        const xc_cpumap_t cpumap_soft,
                         uint32_t flags)
 {
     struct xen_domctl domctl = {};
-    DECLARE_HYPERCALL_BOUNCE(cpumap_hard_inout, 0,
-                             XC_HYPERCALL_BUFFER_BOUNCE_BOTH);
-    DECLARE_HYPERCALL_BOUNCE(cpumap_soft_inout, 0,
-                             XC_HYPERCALL_BUFFER_BOUNCE_BOTH);
+    DECLARE_HYPERCALL_BOUNCE(cpumap_hard, 0, XC_HYPERCALL_BUFFER_BOUNCE_IN);
+    DECLARE_HYPERCALL_BOUNCE(cpumap_soft, 0, XC_HYPERCALL_BUFFER_BOUNCE_IN);
     int ret = -1;
     int cpusize;
 
@@ -218,11 +216,11 @@ int xc_vcpu_setaffinity(xc_interface *xch,
         return -1;
     }
 
-    HYPERCALL_BOUNCE_SET_SIZE(cpumap_hard_inout, cpusize);
-    HYPERCALL_BOUNCE_SET_SIZE(cpumap_soft_inout, cpusize);
+    HYPERCALL_BOUNCE_SET_SIZE(cpumap_hard, cpusize);
+    HYPERCALL_BOUNCE_SET_SIZE(cpumap_soft, cpusize);
 
-    if ( xc_hypercall_bounce_pre(xch, cpumap_hard_inout) ||
-         xc_hypercall_bounce_pre(xch, cpumap_soft_inout) )
+    if ( xc_hypercall_bounce_pre(xch, cpumap_hard) ||
+         xc_hypercall_bounce_pre(xch, cpumap_soft) )
     {
         PERROR("Could not allocate hcall buffers for DOMCTL_setvcpuaffinity");
         goto out;
@@ -234,17 +232,17 @@ int xc_vcpu_setaffinity(xc_interface *xch,
     domctl.u.vcpuaffinity.flags = flags;
 
     set_xen_guest_handle(domctl.u.vcpuaffinity.cpumap_hard.bitmap,
-                         cpumap_hard_inout);
+                         cpumap_hard);
     domctl.u.vcpuaffinity.cpumap_hard.nr_bits = cpusize * 8;
     set_xen_guest_handle(domctl.u.vcpuaffinity.cpumap_soft.bitmap,
-                         cpumap_soft_inout);
+                         cpumap_soft);
     domctl.u.vcpuaffinity.cpumap_soft.nr_bits = cpusize * 8;
 
     ret = do_domctl(xch, &domctl);
 
  out:
-    xc_hypercall_bounce_post(xch, cpumap_hard_inout);
-    xc_hypercall_bounce_post(xch, cpumap_soft_inout);
+    xc_hypercall_bounce_post(xch, cpumap_hard);
+    xc_hypercall_bounce_post(xch, cpumap_soft);
 
     return ret;
 }
-- 
2.54.0

Re: [PATCH 0/3] Change XEN_DOMCTL_setvcpuaffinity interface

[Jan Beulich]

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.

Jan

Re: [PATCH 0/3] Change XEN_DOMCTL_setvcpuaffinity interface

[Andrew Cooper]

On 01/07/2026 12:39 pm, 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.

How does the effective setting differ from what's passed in?

I hadn't even realised that we pass data out of the set op, and it does
smell of bad API design.

While we do care about the domctl lock, I don't consider "extra pressure
on it" as a valid argument to be used here.  It's an internal detail,
whereas the hypercall API is an external detail.

~Andrew

Re: [PATCH 0/3] Change XEN_DOMCTL_setvcpuaffinity interface

[Jürgen Groß]

[-- Attachment #1.1.1: Type: text/plain, Size: 1941 bytes --]

On 01.07.26 13:45, Andrew Cooper wrote:
> On 01/07/2026 12:39 pm, 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.
> 
> How does the effective setting differ from what's passed in?

The hard affinity might differ in case the target domain is in a cpupool
not covering the whole machine and e.g. "all" is passed on input. The
effective setting will have only the CPUs of the cpupool set.

> I hadn't even realised that we pass data out of the set op, and it does
> smell of bad API design.

Yes, especially as the data is used only by one caller for verification.

> While we do care about the domctl lock, I don't consider "extra pressure
> on it" as a valid argument to be used here.  It's an internal detail,
> whereas the hypercall API is an external detail.


Juergen

[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 3743 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 495 bytes --]

Re: [PATCH 0/3] Change XEN_DOMCTL_setvcpuaffinity interface

[Jürgen Groß]

[-- Attachment #1.1.1: Type: text/plain, Size: 1574 bytes --]

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).

For not needing the domctl lock the XEN_DOMCTL_getvcpuaffinity path
would need to take the unit lock, too.


Juergen

[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 3743 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 495 bytes --]

Re: [PATCH 0/3] Change XEN_DOMCTL_setvcpuaffinity interface

[Jan Beulich]

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

Re: [PATCH 0/3] Change XEN_DOMCTL_setvcpuaffinity interface

[Jürgen Groß]

[-- Attachment #1.1.1: Type: text/plain, Size: 2480 bytes --]

On 01.07.26 15:48, Jan Beulich wrote:
> 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.

Hmm, while I understand why this would be nice, I'm having a hard time
imagining a sane scenario where two or more instances are issuing
hypercalls for changing affinities. At least one of those instances will
not be happy afterwards, in case the lock is split both might by unhappy.

I don't see this being a substantial downside, as the main problem would
be on the user side allowing multiple concurrent affinity changes for
the same vcpu(s).

OTOH it would be quite easy to merge both affinity settings into one
locked region, as the underlying function sched_set_affinity() can be
called with both affinity masks or with only one of them. This would
require only a minor reorg of the affinity helpers.


Juergen

[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 3743 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 495 bytes --]

Re: [PATCH 0/3] Change XEN_DOMCTL_setvcpuaffinity interface

[Juergen Gross]

[-- Attachment #1.1.1: Type: text/plain, Size: 674 bytes --]

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.

The possible -ENOMEM isn't the callers fault, though.


Juergen

[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 3743 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 495 bytes --]

Re: [PATCH 0/3] Change XEN_DOMCTL_setvcpuaffinity interface

[Jan Beulich]

On 01.07.2026 17:34, Juergen Gross 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.
> 
> The possible -ENOMEM isn't the callers fault, though.

Yet that'll happen ahead of any changes made, won't it?

Jan

Re: [PATCH 0/3] Change XEN_DOMCTL_setvcpuaffinity interface

[Jürgen Groß]

[-- Attachment #1.1.1: Type: text/plain, Size: 926 bytes --]

On 02.07.26 07:54, Jan Beulich wrote:
> On 01.07.2026 17:34, Juergen Gross 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.
>>
>> The possible -ENOMEM isn't the callers fault, though.
> 
> Yet that'll happen ahead of any changes made, won't it?

No, it can happen during the final call of cpumask_to_xenctl_bitmap().


Juergen

[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 3743 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 495 bytes --]

Re: [PATCH 0/3] Change XEN_DOMCTL_setvcpuaffinity interface

[Jan Beulich]

On 02.07.2026 08:13, Jürgen Groß wrote:
> On 02.07.26 07:54, Jan Beulich wrote:
>> On 01.07.2026 17:34, Juergen Gross 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.
>>>
>>> The possible -ENOMEM isn't the callers fault, though.
>>
>> Yet that'll happen ahead of any changes made, won't it?
> 
> No, it can happen during the final call of cpumask_to_xenctl_bitmap().

Only hypothetically, on a big-endian architecture (which we don't currently
have support for anywhere, hence why the little endian special case was
added there).

Jan

Re: [PATCH 0/3] Change XEN_DOMCTL_setvcpuaffinity interface

[Juergen Gross]

[-- Attachment #1.1.1: Type: text/plain, Size: 1243 bytes --]

On 02.07.26 08:25, Jan Beulich wrote:
> On 02.07.2026 08:13, Jürgen Groß wrote:
>> On 02.07.26 07:54, Jan Beulich wrote:
>>> On 01.07.2026 17:34, Juergen Gross 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.
>>>>
>>>> The possible -ENOMEM isn't the callers fault, though.
>>>
>>> Yet that'll happen ahead of any changes made, won't it?
>>
>> No, it can happen during the final call of cpumask_to_xenctl_bitmap().
> 
> Only hypothetically, on a big-endian architecture (which we don't currently
> have support for anywhere, hence why the little endian special case was
> added there).

Oh, indeed.


Juergen

[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 3743 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 495 bytes --]