[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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 




Xen-devel mailing list



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