[Public]

> -----Original Message-----
> From: Jan Beulich <[email protected]>
> Sent: Monday, August 18, 2025 4:31 PM
> To: Penny, Zheng <[email protected]>; Oleksii Kurochko
> <[email protected]>
> Cc: Huang, Ray <[email protected]>; Andrew Cooper
> <[email protected]>; Roger Pau MonnĂ© <[email protected]>;
> Anthony PERARD <[email protected]>; Orzel, Michal
> <[email protected]>; Julien Grall <[email protected]>; Stefano Stabellini
> <[email protected]>; [email protected]
> 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 <[email protected]>
> > Signed-off-by: Penny Zheng <[email protected]>
>
> 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.

>
> Jan

Reply via email to