On 23.07.2025 08:53, Penny Zheng wrote:
> Not only domctl-op could do foreign updates to guest state, some hypercall,
> like HVMOP_set_param, could also do, and they all need domctl_lock for
> syncronization.
What's "all" here? HVMOP_set_param is the sole such case, and hence - aiui -
it uses the domctl lock only to lock out actual domctl-s. Of which there are
not going to be any with DOMCTL=n, ...
> Later, we will introduce CONFIG_DOMCTL to wrap domctl.c. In order to
> continue using domctl_lock when CONFIG_DOMCTL not defined, we'd like to move
> domctl_lock_acquire/release() out of domctl.c, and into more common space,
> domain.c
... as you indicate is where we're going to move to as a possibility. Hence
the domctl lock is meaningless without DOMCTL=y. At which point moving it out
of domctl.c is the wrong course of action. With DOMCTL=n, we'll rather need
stub domctl_lock_{acquire,release}(), which then likely would do nothing (or
alternatively "#ifdef CONFIG_DOMCTL" could be put around the two uses in
hvm_set_param()).
> The movement could also 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 domctl_lock_acquire/release()
> undefined, causing linking to fail.
If the work towards DOMCTL as a Kconfig control can't be progressed pretty
quickly (and I don't expect that to be much faster than the SYSCTL work),
then I expect our prime option (apart from reverting the earlier change) is
to accept a bunch of dead code in the shim binary again, by moving domctl.o
out of the PV_SHIM_EXCLUSIVE common/Makefile section as well (plus whatever
other adjustments are necessary to undo that earlier dead code elimination).
Jan
