Re: RFC: xen config changes v4

[Juergen Gross <jgross@suse.com>]

On 03/02/2015 06:07 PM, Stefano Stabellini wrote:
> On Mon, 2 Mar 2015, Konrad Rzeszutek Wilk wrote:
>>>>>>> I would prefer to hide it on PAE and x86_64.
>>>>>>
>>>>>>
>>>>>> Okay, as long as it is still _possible_ somehow to configure it.
>>>>>
>>>>> That begs the question, all this just for 32-bit non-PAE ?
>>>>
>>>> There was another reason. Some distros remove the CONFIG_XEN_DOM0 altogether
>>>> even thought they do enable the rest of the pieces (backends, frontends, etc).
>>>>
>>>> Which begs the question - why do we care about DOM0 at all.
>>>>
>>>> What we care about is drivers - either frontend or backend. If we want
>>>> backends and we want PV - then we want to build an kernel that can boot as
>>>> a normal PV or as an dom0 PV.
>>>>
>>>> Ditto for HVM - if you want to build an kernel that won't do PV but
>>>> can do backends - we should be able to do that.
>>>>
>>>> Or PVH  - we want an domain that can be an backend (or frontend).
>>>>
>>>> That does mean the "PV" gets broken down further to be concrete
>>>> pieces and have nothing to do with drivers.
>>>>
>>>> The idea would be that you would just select four knobs:
>>>>
>>>>   Yes/No Backend PV drivers [and maybe remove the PV part?]
>>>>   Yes/No Frontend PV drivers [and maybe remove the PV part?]
>>>>   Yes/No PV support (so utilizing the PV ABI)
>>>>   Yes/No PVH support (a stricter subset of PV ABI - with less pieces)
>>>>
>>>> The HVM support would automatically be picked if the config had
>>>> the 'baremetal' type support - like IOAPIC, APIC, ACPI, etc.
>>>>
>>>> So if you said Y, N, N, N, the kernel would only be able to
>>>> boot in HVM mode but still have pciback, netback, scsiback, blkback, and usbback.
>>>> (good for an device backend). And it could be an PAE or non-PAE kernel.
>>>>
>>>> If you said N,Y,Y,Y then it could boot under HVM, PV, PVH, and only
>>>> have pcifront, netfront, scsifront, blkfront, and usbfront.
>>>> (not very good for an initial domain).
>>>>
>>>> And so on.
>>>
>>> It makes sense.
>>>
>>>
>>>> I hope I hadn't confused the matter?
>>>
>>> Nope, I think it clarifies things, thanks.
>>
>> Thought it does mean that it would add more #ifdery or cleanups
>> to the existing drivers so that they can be compiled under
>> different platforms without any assumptions.
>>
>>>
>>> In this context the issue we were discussing is what to do with the
>>> other PV interfaces for PV on HVM guests, such as HVMOP_pagetable_dying.
>>> I think it would be natural to enable them when Frontend PV drivers are
>>> enabled, without any additional Kconfig options.
>>
>> I would put this in 'Enlightment support for Xen' - which would be
>> the basic foundation to make any kernel work under Xen. This would
>> pull in some _infrastructure_. Regardless of it being a backend
>> or frontend we need grant ops,event channels, support for migration.
>
> Sounds good.
>
>
>> Perhaps add that as a new option under CONFIG_HYPERVISOR. And not
>> depend on CONFIG_PARAVIRT - as in theory you can have an non-PARAVIRT HVM
>> guest running with PV drivers (I haven't tried it, but I would think
>> it can be done?)
>
> That is the bit I disagree with: not depending on CONFIG_PARAVIRT means
> that many good optimizations for PV on HVM guests won't be enabled.
> Doing so will cause a performance regression compared to the PV on HVM
> guests of today.

I think we should have some (hidden) config options to enable/disable
the basic features like frontends, backends, optimizations. Those
features would then be selected by user visible config options.

We should avoid mixing technically independent options under the same
config item.


Juergen