Re: RFC: xen config changes v4

[Ian Campbell <ian.campbell@citrix.com>]

On Thu, 2015-02-26 at 19:48 +0100, 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)

I may have misunderstood this bit, WRT this last parenthetical: adding
PV I/O drivers to an HVM guest is AFAIAA the single biggest improvement
you can make to a bare HVM guest in terms of performance.

There are indeed additional gains to be had from other PV stuff which
Stefano mentions (clocks etc), but I believe those are all mostly
incremental and not as impressive as the PV I/O gains (but still good
improvements).

That's not to say that there's an argument in the context of Linux that
if you can enable PV I/O then you can also enable other PV 
optimisations, but I thought I would mention it.

Wasn't part of the original point here to be able to enable PV I/O (and
perhaps other PV stuff) for non-PAE 32-bit x86, i.e. in a context where
PVMMU isn't available. (That doesn't necessarily conflict with "if you
can enable PV I/O then you can also enable other PV 
optimisations" though)

Ian.