|
[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 |