| Message ID | 20250321092633.3982645-1-Sergiy_Kibrik@epam.com (mailing list archive) |
|---|---|
| State | New |
| Headers | show |
| Series | [v2] x86: make Viridian support optional | expand |
On Fri Mar 21, 2025 at 9:26 AM GMT, Sergiy Kibrik wrote: > Add config option HVM_VIRIDIAN that covers viridian code within HVM. > Calls to viridian functions guarded by is_viridian_domain() and related macros. > Having this option may be beneficial by reducing code footprint for systems > that are not using Hyper-V. > > Signed-off-by: Sergiy Kibrik <Sergiy_Kibrik@epam.com> > CC: Alejandro Vallejo <alejandro.vallejo@cloud.com> > CC: Jan Beulich <jbeulich@suse.com> > --- > changes in v2: > - changed title in Kconfig & add help text > - moved Kconfig changes to arch/x86/hvm/Kconfig > - address review comments > --- > xen/arch/x86/hvm/Kconfig | 10 ++++++++++ > xen/arch/x86/hvm/Makefile | 2 +- > xen/arch/x86/hvm/hvm.c | 27 ++++++++++++++++++--------- > xen/arch/x86/hvm/vlapic.c | 11 +++++++---- > xen/arch/x86/include/asm/hvm/domain.h | 2 ++ > xen/arch/x86/include/asm/hvm/hvm.h | 3 ++- > xen/arch/x86/include/asm/hvm/vcpu.h | 2 ++ > 7 files changed, 42 insertions(+), 15 deletions(-) LGTM Reviewed-by: Alejandro Vallejo <alejandro.vallejo@cloud.com> Cheers, Alejandro
On 21.03.2025 10:26, Sergiy Kibrik wrote: > Add config option HVM_VIRIDIAN that covers viridian code within HVM. > Calls to viridian functions guarded by is_viridian_domain() and related macros. > Having this option may be beneficial by reducing code footprint for systems > that are not using Hyper-V. > > Signed-off-by: Sergiy Kibrik <Sergiy_Kibrik@epam.com> > CC: Alejandro Vallejo <alejandro.vallejo@cloud.com> > CC: Jan Beulich <jbeulich@suse.com> > --- > changes in v2: > - changed title in Kconfig & add help text > - moved Kconfig changes to arch/x86/hvm/Kconfig > - address review comments > --- > xen/arch/x86/hvm/Kconfig | 10 ++++++++++ > xen/arch/x86/hvm/Makefile | 2 +- > xen/arch/x86/hvm/hvm.c | 27 ++++++++++++++++++--------- > xen/arch/x86/hvm/vlapic.c | 11 +++++++---- > xen/arch/x86/include/asm/hvm/domain.h | 2 ++ > xen/arch/x86/include/asm/hvm/hvm.h | 3 ++- > xen/arch/x86/include/asm/hvm/vcpu.h | 2 ++ > 7 files changed, 42 insertions(+), 15 deletions(-) > > diff --git a/xen/arch/x86/hvm/Kconfig b/xen/arch/x86/hvm/Kconfig > index 2def0f98e2..9cdcc0d3cd 100644 > --- a/xen/arch/x86/hvm/Kconfig > +++ b/xen/arch/x86/hvm/Kconfig > @@ -63,6 +63,16 @@ config ALTP2M > > If unsure, stay with defaults. > > +config HVM_VIRIDIAN > + bool "Hyper-V enlighnments for guests" if EXPERT Nit: "enlightenments" > --- a/xen/arch/x86/include/asm/hvm/hvm.h > +++ b/xen/arch/x86/include/asm/hvm/hvm.h > @@ -507,7 +507,8 @@ hvm_get_cpl(struct vcpu *v) > (has_hvm_params(d) ? (d)->arch.hvm.params[HVM_PARAM_VIRIDIAN] : 0) > > #define is_viridian_domain(d) \ > - (is_hvm_domain(d) && (viridian_feature_mask(d) & HVMPV_base_freq)) > + (IS_ENABLED(CONFIG_HVM_VIRIDIAN) && \ > + is_hvm_domain(d) && (viridian_feature_mask(d) & HVMPV_base_freq)) Nit: Missing an indenting blank on the latter line. Will adjust while committing. Jan
On 21.03.2025 10:26, Sergiy Kibrik wrote: > --- a/xen/arch/x86/hvm/hvm.c > +++ b/xen/arch/x86/hvm/hvm.c > @@ -695,9 +695,12 @@ int hvm_domain_initialise(struct domain *d, > if ( hvm_tsc_scaling_supported ) > d->arch.hvm.tsc_scaling_ratio = hvm_default_tsc_scaling_ratio; > > - rc = viridian_domain_init(d); > - if ( rc ) > - goto fail2; > + if ( is_viridian_domain(d) ) > + { > + rc = viridian_domain_init(d); > + if ( rc ) > + goto fail2; > + } It is, aiui, this conditional initialization which causes (XEN) [ 9.136463] UBSAN: Undefined behaviour in arch/x86/hvm/viridian/viridian.c:1118:43 (XEN) [ 9.136465] member access within null pointer of type 'const struct viridian_domain' (XEN) [ 9.136471] ----[ Xen-4.21-unstable x86_64 debug=y ubsan=y Not tainted ]---- (XEN) [ 9.136473] CPU: 14 (XEN) [ 9.136475] RIP: e008:[<ffff82d04032e8a8>] common/ubsan/ubsan.c#ubsan_epilogue+0xa/0xd9 (XEN) [ 9.136480] RFLAGS: 0000000000010096 CONTEXT: hypervisor (d0v6) (XEN) [ 9.136484] rax: 0000000000000000 rbx: ffff8304761afb40 rcx: 0000000000000868 (XEN) [ 9.136486] rdx: ffff8304761affd0 rsi: 0000000000000004 rdi: ffff8304761afb40 (XEN) [ 9.136488] rbp: ffff8304761afb30 rsp: ffff8304761afb20 r8: 0000000000000006 (XEN) [ 9.136490] r9: 00000000ffffffff r10: 0000000000000000 r11: 0000000000000000 (XEN) [ 9.136493] r12: ffff82d040913d22 r13: 0000000000000003 r14: ffff82d040b237a0 (XEN) [ 9.136495] r15: 000000000000000f cr0: 0000000080050033 cr4: 0000000000b526e0 (XEN) [ 9.136497] cr3: 0000000308528000 cr2: 00007f24a0c9de28 (XEN) [ 9.136499] fsb: 00007f24a3fd6b48 gsb: ffff8881b9b80000 gss: 0000000000000000 (XEN) [ 9.136501] ds: 0000 es: 0000 fs: 0000 gs: 0000 ss: e010 cs: e008 (XEN) [ 9.136505] Xen code around <ffff82d04032e8a8> (common/ubsan/ubsan.c#ubsan_epilogue+0xa/0xd9): (XEN) [ 9.136507] 89 e5 41 54 53 48 89 fb <0f> 0b 48 8d 3d ff 92 37 00 e8 9d 99 00 00 48 85 (XEN) [ 9.136572] Xen stack trace from rsp=ffff8304761afb20: (XEN) [ 9.136574] 0000000000000003 ffff82d040913d22 ffff8304761afb70 ffff82d04032ef58 (XEN) [ 9.136578] 0000000000000202 ffff82d040911100 0000000000000000 0000000000000000 (XEN) [ 9.136581] ffff82d040b237a0 000000000000000f ffff8304761afbd0 ffff82d04032f3af (XEN) [ 9.136585] ffff82d0406b8900 0000002b8000045e ffff82d040913d1e 0000000000000001 (XEN) [ 9.136588] ffff82d040b23703 000000000000000f ffff8304761afbc0 ffff830405d65000 (XEN) [ 9.136592] ffff8304761afd00 0000000000000000 ffff8304761afc18 ffff82d040418b9c (XEN) [ 9.136595] 0000000000000000 0000000000000000 0000000000000000 0000000000000000 (XEN) [ 9.136598] ffff82d040b23a88 00000000000002e8 ffff830401d6cfe0 ffff8304761afc98 (XEN) [ 9.136602] ffff82d04045fc14 00000000000002c0 ffff82d040b23a58 ffff8304761afd00 (XEN) [ 9.136605] ffff82d040418a0a ffff830405d65000 ffff82d040b23a88 0000000154381286 (XEN) [ 9.136609] 0000000000000000 00383ffe00090672 0000000000001c78 fffffffffffffff4 (XEN) [ 9.136612] ffff830476161000 ffff8304761afdb0 ffff830405d65000 ffff8304761afd50 (XEN) [ 9.136616] ffff82d040630690 800000030847e127 0000000000000206 000000000000000e (XEN) [ 9.136619] ffff82d040a00b44 ffff82d040a00b40 ffff82d040a00b44 ffff83047618f000 (XEN) [ 9.136622] 00007f24a3c7a010 ffff8304761afef8 ffff8304761afef8 ffff8304761b5088 (XEN) [ 9.136626] 00001c7800000580 ffff830483a24000 0000000000000001 00007f24a3c7a010 (XEN) [ 9.136629] 0000000000000001 ffff830405d65000 00007f24a3c7a010 0000000000000001 (XEN) [ 9.136633] 0000000000000021 0000000000000000 ffff8304761afe68 ffff82d0402c662f (XEN) [ 9.136636] ffff8304761afd80 ffff82d0405a0fbb ffff830476161000 ffff8881b9b80000 (XEN) [ 9.136640] ffff8304761afdb8 ffff82d04052fdef ffff830476161000 ffff8881b9b80000 (XEN) [ 9.136643] Xen call trace: (XEN) [ 9.136646] [<ffff82d04032e8a8>] R common/ubsan/ubsan.c#ubsan_epilogue+0xa/0xd9 (XEN) [ 9.136648] [<ffff82d04032ef58>] F __ubsan_handle_type_mismatch+0x135/0x48e (XEN) [ 9.136651] [<ffff82d04032f3af>] F __ubsan_handle_type_mismatch_v1+0xfe/0x100 (XEN) [ 9.136655] [<ffff82d040418b9c>] F arch/x86/hvm/viridian/viridian.c#viridian_save_domain_ctxt+0x192/0x204 (XEN) [ 9.136658] [<ffff82d04045fc14>] F hvm_save+0x4d1/0x5c6 (XEN) [ 9.136661] [<ffff82d040630690>] F arch_do_domctl+0x2f8/0x51aa (XEN) [ 9.136664] [<ffff82d0402c662f>] F do_domctl+0xc91/0x460d (XEN) [ 9.136667] [<ffff82d04053ab70>] F pv_hypercall+0x6d6/0x834 (XEN) [ 9.136669] [<ffff82d0402012d3>] F lstar_enter+0x143/0x150 (XEN) [ 9.136671] (XEN) [ 9.136673] ================================================================================ (XEN) [ 9.622282] (XEN) [ 9.624469] **************************************** (XEN) [ 9.630471] Panic on CPU 14: (XEN) [ 9.634182] UBSAN failure detected (XEN) [ 9.638469] **************************************** throughout tests on actual hardware in CI. And really I don't think it's just UB, but rather a real NULL deref: const struct viridian_domain *vd = d->arch.hvm.viridian; struct hvm_viridian_domain_context ctxt = { .hypercall_gpa = vd->hypercall_gpa.raw, .guest_os_id = vd->guest_os_id.raw, }; and only then if ( !is_viridian_domain(d) ) return 0; Makes me wonder if this change was actually tested ... In any event I'm about to revert it. Jan
On 24/03/2025 1:37 pm, Jan Beulich wrote: > On 21.03.2025 10:26, Sergiy Kibrik wrote: >> --- a/xen/arch/x86/hvm/hvm.c >> +++ b/xen/arch/x86/hvm/hvm.c >> @@ -695,9 +695,12 @@ int hvm_domain_initialise(struct domain *d, >> if ( hvm_tsc_scaling_supported ) >> d->arch.hvm.tsc_scaling_ratio = hvm_default_tsc_scaling_ratio; >> >> - rc = viridian_domain_init(d); >> - if ( rc ) >> - goto fail2; >> + if ( is_viridian_domain(d) ) >> + { >> + rc = viridian_domain_init(d); >> + if ( rc ) >> + goto fail2; >> + } > It is, aiui, this conditional initialization which causes > > (XEN) [ 9.136463] UBSAN: Undefined behaviour in arch/x86/hvm/viridian/viridian.c:1118:43 > (XEN) [ 9.136465] member access within null pointer of type 'const struct viridian_domain' > (XEN) [ 9.136471] ----[ Xen-4.21-unstable x86_64 debug=y ubsan=y Not tainted ]---- > (XEN) [ 9.136473] CPU: 14 > (XEN) [ 9.136475] RIP: e008:[<ffff82d04032e8a8>] common/ubsan/ubsan.c#ubsan_epilogue+0xa/0xd9 > (XEN) [ 9.136480] RFLAGS: 0000000000010096 CONTEXT: hypervisor (d0v6) > (XEN) [ 9.136484] rax: 0000000000000000 rbx: ffff8304761afb40 rcx: 0000000000000868 > (XEN) [ 9.136486] rdx: ffff8304761affd0 rsi: 0000000000000004 rdi: ffff8304761afb40 > (XEN) [ 9.136488] rbp: ffff8304761afb30 rsp: ffff8304761afb20 r8: 0000000000000006 > (XEN) [ 9.136490] r9: 00000000ffffffff r10: 0000000000000000 r11: 0000000000000000 > (XEN) [ 9.136493] r12: ffff82d040913d22 r13: 0000000000000003 r14: ffff82d040b237a0 > (XEN) [ 9.136495] r15: 000000000000000f cr0: 0000000080050033 cr4: 0000000000b526e0 > (XEN) [ 9.136497] cr3: 0000000308528000 cr2: 00007f24a0c9de28 > (XEN) [ 9.136499] fsb: 00007f24a3fd6b48 gsb: ffff8881b9b80000 gss: 0000000000000000 > (XEN) [ 9.136501] ds: 0000 es: 0000 fs: 0000 gs: 0000 ss: e010 cs: e008 > (XEN) [ 9.136505] Xen code around <ffff82d04032e8a8> (common/ubsan/ubsan.c#ubsan_epilogue+0xa/0xd9): > (XEN) [ 9.136507] 89 e5 41 54 53 48 89 fb <0f> 0b 48 8d 3d ff 92 37 00 e8 9d 99 00 00 48 85 > (XEN) [ 9.136572] Xen stack trace from rsp=ffff8304761afb20: > (XEN) [ 9.136574] 0000000000000003 ffff82d040913d22 ffff8304761afb70 ffff82d04032ef58 > (XEN) [ 9.136578] 0000000000000202 ffff82d040911100 0000000000000000 0000000000000000 > (XEN) [ 9.136581] ffff82d040b237a0 000000000000000f ffff8304761afbd0 ffff82d04032f3af > (XEN) [ 9.136585] ffff82d0406b8900 0000002b8000045e ffff82d040913d1e 0000000000000001 > (XEN) [ 9.136588] ffff82d040b23703 000000000000000f ffff8304761afbc0 ffff830405d65000 > (XEN) [ 9.136592] ffff8304761afd00 0000000000000000 ffff8304761afc18 ffff82d040418b9c > (XEN) [ 9.136595] 0000000000000000 0000000000000000 0000000000000000 0000000000000000 > (XEN) [ 9.136598] ffff82d040b23a88 00000000000002e8 ffff830401d6cfe0 ffff8304761afc98 > (XEN) [ 9.136602] ffff82d04045fc14 00000000000002c0 ffff82d040b23a58 ffff8304761afd00 > (XEN) [ 9.136605] ffff82d040418a0a ffff830405d65000 ffff82d040b23a88 0000000154381286 > (XEN) [ 9.136609] 0000000000000000 00383ffe00090672 0000000000001c78 fffffffffffffff4 > (XEN) [ 9.136612] ffff830476161000 ffff8304761afdb0 ffff830405d65000 ffff8304761afd50 > (XEN) [ 9.136616] ffff82d040630690 800000030847e127 0000000000000206 000000000000000e > (XEN) [ 9.136619] ffff82d040a00b44 ffff82d040a00b40 ffff82d040a00b44 ffff83047618f000 > (XEN) [ 9.136622] 00007f24a3c7a010 ffff8304761afef8 ffff8304761afef8 ffff8304761b5088 > (XEN) [ 9.136626] 00001c7800000580 ffff830483a24000 0000000000000001 00007f24a3c7a010 > (XEN) [ 9.136629] 0000000000000001 ffff830405d65000 00007f24a3c7a010 0000000000000001 > (XEN) [ 9.136633] 0000000000000021 0000000000000000 ffff8304761afe68 ffff82d0402c662f > (XEN) [ 9.136636] ffff8304761afd80 ffff82d0405a0fbb ffff830476161000 ffff8881b9b80000 > (XEN) [ 9.136640] ffff8304761afdb8 ffff82d04052fdef ffff830476161000 ffff8881b9b80000 > (XEN) [ 9.136643] Xen call trace: > (XEN) [ 9.136646] [<ffff82d04032e8a8>] R common/ubsan/ubsan.c#ubsan_epilogue+0xa/0xd9 > (XEN) [ 9.136648] [<ffff82d04032ef58>] F __ubsan_handle_type_mismatch+0x135/0x48e > (XEN) [ 9.136651] [<ffff82d04032f3af>] F __ubsan_handle_type_mismatch_v1+0xfe/0x100 > (XEN) [ 9.136655] [<ffff82d040418b9c>] F arch/x86/hvm/viridian/viridian.c#viridian_save_domain_ctxt+0x192/0x204 > (XEN) [ 9.136658] [<ffff82d04045fc14>] F hvm_save+0x4d1/0x5c6 > (XEN) [ 9.136661] [<ffff82d040630690>] F arch_do_domctl+0x2f8/0x51aa > (XEN) [ 9.136664] [<ffff82d0402c662f>] F do_domctl+0xc91/0x460d > (XEN) [ 9.136667] [<ffff82d04053ab70>] F pv_hypercall+0x6d6/0x834 > (XEN) [ 9.136669] [<ffff82d0402012d3>] F lstar_enter+0x143/0x150 > (XEN) [ 9.136671] > (XEN) [ 9.136673] ================================================================================ > (XEN) [ 9.622282] > (XEN) [ 9.624469] **************************************** > (XEN) [ 9.630471] Panic on CPU 14: > (XEN) [ 9.634182] UBSAN failure detected > (XEN) [ 9.638469] **************************************** > > throughout tests on actual hardware in CI. And really I don't think it's just UB, but > rather a real NULL deref: This is a consequence of us turning on UBSAN generally in GitlabCI, and will be the norm moving forward. Nevertheless, "member access within null pointer of type $X" is very clear cut. ~Andrew
diff --git a/xen/arch/x86/hvm/Kconfig b/xen/arch/x86/hvm/Kconfig index 2def0f98e2..9cdcc0d3cd 100644 --- a/xen/arch/x86/hvm/Kconfig +++ b/xen/arch/x86/hvm/Kconfig @@ -63,6 +63,16 @@ config ALTP2M If unsure, stay with defaults. +config HVM_VIRIDIAN + bool "Hyper-V enlighnments for guests" if EXPERT + default y + help + Support optimizations for Hyper-V guests such as faster hypercalls, + efficient timer and interrupt handling, and enhanced paravirtualized + I/O. This is to improve performance and compatibility of Windows VMs. + + If unsure, say Y. + config MEM_PAGING bool "Xen memory paging support (UNSUPPORTED)" if UNSUPPORTED depends on VM_EVENT diff --git a/xen/arch/x86/hvm/Makefile b/xen/arch/x86/hvm/Makefile index 4c1fa5c6c2..6cc2e74fc4 100644 --- a/xen/arch/x86/hvm/Makefile +++ b/xen/arch/x86/hvm/Makefile @@ -1,6 +1,6 @@ obj-$(CONFIG_AMD_SVM) += svm/ obj-$(CONFIG_INTEL_VMX) += vmx/ -obj-y += viridian/ +obj-$(CONFIG_HVM_VIRIDIAN) += viridian/ obj-y += asid.o obj-y += dm.o diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c index 5950f3160f..529068e80c 100644 --- a/xen/arch/x86/hvm/hvm.c +++ b/xen/arch/x86/hvm/hvm.c @@ -695,9 +695,12 @@ int hvm_domain_initialise(struct domain *d, if ( hvm_tsc_scaling_supported ) d->arch.hvm.tsc_scaling_ratio = hvm_default_tsc_scaling_ratio; - rc = viridian_domain_init(d); - if ( rc ) - goto fail2; + if ( is_viridian_domain(d) ) + { + rc = viridian_domain_init(d); + if ( rc ) + goto fail2; + } rc = alternative_call(hvm_funcs.domain_initialise, d); if ( rc != 0 ) @@ -733,7 +736,8 @@ void hvm_domain_relinquish_resources(struct domain *d) if ( hvm_funcs.nhvm_domain_relinquish_resources ) alternative_vcall(hvm_funcs.nhvm_domain_relinquish_resources, d); - viridian_domain_deinit(d); + if ( is_viridian_domain(d) ) + viridian_domain_deinit(d); ioreq_server_destroy_all(d); @@ -1637,9 +1641,12 @@ int hvm_vcpu_initialise(struct vcpu *v) && (rc = nestedhvm_vcpu_initialise(v)) < 0 ) /* teardown: nestedhvm_vcpu_destroy */ goto fail5; - rc = viridian_vcpu_init(v); - if ( rc ) - goto fail6; + if ( is_viridian_domain(d) ) + { + rc = viridian_vcpu_init(v); + if ( rc ) + goto fail6; + } rc = ioreq_server_add_vcpu_all(d, v); if ( rc != 0 ) @@ -1669,13 +1676,15 @@ int hvm_vcpu_initialise(struct vcpu *v) fail2: hvm_vcpu_cacheattr_destroy(v); fail1: - viridian_vcpu_deinit(v); + if ( is_viridian_domain(d) ) + viridian_vcpu_deinit(v); return rc; } void hvm_vcpu_destroy(struct vcpu *v) { - viridian_vcpu_deinit(v); + if ( is_viridian_domain(v->domain) ) + viridian_vcpu_deinit(v); ioreq_server_remove_vcpu_all(v->domain, v); diff --git a/xen/arch/x86/hvm/vlapic.c b/xen/arch/x86/hvm/vlapic.c index 065b2aab5b..3d76ce3f0d 100644 --- a/xen/arch/x86/hvm/vlapic.c +++ b/xen/arch/x86/hvm/vlapic.c @@ -426,7 +426,8 @@ void vlapic_EOI_set(struct vlapic *vlapic) * priority vector and then recurse to handle the lower priority * vector. */ - bool missed_eoi = viridian_apic_assist_completed(v); + bool missed_eoi = has_viridian_apic_assist(v->domain) && + viridian_apic_assist_completed(v); int vector; again: @@ -442,7 +443,7 @@ void vlapic_EOI_set(struct vlapic *vlapic) * NOTE: It is harmless to call viridian_apic_assist_clear() on a * recursion, even though it is not necessary. */ - if ( !missed_eoi ) + if ( has_viridian_apic_assist(v->domain) && !missed_eoi ) viridian_apic_assist_clear(v); vlapic_clear_vector(vector, &vlapic->regs->data[APIC_ISR]); @@ -1360,7 +1361,8 @@ int vlapic_has_pending_irq(struct vcpu *v) * If so, we need to emulate the EOI here before comparing ISR * with IRR. */ - if ( viridian_apic_assist_completed(v) ) + if ( has_viridian_apic_assist(v->domain) && + viridian_apic_assist_completed(v) ) vlapic_EOI_set(vlapic); isr = vlapic_find_highest_isr(vlapic); @@ -1373,7 +1375,8 @@ int vlapic_has_pending_irq(struct vcpu *v) if ( isr >= 0 && (irr & 0xf0) <= (isr & 0xf0) ) { - viridian_apic_assist_clear(v); + if ( has_viridian_apic_assist(v->domain) ) + viridian_apic_assist_clear(v); return -1; } diff --git a/xen/arch/x86/include/asm/hvm/domain.h b/xen/arch/x86/include/asm/hvm/domain.h index 333501d5f2..07eec231f0 100644 --- a/xen/arch/x86/include/asm/hvm/domain.h +++ b/xen/arch/x86/include/asm/hvm/domain.h @@ -111,7 +111,9 @@ struct hvm_domain { /* hypervisor intercepted msix table */ struct list_head msixtbl_list; +#ifdef CONFIG_HVM_VIRIDIAN struct viridian_domain *viridian; +#endif /* * TSC value that VCPUs use to calculate their tsc_offset value. diff --git a/xen/arch/x86/include/asm/hvm/hvm.h b/xen/arch/x86/include/asm/hvm/hvm.h index 963e820113..a836b2f4de 100644 --- a/xen/arch/x86/include/asm/hvm/hvm.h +++ b/xen/arch/x86/include/asm/hvm/hvm.h @@ -507,7 +507,8 @@ hvm_get_cpl(struct vcpu *v) (has_hvm_params(d) ? (d)->arch.hvm.params[HVM_PARAM_VIRIDIAN] : 0) #define is_viridian_domain(d) \ - (is_hvm_domain(d) && (viridian_feature_mask(d) & HVMPV_base_freq)) + (IS_ENABLED(CONFIG_HVM_VIRIDIAN) && \ + is_hvm_domain(d) && (viridian_feature_mask(d) & HVMPV_base_freq)) #define is_viridian_vcpu(v) \ is_viridian_domain((v)->domain) diff --git a/xen/arch/x86/include/asm/hvm/vcpu.h b/xen/arch/x86/include/asm/hvm/vcpu.h index 196fed6d5d..4c5a76a707 100644 --- a/xen/arch/x86/include/asm/hvm/vcpu.h +++ b/xen/arch/x86/include/asm/hvm/vcpu.h @@ -172,7 +172,9 @@ struct hvm_vcpu { /* Pending hw/sw interrupt (.vector = -1 means nothing pending). */ struct x86_event inject_event; +#ifdef CONFIG_HVM_VIRIDIAN struct viridian_vcpu *viridian; +#endif }; #endif /* __ASM_X86_HVM_VCPU_H__ */
Add config option HVM_VIRIDIAN that covers viridian code within HVM. Calls to viridian functions guarded by is_viridian_domain() and related macros. Having this option may be beneficial by reducing code footprint for systems that are not using Hyper-V. Signed-off-by: Sergiy Kibrik <Sergiy_Kibrik@epam.com> CC: Alejandro Vallejo <alejandro.vallejo@cloud.com> CC: Jan Beulich <jbeulich@suse.com> --- changes in v2: - changed title in Kconfig & add help text - moved Kconfig changes to arch/x86/hvm/Kconfig - address review comments --- xen/arch/x86/hvm/Kconfig | 10 ++++++++++ xen/arch/x86/hvm/Makefile | 2 +- xen/arch/x86/hvm/hvm.c | 27 ++++++++++++++++++--------- xen/arch/x86/hvm/vlapic.c | 11 +++++++---- xen/arch/x86/include/asm/hvm/domain.h | 2 ++ xen/arch/x86/include/asm/hvm/hvm.h | 3 ++- xen/arch/x86/include/asm/hvm/vcpu.h | 2 ++ 7 files changed, 42 insertions(+), 15 deletions(-)