[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [PATCH] xen/x86: move domctl.o out of PV_SHIM_EXCLUSIVE
On 22.08.2025 02:10, Stefano Stabellini wrote: > 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. Should I translate this to Tested-by: then? Jan
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |