WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] Re: [PATCH] Remus breaks the build

To: Dulloor <dulloor@xxxxxxxxx>
Subject: Re: [Xen-devel] Re: [PATCH] Remus breaks the build
From: Brendan Cully <brendan@xxxxxxxxx>
Date: Tue, 17 Aug 2010 10:38:28 -0700
Cc: Jeremy Fitzhardinge <jeremy@xxxxxxxx>, "Xen-devel@xxxxxxxxxxxxxxxxxxx" <Xen-devel@xxxxxxxxxxxxxxxxxxx>, Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx>, Ian Campbell <Ian.Campbell@xxxxxxxxxx>, Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>
Delivery-date: Tue, 17 Aug 2010 10:39:38 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <AANLkTiktNSnHfF_v+L7Ad+6BcaYwuQVdWv1WKm_r7wFy@xxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Mail-followup-to: Dulloor <dulloor@xxxxxxxxx>, Jeremy Fitzhardinge <jeremy@xxxxxxxx>, "Xen-devel@xxxxxxxxxxxxxxxxxxx" <Xen-devel@xxxxxxxxxxxxxxxxxxx>, Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx>, Ian Campbell <Ian.Campbell@xxxxxxxxxx>, Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>
References: <4C6493ED.3040605@xxxxxxxx> <20100813194217.GA6981@xxxxxxxxxxxxxxxxx> <4C65B5A5.8020202@xxxxxxxx> <AANLkTiktNSnHfF_v+L7Ad+6BcaYwuQVdWv1WKm_r7wFy@xxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mutt/1.5.20 (2010-03-22)
On Friday, 13 August 2010 at 21:25, Dulloor wrote:
> On Fri, Aug 13, 2010 at 2:14 PM, Jeremy Fitzhardinge <jeremy@xxxxxxxx> wrote:
> >  On 08/13/2010 12:42 PM, Brendan Cully wrote:
> >> I assume you're talking about this snippet of tools/remus/kmod/Makefile:
> >>
> >> $(MAKE) -C $(KERNELDIR) SUBDIRS=`pwd` modules
> >>
> >> which expects to find a Makefile in $KERNELDIR but does the actual
> >> building in place, in the tools/remus/kmod directory (unless the
> >> kernel build system has changed recently?). I thought this was a
> >> pretty standard way to build out-of-tree kernel modules.
> >
> > I don't ever build the kernel out of the Xen tree.  In general, it
> > assumes the kernel tree has already been configured and built, which may
> > not be true if you're doing a parallel build, or if you're building the
> > Xen tree piecewise.
> >
> >> I'm not sure why this is causing you problems (is it?), but if you're
> >> willing to carry sch_queue in the pvops tree, I'd be happy to drop
> >> tools/remus/kmod in the unstable tree.
> >
> > Yes, I'm happy to include it.  Do you have a git reference I can merge from?
> 
> My understanding is that we don't need any out-of-tree modules, if
> linux is built with CONFIG_IFB.
> Also, that IFB isn't something available on 2.6.18 (and maybe
> 2.6.27?), where we will need to build these modules.
> 
> Is that right ? And, if thats the case, isn't it better to fold these
> drivers into 2.6.18 (2.6.27 ?) and
> support Remus conditional on IFB for pvops tree ?

Remus actually uses two modules. One is sch_queue, a Linux queueing
discipline that queues outbound guest traffic until the machine state
that produced it has been committed at the backup. This is the one
that we're talking about moving into the pvops tree (after I've tested
it -- I'm having the customary day-long fight getting Xen running
smoothly after having not updated for a while).

We need a second module (IFB or IMQ, depending on the kernel version)
because Linux queueing disciplines only operate on a device's outbound
traffic. Since Remus runs in dom0, it sees the guest's outbound
traffic as _inbound_ traffic on a VIF device. So IMQ/IFB is used to
redirect that incoming VIF traffic to a virtual intermediate device
with the sch_queue queueing discipline installed on it.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel