Xen devel - Apr 2010 - [PATCH 0 of 2] Remus: support for pvops dom0

These two patches update the Remus network buffering code to work with
newer kernels, including the pvops tree.

Built and run, but not extensively tested (I''m still working on some
blktap2
issues on the disk replication side).

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

# HG changeset patch
# User Brendan Cully <brendan@cs.ubc.ca>
# Date 1271123805 25200
# Node ID b0d4c221e926feff21bea0c2f3c852a692782586
# Parent  f28f1ee587c8d3fb8450e5aae9541d785e8914cc
Remus: make ebt_imq and sch_queue compatible with pvops

diff --git a/tools/remus/kmod/Makefile b/tools/remus/kmod/Makefile
--- a/tools/remus/kmod/Makefile
+++ b/tools/remus/kmod/Makefile
@@ -9,6 +9,9 @@
 ifeq ($(KERNELS),linux-2.6-xen0)
 LINUX_VER=2.6.18-xen0
 endif
+ifeq ($(KERNELS),linux-2.6-pvops)
+LINUX_VER=2.6-pvops
+endif
 
 KERNELDIR ?= $(XEN_ROOT)/build-linux-$(LINUX_VER)_$(XEN_TARGET_ARCH)
 
diff --git a/tools/remus/kmod/ebt_imq.c b/tools/remus/kmod/ebt_imq.c
--- a/tools/remus/kmod/ebt_imq.c
+++ b/tools/remus/kmod/ebt_imq.c
@@ -1,9 +1,19 @@
+#include <linux/version.h>
+#if LINUX_VERSION_CODE == KERNEL_VERSION(2,6,18)
+#  define OLDKERNEL
+#endif
+
 #include <linux/module.h>
 #include <linux/skbuff.h>
+#ifndef OLDKERNEL
+#  include <linux/netfilter/x_tables.h>
+#endif
 #include <linux/netfilter_bridge/ebtables.h>
 #include <linux/netdevice.h>
 #include "ebt_imq.h"
 
+#ifdef OLDKERNEL
+
 static int ebt_target_imq(struct sk_buff **pskb, unsigned int hooknr,
    const struct net_device *in, const struct net_device *out,
    const void *data, unsigned int datalen)
@@ -21,25 +31,66 @@
   return 0;
 }
 
-static struct ebt_target imq_target +static struct ebt_target ebt_imq_target  {
-  .name                = "imq",
-  .target       = ebt_target_imq,
+  .name        = EBT_IMQ_TARGET,
+  .target      = ebt_target_imq,
   .check       = ebt_target_imq_check,
   .me          = THIS_MODULE,
 };
 
-static int __init init(void)
+static int __init ebt_imq_init(void)
 {
-  return ebt_register_target(&imq_target);
+  return ebt_register_target(&ebt_imq_target);
 }
 
-static void __exit fini(void)
+static void __exit ebt_imq_fini(void)
 {
-  ebt_unregister_target(&imq_target);
+  ebt_unregister_target(&ebt_imq_target);
 }
 
+#else /* OLDKERNEL */
 
-module_init(init);
-module_exit(fini);
+static unsigned int
+ebt_imq_tg(struct sk_buff *skb, const struct xt_target_param *par)
+{
+  const struct ebt_imq_info *info = par->targinfo;
+
+  if (!skb_make_writable(skb, 0))
+    return EBT_DROP;
+
+  skb->imq_flags = info->todev | IMQ_F_ENQUEUE;
+
+  return EBT_CONTINUE;
+}
+
+static bool ebt_imq_tg_check(const struct xt_tgchk_param *par)
+{
+  return true;
+}
+
+static struct xt_target ebt_imq_target __read_mostly = {
+  .name		= EBT_IMQ_TARGET,
+  .revision	= 0,
+  .family       = NFPROTO_BRIDGE,
+  .target	= ebt_imq_tg,
+  .checkentry	= ebt_imq_tg_check,
+  .targetsize	= XT_ALIGN(sizeof(struct ebt_imq_info)),
+  .me		= THIS_MODULE,
+};
+
+static int __init ebt_imq_init(void)
+{
+  return xt_register_target(&ebt_imq_target);
+}
+
+static void __init ebt_imq_fini(void)
+{
+  xt_unregister_target(&ebt_imq_target);
+}
+
+#endif /* OLDKERNEL */
+
+module_init(ebt_imq_init);
+module_exit(ebt_imq_fini);
 MODULE_LICENSE("GPL");
