From: Alejandro Vallejo <alejandro.garciavallejo@amd.com>
To: Jan Beulich <jbeulich@suse.com>
Cc: <roger.pau@citrix.com>, <andrew.cooper3@citrix.com>,
<jason.andryuk@amd.com>,
Stefano Stabellini <stefano.stabellini@amd.com>,
<xen-devel@lists.xenproject.org>
Subject: Re: [PATCH] x86/hvm: Add Kconfig option to disable nested virtualization
Date: Mon, 16 Feb 2026 12:28:49 +0100 [thread overview]
Message-ID: <DGGCNDLX0AY0.2P9QP7NMYNR5R@amd.com> (raw)
In-Reply-To: <c0635184-6422-498b-87de-e6c3fa016a4d@suse.com>
On Mon Feb 16, 2026 at 12:01 PM CET, Jan Beulich wrote:
>>> --- 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
I'd agree should we need more than 2 settings, long config parameter names
or long filenames, but none of that applies here. It fits neatly in within 80
columns and the extra indirection bumps the cognitive load (subjectively
speaking) way more than the single line does. Plus, it takes more vertical
space.
Even then, I'd rather have ifeq on the 3rd and/or 4th parameters and filter
inside, which makes the group stand out much better and doesn't pollute the
global namespace with even more names.
And there's the matter of "filter" being in use very prevalently elsewhere.
My .02, anyway. They are functionally equivalent, after all.
Cheers,
Alejandro
next prev parent reply other threads:[~2026-02-16 11:29 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-02-13 22:02 [PATCH] x86/hvm: Add Kconfig option to disable nested virtualization Stefano Stabellini
2026-02-13 23:48 ` Demi Marie Obenour
2026-02-16 10:00 ` Jan Beulich
2026-02-16 10:34 ` Alejandro Vallejo
2026-02-16 11:01 ` Jan Beulich
2026-02-16 11:28 ` Alejandro Vallejo [this message]
-- strict thread matches above, loose matches on Subject: below --
2026-02-06 1:50 Stefano Stabellini
2026-02-06 4:07 ` Demi Marie Obenour
2026-02-06 8:15 ` Roger Pau Monné
2026-02-06 20:52 ` Stefano Stabellini
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=DGGCNDLX0AY0.2P9QP7NMYNR5R@amd.com \
--to=alejandro.garciavallejo@amd.com \
--cc=andrew.cooper3@citrix.com \
--cc=jason.andryuk@amd.com \
--cc=jbeulich@suse.com \
--cc=roger.pau@citrix.com \
--cc=stefano.stabellini@amd.com \
--cc=xen-devel@lists.xenproject.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.