[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [PATCH] x86/hvm: add HVM-specific Kconfig
On 07.02.2025 23:03, dmkhn@xxxxxxxxx wrote: > Add separate menu for configuring HVM build-time settings to help organizing > HVM-specific options. > > Signed-off-by: Denis Mukhin <dmukhin@xxxxxxxx> I think it would be nice if "organizing" was further qualified, to really see _why_ the change is being made. A particular benefit that Roger points out is that this way all HVM-dependent options moved here will then appear in a sub- menu like fashion in the tool. > --- a/xen/arch/x86/Kconfig > +++ b/xen/arch/x86/Kconfig > @@ -30,7 +30,6 @@ config X86 > select HAS_SCHED_GRANULARITY > select HAS_UBSAN > select HAS_VMAP > - select HAS_VPCI if HVM > select NEEDS_LIBELF As said before, personally I'd prefer if this didn't move. > --- /dev/null > +++ b/xen/arch/x86/hvm/Kconfig > @@ -0,0 +1,73 @@ > +menuconfig HVM > + bool "HVM support" > + depends on !PV_SHIM_EXCLUSIVE > + default !PV_SHIM > + select COMPAT > + select HAS_VPCI > + select IOREQ_SERVER > + select MEM_ACCESS_ALWAYS_ON > + help > + Interfaces to support HVM domains. HVM domains require hardware > + virtualisation extensions (e.g. Intel VT-x, AMD SVM), but can boot > + guests which have no specific Xen knowledge. > + > + This option is needed if you want to run HVM or PVH domains. > + > + If unsure, say Y. > + > +if HVM > + > +config AMD_SVM > + bool "AMD-V" if EXPERT > + default y > + help > + Enables virtual machine extensions on platforms that implement the > + AMD Virtualization Technology (AMD-V). > + If your system includes a processor with AMD-V support, say Y. > + If in doubt, say Y. > + > +config INTEL_VMX > + bool "Intel VT-x" if EXPERT > + default y > + select ARCH_VCPU_IOREQ_COMPLETION > + help > + Enables virtual machine extensions on platforms that implement the > + Intel Virtualization Technology (Intel VT-x). > + If your system includes a processor with Intel VT-x support, say Y. > + If in doubt, say Y. Perhaps not to be done right here, but still: I guess the "default" of these want to change to use AMD / INTEL respectively. While we permit enabling the virt extension support separately, generally there's little point doing so by default when the corresponding CPU support code was disabled. > +config ALTP2M > + bool "Alternate P2M support" if EXPERT > + depends on INTEL_VMX > + default y > + help > + Alternate-p2m allows a guest to manage multiple p2m guest physical > + "memory views" (as opposed to a single p2m). > + Useful for memory introspection. > + > + If unsure, stay with defaults. > + > +config MEM_PAGING > + bool "Xen memory paging support (UNSUPPORTED)" if UNSUPPORTED > + > +config MEM_SHARING > + bool "Xen memory sharing support (UNSUPPORTED)" if UNSUPPORTED > + > +config HVM_FEP > + bool "HVM Forced Emulation Prefix support (UNSUPPORTED)" if UNSUPPORTED > + default DEBUG > + help > + Compiles in a feature that allows HVM guest to arbitrarily > + exercise the instruction emulator. > + > + This feature can only be enabled during boot time with > + appropriate hypervisor command line option. Please read > + hypervisor command line documentation before trying to use > + this feature. > + > + This is strictly for testing purposes, and not appropriate > + for use in production. > + > + If unsure, say N. Please can this move ahead of at least the two MEM_* ones, maybe even ahead of ALTP2M? Jan
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |