[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

Doesn't that prohibit them from being altered, even for development

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


Xen-devel mailing list



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