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
