[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH v4 19/24] xen/domctl: wrap hvm_save{,load} with CONFIG_MGMT_HYPERCALLS
- To: Jan Beulich <jbeulich@xxxxxxxx>, Penny Zheng <Penny.Zheng@xxxxxxx>
- From: Grygorii Strashko <grygorii_strashko@xxxxxxxx>
- Date: Tue, 25 Nov 2025 18:30:08 +0200
- 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=1fYYWaji9e4TuksCboL6iP1HajnxgH2P8fbiA+Ip9B4=; b=NcqTVKkOWFAvYRa0jVg7/+XkVk3tlPR01MEqXy8TVvZluiVpDG4sn1G21izReDXnR/K0i5ZXAAwo21+VAF4Wu5fcoC+Quzm4Vn3Qz4zS05I8T74Ck7LgarX+v5y6tejoOxSN2n7aG3RwZpNycf02e5/DeY0lD+tVQGVgbQytOUNQcmUZXEBLOdr/xMq8bOx0P59IKnhYI/m6e0989rzTEEX1XafNxUSVNuskl0SPdS07ZRAQkGLVWnOB6t/eTIHN6GQaLYssDy9Bjd2ctg7Z1o/u5h4SDBUFGzL6ctXxJPHnahS/bA+ap9y9K2SGqJtrAi7hqEFopwIQEEIJuAWxvg==
- Arc-seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=wRgMLTni9sXliXI4y0doPAwKKr/BdWLmyllPAAwgRR0LSjYaQ9QA2cXkSWKJRLddQ/2ysxzvxI8qwND81N2/Lg9GveDg4E5cSEWNAQuezX8HiN2bm6ZvWn/a70M4+D99p2h3J5SnX4Mw4ewTwLD76Au/aZnogBQo5bqEm9OVMU67SHPggLCMY8JnUDVHdMKKZhamXTQ/SrEh+3PX2Pxs7XDotD2F/GyDZ5XcwYO5oiPWKD6V5R7nCU5HFgA7mvke5z1Xz/jMYzmheD0ngs7AYatFEcwpk4vjqRfgYLtGPHsna3WCbS2nk9OOZML5y7dbKLu5xZdKd9muYZzTClsu9A==
- Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=epam.com;
- Cc: ray.huang@xxxxxxx, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, Roger Pau Monné <roger.pau@xxxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxxx
- Delivery-date: Tue, 25 Nov 2025 16:30:27 +0000
- List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
Hi Jan, Penny,
On 25.11.25 17:59, Jan Beulich wrote:
On 21.11.2025 11:57, Penny Zheng wrote:
The following functions have been referenced in places which is either guarded
with CONFIG_MGMT_HYPERCALLS or CONFIG_MEM_SHARING:
- arch_hvm_save
- arch_hvm_check
- arch_hvm_load
- hvm_save_size
- hvm_save
- hvm_load
While CONFIG_MEM_SHARING is also dependent on CONFIG_MGMT_HYPERCALLS.
So they shall be wrapped under MGMT_HYPERCALLS, otherwise they will become
unreachable codes when MGMT_HYPERCALLS=n, and hence violating Misra rule 2.1.
We move arch_hvm_save(), arch_hvm_check(), arch_hvm_load() and hvm_save_size()
nearer to the left functions, to avoid scattered #ifdef-wrapping.
Why would you move things? What is in this source file that is of any use when
MGMT_HYPERCALLS=n? The only caller of hvm_save_one() lives in x86/domctl.c. With
that also removed, hvm_sr_handlers[] is only ever written to afaict, which means
that's an effectively dead array then too.
The final few functions ...
@@ -390,6 +391,7 @@ int hvm_load(struct domain *d, bool real,
hvm_domain_context_t *h)
/* Not reached */
}
+#endif /* CONFIG_MGMT_HYPERCALLS */
int _hvm_init_entry(struct hvm_domain_context *h, uint16_t tc, uint16_t inst,
uint32_t len)
... here and below are only helpers for the save/restore machinery, i.e. that
_all_ is also usable only when MGMT_HYPERCALLS=y. Yes, that's a lot of further
work, but what do you do? You'll then have quite a bit more code removed from
the set that as per coverage analysis is never reached.
I have a local patch which allows to disable all HVM save/load code at once by
using
separated Kconfig option SAVE_RESTORE.
+++ b/xen/arch/x86/hvm/Kconfig
@@ -127,4 +127,8 @@ config VHPET
+config SAVE_RESTORE
+ depends on MGMT_HYPERCALLS
+ def_bool y
SAVE_RESTORE - annotates all HVM save/load code and, in general, could made a
feature by
allowing it to be selectable.
Of course, It all can be done by just using MGMT_HYPERCALLS.
So, I'd be appreciated for you opinion - does it make sense to have separate
SAVE_RESTORE?
--
Best regards,
-grygorii
|
