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

[Stefano Stabellini <sstabellini@xxxxxxxxxx>]

On Thu, 21 Aug 2025, Jan Beulich wrote:
> On 20.08.2025 05:12, Penny, Zheng wrote:
> > [Public]
> > 
> >> -----Original Message-----
> >> From: Jan Beulich <jbeulich@xxxxxxxx>
> >> Sent: Monday, August 18, 2025 4:31 PM
> >> To: Penny, Zheng <penny.zheng@xxxxxxx>; Oleksii Kurochko
> >> <oleksii.kurochko@xxxxxxxxx>
> >> Cc: Huang, Ray <Ray.Huang@xxxxxxx>; Andrew Cooper
> >> <andrew.cooper3@xxxxxxxxxx>; Roger Pau Monné <roger.pau@xxxxxxxxxx>;
> >> Anthony PERARD <anthony.perard@xxxxxxxxxx>; Orzel, Michal
> >> <Michal.Orzel@xxxxxxx>; Julien Grall <julien@xxxxxxx>; Stefano Stabellini
> >> <sstabellini@xxxxxxxxxx>; xen-devel@xxxxxxxxxxxxxxxxxxxx
> >> Subject: Re: [PATCH] xen/x86: move domctl.o out of PV_SHIM_EXCLUSIVE
> >>
> >> 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. 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.
> >> 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.
> >>
> >>> 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?
> > 
> > Sorry, missed that, yes, it has been tested with both default defconfig and 
> > allyesconfig.
> 
> I'm sorry if my request was unclear, but with "full round of testing" I in 
> particular
> meant a full CI pipeline, plus (given the issue that's being fixed) some extra
> randconfig testing.

https://gitlab.com/xen-project/people/sstabellini/xen/-/pipelines/1997431361

I ran a few tests myself changing config options on purpose trying to
break it, and so far they were all successful.