diff --git a/tools/remus/kmod/ebt_imq.h b/tools/remus/kmod/ebt_imq.h
--- a/tools/remus/kmod/ebt_imq.h
+++ b/tools/remus/kmod/ebt_imq.h
@@ -1,10 +1,14 @@
 #ifndef __LINUX_BRIDGE_EBT_IMQ_H
 #define __LINUX_BRIDGE_EBT_IMQ_H
 
-#define IMQ_F_ENQUEUE 0x80
+#ifdef OLDKERNEL
+#  define IMQ_F_ENQUEUE 0x80
+#endif
 
 struct ebt_imq_info
 {
   unsigned int todev;
 };
+#define EBT_IMQ_TARGET "imq"
+
 #endif
diff --git a/tools/remus/kmod/sch_queue.c b/tools/remus/kmod/sch_queue.c
--- a/tools/remus/kmod/sch_queue.c
+++ b/tools/remus/kmod/sch_queue.c
@@ -16,7 +16,14 @@
  * So it supports two operations, barrier and release.
  */
 
-#include <linux/config.h>
+#include <linux/version.h>
+#if LINUX_VERSION_CODE == KERNEL_VERSION(2,6,18)
+#  define OLDKERNEL
+#endif
+
+#ifdef OLDKERNEL
+#  include <linux/config.h>
+#endif
 #include <linux/module.h>
 #include <linux/types.h>
 #include <linux/kernel.h>
@@ -25,6 +32,17 @@
 #include <linux/skbuff.h>
 #include <net/pkt_sched.h>
 
+#ifdef OLDKERNEL
+#  define compatnlattr rtattr
+#  define compatnllen RTA_PAYLOAD
+#  define compatnldata RTA_DATA
+#else
+#  include <xen/features.h>
+#  define compatnlattr nlattr
+#  define compatnllen nla_len
+#  define compatnldata nla_data
+#endif
+
 /* xenbus directory */
 #define FIFO_BUF    (10*1024*1024)
 
@@ -43,6 +61,7 @@
   int action;
 };
 
+#ifdef OLDKERNEL
 /* borrowed from drivers/xen/netback/loopback.c */
 #ifdef CONFIG_X86
 static int is_foreign(unsigned long pfn)
@@ -88,6 +107,12 @@
 
   return 1;
 }
