[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH] [RFC] x86/kconfig: Introduce CONFIG_PV and CONFIG_HVM

>>> On 15.02.17 at 20:41, <andrew.cooper3@xxxxxxxxxx> wrote:
> Making PV and HVM guests individually compilable is useful as a reduction in
> hypervisor size, and as an aid to enforcing clean API boundaries.
> Introduce CONFIG_PV and CONFIG_HVM, although there is a lot of work to do
> until either can actually be disabled.

While this is a nice goal, is it really useful to add these config options
now, rather than when that lot of work is at least near completion?
Or otherwise, how about making them prompt-less for now even for

> --- a/xen/arch/x86/Kconfig
> +++ b/xen/arch/x86/Kconfig
> @@ -32,6 +32,56 @@ menu "Architecture Features"
>  source "arch/Kconfig"
> +config PV
> +     def_bool y
> +     prompt "PV guest support" if EXPERT = "y"
> +     depends on X86
> +     ---help---
> +       Support for Xen Paravirtual guests.
> +
> +       Xen PV guests use Ring Deprivileging as a method of virtualisation.
> +       This requires no specific hardware support, but does require an OS
> +       capable of running PV under Xen.
> +
> +       If unsure, say Y.
> +
> +       TODO: This is a work in process, and Xen doesn't currently compile
> +       if this option is disabled.
> +
> +config HVM
> +     def_bool y
> +     prompt "HVM guest support" if EXPERT = "y"
> +     depends on X86

Both of them getting selected to "no" makes extremely little sense,
I think, so I would wish to have a guard against that. Maybe the
user visible part wants to be a choice (both, PV only, HVM only),
selecting prompt-less PV and HVM as necessary?

Furthermore, considering what file they're in, I don't think the
"depends on X86" are necessary here (oddly enough TBOOT has
this too, but SHADOW_PAGING and BIGMEM don't).


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.