[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 16/02/17 14:39, Jan Beulich wrote: >>>> 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? Hence the RFC on this patch. > Or otherwise, how about making them prompt-less for now even for > EXPERT? Doesn't that prohibit them from being altered, even for development purposes? > >> --- 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? There are a few edgecases whether neither would be useful, e.g. seeing if we have subsystems in the resulting compile which should be covered under PV or HVM. I also had occason to need no guests whatsoever when doing the HPET work (and I still have the debugging patch to allow Xen to run without a dom0). As this is already under EXPERT (and I expect that not to change), I don't it is too much of a problem allowing both to be disabled. > 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). I did find this weird. ~Andrew _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx https://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |