[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH v2] xen/sched: rtds: re-arm repl_timer after timer re-initialization
- To: Juergen Gross <jgross@xxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>
- From: Oleksii Moisieiev <oleksii_moisieiev@xxxxxxxx>
- Date: Fri, 10 Apr 2026 18:12:08 +0300
- Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=epam.com; dmarc=pass action=none header.from=epam.com; dkim=pass header.d=epam.com; arc=none
- Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=yNuCGUOr1cdp9tsad0r0/l5zdLk78guGqazR5193nIw=; b=I5Xy52mbKB2oJ8prN5nHunHXwPxgBrg3OmEGxU/B3G/TLHhI11i6dyPKTaJhcIvQJu1ZY9gPAVIv0lCyI99AnIdJ80GerUYZH6YHzoi8GDQgtDcYVyxIQjDnD4V12oiGrBMgThFZaEJ8uiCLZshu/Nswk8659nQMI9hromVg841+WXAdivfr17RlalSxZZdBTn5d1+C6qQ8WmDZHKpbrbjcTKABiyhXhNySkKXccaSq5V0QrH40fubuQu6xBeMyRUVb1aRU5oH6bTb0pnwamVROe2KoM55MIiweVjJTbsqXQFW1Nma0YBxfbOpc7eCaFGVopDyzTuXp2umivu0POQg==
- Arc-seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=kATNyPstnasisNN3VRb0twFNTQTIsaLGlZODkMI1CM/ciA9W5CqYHazIDC0dU3XTWRlB2GUpQrMPV6F5J86z2phaaCK8rf6s/BuMpVISkLCM/EZ6BHcMwgkTIHVoGBNqXjDG1DRBIFcicewe3YKBfrkq4EjOeQ+MYESyGrSQMIk6Zzd4MliVVtzZ0ndc+pyYDg72jcg+VvDpvA5mJk2kK0P0y1YVMwy4GOAaPkO4cR4scSfj7ebLZXFAj8mwD2qJkc187D/YZp92EYA0+ziCMstIILJA1qKK6XAoEOpDc9PkZn5VkboPgRom5mzUmnrKGXRcSkhzlECj1gn1BKZUjA==
- Authentication-results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=epam.com header.i="@epam.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck"
- Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=epam.com;
- Cc: Dario Faggioli <dfaggioli@xxxxxxxx>, George Dunlap <gwd@xxxxxxxxxxxxxx>, Meng Xu <mengxu@xxxxxxxxxxxxx>
- Delivery-date: Fri, 10 Apr 2026 15:12:19 +0000
- List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
On 10/04/2026 15:16, Juergen Gross wrote:
On 10.04.26 14:13, Juergen Gross wrote:
On 10.04.26 14:04, Oleksii Moisieiev wrote:
Hi Juergen,
During our safety certification analysis work, we identified this as
a potential
issue. While we haven't encountered this problem in practice yet, it
could occur
in the future, so I believe it should be addressed proactively.
For being able to occur in future, the handling of removing a cpu from a
cpupool would need to be changed. Considering the refusal to remove the
last cpu from a populated cpupool is on purpose (this avoids leaving a
domain without any cpu to run on), adding the code as you suggest would
just be an addition without any benefit.
It isn't doing any harm (other than adding code without purpose), so I
won't explicitly NAK the patch, but I won't Ack it either.
One further remark: I would ack the addition of an
ASSERT(list_empty(replq))
instead of the conditional set_timer() call.
You're right: with the current cpupool semantics, when the timer is
re-initialized in this path, replq is expected to be empty. In that case
there is nothing to re-arm, and the timer can be programmed later when a
new replenishment event is queued.
Now I see that it would probably be better to update the cpupool logic
to prohibit removing the last pCPU from a cpupool. In that case, this
fix — even with the ASSERT — seems to be no longer relevant.
I think I'd rather post an update for the cpupool semantics and drop
this patch. Or I can send a v3 with the ASSERT if you think that is
still reasonable.
Thank you for the review!
--
Oleksii
Juergen
|
