Re: [PATCH] x86/hvm: Add Kconfig option to disable nested virtualization

[Jan Beulich <jbeulich@xxxxxxxx>]

On 16.02.2026 11:34, Alejandro Vallejo wrote:
> On Fri Feb 13, 2026 at 11:02 PM CET, Stefano Stabellini wrote:
>> --- a/xen/arch/x86/hvm/Kconfig
>> +++ b/xen/arch/x86/hvm/Kconfig
>> @@ -92,4 +92,11 @@ config MEM_SHARING
>>      bool "Xen memory sharing support (UNSUPPORTED)" if UNSUPPORTED
>>      depends on INTEL_VMX
>>  
>> +config NESTED_VIRT
>> +    bool "Nested virtualization support"
>> +    depends on HVM
>> +    help
>> +      Enable nested virtualization, allowing guests to run their own
>> +      hypervisors. This requires hardware support.
> 
> nit: If we state above "allowing HVM guests..." rather than plain "guests" we 
> can
> then get rid of the "This requires hardware support line". What you probably
> meant is that this is HVM-only and we don't allow PV nesting.
> 
> "This requires hardware support" makes me (the user) think my hardware needs
> something special to support nesting, when in reality I just need HVM support.

When replying, I also initially meant to make this broad a statement, but then
went to check: While indeed it ought to be possible to implement nested without
further hw support, both demands HAP and SVM demands a few more advanced
features (see start_nested_svm()).

>> --- a/xen/arch/x86/mm/hap/Makefile
>> +++ b/xen/arch/x86/mm/hap/Makefile
>> @@ -2,5 +2,6 @@ obj-y += hap.o
>>  obj-y += guest_walk_2.o
>>  obj-y += guest_walk_3.o
>>  obj-y += guest_walk_4.o
>> -obj-y += nested_hap.o
>> -obj-$(CONFIG_INTEL_VMX) += nested_ept.o
>> +nested-y := nested_hap.o
>> +nested-$(CONFIG_INTEL_VMX) += nested_ept.o
>> +obj-$(CONFIG_NESTED_VIRT) += $(nested-y)
> 
> Why not use plain filter?
> 
>       -obj-y += nested_hap.o
>       +obj-$(CONFIG_NESTED_VIRT) += nested_hap.o
>       -obj-$(CONFIG_INTEL_VMX) += nested_ept.o
>       +obj-$(filter $(CONFIG_NESTED_VIRT),$(CONFIG_INTEL_VMX)) += nested_ept.o

It may have been like this in v1. Problem being that this leads to long lines,
which doesn't scale very well (and is - imo - harder to read). Especially when
you consider what happens when it's more than two settings that need checking.
The list approach easily scales to about anything (by using as many separate
lists as you need).

Jan