Re: [PATCH] xen/x86: move domctl.o out of PV_SHIM_EXCLUSIVE

[Oleksii Kurochko <oleksii.kurochko@xxxxxxxxx>]

On 8/18/25 10:31 AM, Jan Beulich wrote:

> On 15.08.2025 12:27, Penny Zheng wrote:
> > In order to fix CI error of a randconfig picking both PV_SHIM_EXCLUSIVE=y and
> > HVM=y results in hvm.c being built, but domctl.c not being built, which leaves
> > a few functions, like domctl_lock_acquire/release() undefined, causing linking
> > to fail.
> > To fix that, we intend to move domctl.o out of the PV_SHIM_EXCLUSIVE Makefile
> > /hypercall-defs section, with this adjustment, we also need to release
> > redundant vnuma_destroy() stub definition from PV_SHIM_EXCLUSIVE guardian,
> > to not break compilation
> > Above change will leave dead code in the shim binary temporarily and will be
> > fixed with the introduction of domctl-op wrapping.
> >       
> Well, "temporarily" is now getting interesting. While v1 of "Introduce
> CONFIG_DOMCTL" was submitted in time to still be eligible for taking into
> 4.21, that - as indicated elsewhere - is moving us further in an unwanted
> direction.
>     
Do you mean that specifically this patch or the whole patch series is moving us
in unwanted direction? (1)


>  Hence I'm not sure this can even be counted as an in-time
> submission. Plus it looks to be pretty extensive re-work in some areas.
>     
It doesn't clear based on change log why this patch is sent outside "Introduce
CONFIG_DOMCTL" (2) as it looks the same as in (2) and it was reverted once with
the reason "for breaking the x86 build". (I haven't checked what was changed so
it won't lead to build issue again.)

> Hence I'm somewhat weary as to 4.21 here. IOW question, mainly to Oleksii,
> is whether to
> 1) strive to complete that work in time (and hence take the patch here),
> 2) take the patch here, accepting the size regression for the shim, or
> 3) revert what has caused the randconfig issues, and retry the effort in
>    4.22.
>
>     
In the current context, I think I prefer option 3.
However, if option 1 is possible, it could also be considered—except in the
case where the answer to (1) is that the whole patch series is moving us in
an unwanted direction. In that situation, IMO, only option 3 remains viable.

> > Fixes: 568f806cba4c ("xen/x86: remove "depends on !PV_SHIM_EXCLUSIVE"")
> > Reported-by: Jan Beulich <jbeulich@xxxxxxxx>
> > Signed-off-by: Penny Zheng <Penny.Zheng@xxxxxxx>
> >       
> My earlier question (when the patch still was part of a series) sadly has
> remained unanswered: You've run this through a full round of testing this
> time?
>
> Jan
>