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

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

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.

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

  Luis

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