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 <jbeul...@suse.com>
> Signed-off-by: Penny Zheng <penny.zh...@amd.com>
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
