[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH v4] x86: make Viridian support optional
- To: Jan Beulich <jbeulich@xxxxxxxx>, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
- From: Grygorii Strashko <grygorii_strashko@xxxxxxxx>
- Date: Wed, 24 Sep 2025 13:13:52 +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=BZh24mg9yneXZeRrOk1njoyYCQYbTxK2zbMrRvHMnjY=; b=UYRimua3/ySGwrK997sD6LlZPGFlVyp0wWWFOuDYLJYow0Sr4XLZhIx3P/CoSP7RkphGs0vsjPu7FbtRl+HumRLB72W26x9C56uOTZPi+zCieMNayCoWUOTtQkE9KtRi0+5ORxwcPMsuPzObFAlg1VFESVbvJE8opHuAnHPKPe8332llr+XU768oCEdu60BWdT5a6h1VOdMpWHhyfdefDx0rl0dyirrD3Df2I52oXh9tYSG9N4A9mgAMEFMzC4cpN0FfY7rCUEBwsE1nDuqhFdU4/YOIF9IKzT9x89byoiMii1VY0skK9wrw7QWKBKforiGKTggIEzJt6beMGjd9gw==
- Arc-seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=ER76Dphd3IiRw99mTfBAdZYmZV6B4SqyBNFdYYnwsUD+ZJdSRgjnPfEkyBzfJ6Vg+u0D7jv7xgRoe3lm7fdBpjLXbC9QGOKzc59gRwApNs2XN/0W1VVqDbPGkov+xGgxe1KssK9mM4reYhi+fHmrL+f+6aka/+wfxmdfpm965u4zFxPazXX4Qu8pnXuGeGuCaTeoRNXKStclL4H8qevFANLDIpJD3V1gdAW+/VfiNCN3XlLfYzVXWplOjFCm1Hv75SeDtpUqqxRHC25brvOlS5g70pHJdigLw15UvEaFf1nggX5M/gjKMEz5o9ZgYgnWegr5aKmp34DusgaH8DGr8g==
- Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=epam.com;
- Cc: Sergiy Kibrik <Sergiy_Kibrik@xxxxxxxx>, Roger Pau Monné <roger.pau@xxxxxxxxxx>, Paul Durrant <paul@xxxxxxx>, Alejandro Vallejo <alejandro.garciavallejo@xxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>
- Delivery-date: Wed, 24 Sep 2025 10:14:06 +0000
- List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
On 19.09.25 23:49, Jan Beulich wrote:
On 19.09.2025 18:31, Grygorii Strashko wrote:
--- a/xen/arch/x86/hvm/Kconfig
+++ b/xen/arch/x86/hvm/Kconfig
@@ -62,6 +62,17 @@ config ALTP2M
If unsure, stay with defaults.
+config VIRIDIAN
+ bool "Hyper-V enlightenments for guests" if EXPERT
+ depends on AMD_SVM || INTEL_VMX
Looks like either there was a misunderstanding, or I wasn't clear enough.
Here the dependency should strictly be HVM. If anything, the dependency
above could appear for HVM (but as said, as of now it's deliberately not
there).
Sorry, I misunderstood you. I'll drop above "depends on".
@@ -1136,6 +1136,9 @@ static int cf_check viridian_load_domain_ctxt(
struct viridian_domain *vd = d->arch.hvm.viridian;
struct hvm_viridian_domain_context ctxt;
+ if ( !is_viridian_domain(d) )
+ return 0;
+
if ( hvm_load_entry_zeroextend(VIRIDIAN_DOMAIN, h, &ctxt) != 0 )
return -EINVAL;
@@ -1172,6 +1175,9 @@ static int cf_check viridian_load_vcpu_ctxt(
struct vcpu *v;
struct hvm_viridian_vcpu_context ctxt;
+ if ( !is_viridian_domain(d) )
+ return 0;
I don't think we should let these go through, but rather flag an error.
And perhaps an intentionally exotic one (e.g. EILSEQ or something yet
more "odd").
Most of existing load_x() returns -ENODEV (for example pit_load() for
!has_vpit()).
Some -EOPNOTSUPP.
I'd be very much appreciated if you could explicitly specify err code to be
used.
-EILSEQ? or -ENODEV? or ..
--
Best regards,
-grygorii
|
