Re: RFC: xen config changes v4

[Juergen Gross <jgross@suse.com>]

On 02/26/2015 07:48 PM, Luis R. Rodriguez wrote:
> On Thu, Feb 26, 2015 at 05:42:57PM +0000, Stefano Stabellini wrote:
>> On Thu, 26 Feb 2015, Luis R. Rodriguez wrote:
>>> On Thu, Feb 26, 2015 at 11:08:20AM +0000, Stefano Stabellini wrote:
>>>> On Thu, 26 Feb 2015, David Vrabel wrote:
>>>>> On 26/02/15 04:59, Juergen Gross wrote:
>>>>>>
>>>>>> So we are again in the situation that pv-drivers always imply the pvops
>>>>>> kernel (PARAVIRT selected). I started the whole Kconfig rework to
>>>>>> eliminate this dependency.
>>>>>
>>>>> Yes.  Can you produce a series that just addresses this one issue.
>>>>>
>>>>> In the absence of any concrete requirement for this big Kconfig reorg I
>>>>> I don't think it is helpful.
>>>>
>>>> I clearly missed some context as I didn't realize that this was the
>>>> intended goal. Why do we want this? Please explain as it won't come
>>>> for free.
>>>>
>>>>
>>>> We have a few PV interfaces for HVM guests that need PARAVIRT in Linux
>>>> in order to be used, for example pv_time_ops and HVMOP_pagetable_dying.
>>>> They are critical performance improvements and from the interface
>>>> perspective, small enough that doesn't make much sense having a separate
>>>> KConfig option for them.
>>>>
>>>>
>>>> In order to reach the goal above we necessarily need to introduce a
>>>> differentiation in terms of PV on HVM guests in Linux:
>>>>
>>>> 1) basic guests with PV network, disk, etc but no PV timers, no
>>>>     HVMOP_pagetable_dying, no PV IPIs
>>>> 2) full PV on HVM guests that have PV network, disk, timers,
>>>>     HVMOP_pagetable_dying, PV IPIs and anything else that makes sense.
>>>>
>>>> 2) is much faster than 1) on Xen and 2) is only a tiny bit slower than
>>>> 1) on native x86
>>>
>>> Also don't we shove 2) down hvm guests right now? Even when everything is
>>> built in I do not see how we opt out for HVM for 1) at run time right now.
>>>
>>> If this is true then the question of motivation for this becomes even
>>> stronger I think.
>>
>> Yes, indeed there is no way to do 1) at the moment. And for good
>> reasons, see above.
>
> OK if the goal is to be able to build front end drivers by avoiding building
> PARAVIRT / PARAVIRT_CLOCK and if the gains to be able to do so (which haven't
> been stated other than just the ability to do so) are small (as Stefano notes
> simple hvm containers do not perform great) but requires a bit of work, I'd
> rather ask -- why not address *why* we are avoiding PARAVIRT /
> PARAVIRT_CLOCK and stick to the original goals behind the pvops model by
> addressing what is required to be able to continue to be happy with one single
> kernel. The work required to do that might be more than to just be able to
> build simple Xen hvm containers without PARAVIRT / PARAVIRT_CLOCK  but I'd
> think the gains would be much higher.

I absolutely agree. I think this is a long term goal we should work on.
PVH should address most of the issues, BTW.

> If this resonates well then I'd like to ask: what are the current most pressing
> issues with enabling PARAVIRT / PARAVIRT_CLOCK.

PARAVIRT: performance, especially memory management

PARAVIRT_CLOCK: none


Juergen