Re: [Xen-devel] RFC: xen config changes v4

["Luis R. Rodriguez" <mcgrof@xxxxxxxx>]

On Fri, Feb 27, 2015 at 07:14:32AM +0100, Juergen Gross wrote:
> 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

Do we have studies on specific areas? I'd be very interested in the exact 
routines.

> PARAVIRT_CLOCK: none

Great!

 Luis

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel