[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 at 15:58, <andrew.cooper3@xxxxxxxxxx> wrote:
> 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
> Doesn't that prohibit them from being altered, even for development
> purposes?

Well, one would have to add a prompt line for the value to be
changeable. But that would be a 1-line change, much smaller
compared to the patch here, and hence acceptable imo.

>>> --- 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).

Oh, okay.

>> 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.

Which part - the pointlessly present one, or the absent ones?


Xen-devel mailing list



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