| Message ID | c94e4480-96a0-34b6-a4c6-6176daa57588@suse.com (mailing list archive) |
|---|---|
| State | Superseded |
| Headers | show |
| Series | x86: shim building adjustments (plus shadow follow-on) | expand |
On Wed, Sep 16, 2020 at 03:08:00PM +0200, Jan Beulich wrote: > This combination doesn't really make sense (and there likely are more); > in particular even if the code built with both options set, HVM guests > wouldn't work (and I think one wouldn't be able to create one in the > first place). The alternative here would be some presumably intrusive > #ifdef-ary to get this combination to actually build (but still not > work) again. > > Signed-off-by: Jan Beulich <jbeulich@suse.com> I can see the desire for being able to remove code, and the point Andrew made about one option not making another disappear in a completely different menu section. Yet I don't see how to converge the two together, unless we completely change our menu layouts, and even then I'm not sure I see how we could structure this. Hence: Acked-by: Roger Pau Monné <roger.pau@citrix.com> Thanks, Roger.
On 08.10.2020 16:52, Roger Pau Monné wrote: > On Wed, Sep 16, 2020 at 03:08:00PM +0200, Jan Beulich wrote: >> This combination doesn't really make sense (and there likely are more); >> in particular even if the code built with both options set, HVM guests >> wouldn't work (and I think one wouldn't be able to create one in the >> first place). The alternative here would be some presumably intrusive >> #ifdef-ary to get this combination to actually build (but still not >> work) again. >> >> Signed-off-by: Jan Beulich <jbeulich@suse.com> > > I can see the desire for being able to remove code, and the point > Andrew made about one option not making another disappear in a > completely different menu section. > > Yet I don't see how to converge the two together, unless we completely > change our menu layouts, and even then I'm not sure I see how we could > structure this. Hence: > > Acked-by: Roger Pau Monné <roger.pau@citrix.com> Thanks. Andrew - are you okay with this going in then? Or if not, do you have any thoughts towards an alternative approach? Jan
--- a/xen/arch/x86/Kconfig +++ b/xen/arch/x86/Kconfig @@ -23,7 +23,7 @@ config X86 select HAS_PDX select HAS_SCHED_GRANULARITY select HAS_UBSAN - select HAS_VPCI if !PV_SHIM_EXCLUSIVE && HVM + select HAS_VPCI if HVM select NEEDS_LIBELF select NUMA @@ -90,8 +90,9 @@ config PV_LINEAR_PT If unsure, say Y. config HVM - def_bool !PV_SHIM_EXCLUSIVE - prompt "HVM support" + bool "HVM support" + depends on !PV_SHIM_EXCLUSIVE + default y ---help--- Interfaces to support HVM domains. HVM domains require hardware virtualisation extensions (e.g. Intel VT-x, AMD SVM), but can boot
This combination doesn't really make sense (and there likely are more); in particular even if the code built with both options set, HVM guests wouldn't work (and I think one wouldn't be able to create one in the first place). The alternative here would be some presumably intrusive #ifdef-ary to get this combination to actually build (but still not work) again. Signed-off-by: Jan Beulich <jbeulich@suse.com> --- v2: Restore lost default setting.