+#else /* OLDKERNEL */
+static int skb_remove_foreign_references(struct sk_buff *skb)
+{
+  return !skb_linearize(skb);
+}
+#endif /* OLDKERNEL */
 
 static int queue_enqueue(struct sk_buff *skb, struct Qdisc* sch)
 {
@@ -112,7 +137,7 @@
 
 /* dequeue doesn''t actually dequeue until the release command is
  * received. */
-static inline struct sk_buff *queue_dequeue(struct Qdisc* sch)
+static struct sk_buff *queue_dequeue(struct Qdisc* sch)
 {
   struct queue_sched_data *q = qdisc_priv(sch);
   struct sk_buff* peek;
@@ -145,7 +170,7 @@
   return qdisc_dequeue_head(sch);
 }
 
-static int queue_init(struct Qdisc *sch, struct rtattr *opt)
+static int queue_init(struct Qdisc *sch, struct compatnlattr *opt)
 {
   sch->flags |= TCQ_F_THROTTLED;
 
@@ -155,7 +180,7 @@
 /* receives two messages:
  *   0: checkpoint queue (set stop to next packet)
  *   1: dequeue until stop */
-static int queue_change(struct Qdisc* sch, struct rtattr* opt)
+static int queue_change(struct Qdisc* sch, struct compatnlattr* opt)
 {
   struct queue_sched_data *q = qdisc_priv(sch);
   struct tc_queue_qopt* msg;
@@ -163,10 +188,10 @@
   struct timeval tv;
   */
 
-  if (!opt || RTA_PAYLOAD(opt) < sizeof(*msg))
+  if (!opt || compatnllen(opt) < sizeof(*msg))
     return -EINVAL;
 
-  msg = RTA_DATA(opt);
+  msg = compatnldata(opt);
 
   if (msg->action == TCQ_CHECKPOINT) {
     /* reset stop */
@@ -174,7 +199,11 @@
   } else if (msg->action == TCQ_DEQUEUE) {
     /* dequeue */
     sch->flags &= ~TCQ_F_THROTTLED;
+#ifdef OLDKERNEL
     netif_schedule(sch->dev);
+#else
+    netif_schedule_queue(sch->dev_queue);
+#endif
     /*
     do_gettimeofday(&tv);
     printk("queue release at %lu.%06lu (%d bytes)\n", tv.tv_sec,
tv.tv_usec,
@@ -192,8 +221,11 @@
   .priv_size   =       sizeof(struct queue_sched_data),
   .enqueue     =       queue_enqueue,
   .dequeue     =       queue_dequeue,
-  .init                =       queue_init,
-  .change       =      queue_change,
+#ifndef OLDKERNEL
+  .peek        =       qdisc_peek_head,
+#endif
+  .init        =       queue_init,
+  .change      =       queue_change,
   .owner       =       THIS_MODULE,
 };
 

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

# HG changeset patch
# User Brendan Cully <brendan@cs.ubc.ca>
# Date 1271281121 25200
# Node ID 16eee52ac2ee7c3d4ddc25c9f4371ad7a9a00ae9
# Parent  b0d4c221e926feff21bea0c2f3c852a692782586
Remus: fix alignment bug in python rtnl library

diff --git a/tools/python/xen/remus/netlink.py
b/tools/python/xen/remus/netlink.py
--- a/tools/python/xen/remus/netlink.py
+++ b/tools/python/xen/remus/netlink.py
@@ -77,7 +77,7 @@
         return align(self.rta_len)
 
     def pack(self):
-        self.rta_len = align(self.fmtlen + len(self.body))
+        self.rta_len = self.fmtlen + align(len(self.body), 2)
         s = struct.pack(self.fmt, self.rta_len, self.rta_type) + self.body
         pad = self.rta_len - len(s)
         if pad:
@@ -88,7 +88,7 @@
         args = struct.unpack(self.fmt, msg[:self.fmtlen])
         self.rta_len, self.rta_type = args
 
-        self.body = msg[align(self.fmtlen):self.rta_len]
+        self.body = msg[self.fmtlen:self.rta_len]
 
 class rtattrlist(object):
     def __init__(self, msg):

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

Brendan Cully writes ("[Xen-devel] [PATCH 0 of 2] Remus: support for pvops
dom0"):
> These two patches update the Remus network buffering code to work with
> newer kernels, including the pvops tree.
Excellent.
> Built and run, but not extensively tested (I''m still working on
some blktap2
> issues on the disk replication side).
I haven''t looked at the code for the "remus" utility, but:
How hard is
it going to be to port it to libxl ?  I think remus is too exciting a
feature to be left to rot with xend.

Ian.

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

Forgive me

Where I found this patch?

Thanks


Brendan Cully escreveu:
> These two patches update the Remus network buffering code to work with
> newer kernels, including the pvops tree.
>
> Built and run, but not extensively tested (I''m still working on
some blktap2
> issues on the disk replication side).
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
>   
-- 
Gilberto Nunes Ferreira
*Suporte T.I.*
*Selbetti Gestão de Documentos*
*(47) 3441-6004 / (47) 8861-6672*
*Fax (47) 3441-6021*
/*gilberto.nunes@selbetti.com.br*/



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

On Thursday, 15 April 2010 at 14:58, Ian Jackson wrote:
> Brendan Cully writes ("[Xen-devel] [PATCH 0 of 2] Remus: support for
pvops dom0"):
> > These two patches update the Remus network buffering code to work with
> > newer kernels, including the pvops tree.
> 
> Excellent.
> 
> > Built and run, but not extensively tested (I''m still working
on some blktap2
> > issues on the disk replication side).
> 
> I haven''t looked at the code for the "remus" utility,
but: How hard is
> it going to be to port it to libxl ?  I think remus is too exciting a
> feature to be left to rot with xend.
Thanks :)

Remus doesn''t really use xend at all. It has its own bindings to libxc
and reimplements the migration control layer. I''d had tighter
integration with xend on my TODO list, but it sounds like I may not
need to do that any more.

I haven''t been paying close attention to the libxl patches flying by
on the list, but it looks like the area where libxl and Remus might
interact in the short term is your cleanups to the save image
format. Off the top of my head, I remember having to hack up a
slightly different stream format for HVM because the qemu blob had no
length prefix.

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

On Thursday 15 April 2010 15:58:27 Ian Jackson wrote:
> Brendan Cully writes ("[Xen-devel] [PATCH 0 of 2] Remus: support for
pvops
dom0"):
> > These two patches update the Remus network buffering code to work with
> > newer kernels, including the pvops tree.
> 
> Excellent.
Great news. I will test them in the next week.
> I haven''t looked at the code for the "remus" utility,
but: How hard is
> it going to be to port it to libxl ?  I think remus is too exciting a
> feature to be left to rot with xend.
What is wrong with xend? I''m new here, and I just started to learn this
stuff... :)

Regards,
Łukasz Oleś

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

Brendan Cully writes ("Re: [Xen-devel] [PATCH 0 of 2] Remus: support for
pvops dom0"):
> Remus doesn''t really use xend at all. It has its own bindings to
libxc
> and reimplements the migration control layer. I''d had tighter
> integration with xend on my TODO list, but it sounds like I may not
> need to do that any more.
Surely it uses xend at the receiving end at the very least ?  The
remus utility connects to something at the destination.

xl doesn''t have a daemon at the far end; xl migration is done over
ssh by default (although you can make it use some other transport if
you like).
> I haven''t been paying close attention to the libxl patches flying
by
> on the list, but it looks like the area where libxl and Remus might
> interact in the short term is your cleanups to the save image
> format. Off the top of my head, I remember having to hack up a
> slightly different stream format for HVM because the qemu blob had no
> length prefix.
The save image format is not defined by libxl but by the command-line
tool xl.  I expect it will move to the "kit of parts" library
libxlutil.

Ian.

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

áukasz Oleû writes ("Re: [Xen-devel] [PATCH 0 of 2] Remus: support for
pvops dom0"):
> On Thursday 15 April 2010 15:58:27 Ian Jackson wrote:
> > I haven''t looked at the code for the "remus"
utility, but: How hard is
> > it going to be to port it to libxl ?  I think remus is too exciting a
> > feature to be left to rot with xend.
> 
> What is wrong with xend? I''m new here, and I just started to learn
this
> stuff... :)
xend has a huge amount of unfortunately rather unreliable code to do
what is essentially a very simple set of tasks.  IMO it needs to be
thrown away.  Part of the benefit of libxl is that it provides a basis
for providing a utility like xl which does the same things as xm but
with much less code - specifically without xend.

Ian.

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

On Monday, 19 April 2010 at 14:09, Ian Jackson wrote:
> Brendan Cully writes ("Re: [Xen-devel] [PATCH 0 of 2] Remus: support
for pvops dom0"):
> > Remus doesn''t really use xend at all. It has its own bindings
to libxc
> > and reimplements the migration control layer. I''d had tighter
> > integration with xend on my TODO list, but it sounds like I may not
> > need to do that any more.
> 
> Surely it uses xend at the receiving end at the very least ?  The
> remus utility connects to something at the destination.
> 
> xl doesn''t have a daemon at the far end; xl migration is done over
> ssh by default (although you can make it use some other transport if
> you like).
Yes, that''s true -- Remus does just open up the xend migration socket
for sending. But if xl has support for migration, then it sounds like
remus just needs a different handshaking shim to set up its file
descriptor, which shouldn''t be too bad. On the other hand, I expect
ssh will generally be too heavyweight for Remus.
> > I haven''t been paying close attention to the libxl patches
flying by
> > on the list, but it looks like the area where libxl and Remus might
> > interact in the short term is your cleanups to the save image
> > format. Off the top of my head, I remember having to hack up a
> > slightly different stream format for HVM because the qemu blob had no
> > length prefix.
> 
> The save image format is not defined by libxl but by the command-line
> tool xl.  I expect it will move to the "kit of parts" library
> libxlutil.
> 
> Ian.
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
> 
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel