[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Xen-devel] RFC: xen config changes v4
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
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel
|
