similar to: [PATCH V5 2/7] xen-netfront: frags -> slots in xennet_get_responses

Signed-off-by: Ian Campbell <ian.campbell@citrix.com> Cc: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Cc: xen-devel@lists.xensource.com Cc: netdev@vger.kernel.org --- drivers/net/xen-netfront.c | 34 +++++++++++++++++++--------------- 1 files changed, 19 insertions(+), 15 deletions(-) diff --git

Hi all, my name is Hirofumi Tsujimura. We are porting and testing a PV-on-HVM in the IPF. This is a first time to send mail. I probably found the problem when I tested the VNIF. My operation for the test is following. 1. create a domain VTx and attach the VNIF in it. 2. create a domain U. 3. send a packet to the domain VTx from the domain U with ping command. Then, the domain VTx

Tune xen_netbk_count_requests to not touch working array beyond limit, so that we can make working array size constant. Signed-off-by: Wei Liu <wei.liu2@citrix.com> --- drivers/net/xen-netback/netback.c | 26 +++++++++++++++++++++----- 1 file changed, 21 insertions(+), 5 deletions(-) diff --git a/drivers/net/xen-netback/netback.c b/drivers/net/xen-netback/netback.c index

add segring support in blkback Signed-off-by: Ronghui Duan <ronghui.duan@intel.com> diff --git a/drivers/block/xen-blkback/blkback.c b/drivers/block/xen-blkback/blkback.c index 45eda98..0bbc226 100644 --- a/drivers/block/xen-blkback/blkback.c +++ b/drivers/block/xen-blkback/blkback.c @@ -60,6 +60,10 @@ static int xen_blkif_reqs = 64; module_param_named(reqs, xen_blkif_reqs, int, 0);

From: Julia Lawall <julia at diku.dk> The kernel.h macro DIV_ROUND_UP performs the computation (((n) + (d) - 1) / (d)) but is perhaps more readable. An extract of the semantic patch that makes this change is as follows: (http://www.emn.fr/x-info/coccinelle/) // <smpl> @haskernel@ @@ #include <linux/kernel.h> @depends on haskernel@ expression n,d; @@ ( - (n + d - 1) / d +

Align ip header to a 16 byte boundary to avoid unaligned access like other drivers. Without this patch, xen-netfront doesn't work well on ia64. Signed-off-by: Isaku Yamahata <yamahata at valinux.co.jp> --- drivers/net/xen-netfront.c | 5 ++++- 1 files changed, 4 insertions(+), 1 deletions(-) diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-netfront.c index 3c3dd40..7416f41

Align ip header to a 16 byte boundary. This patch eliminates noisy warnings on IA64. Signed-off-by: Isaku Yamahata <yamahata at valinux.co.jp> --- drivers/net/xen-netfront.c | 5 ++++- 1 files changed, 4 insertions(+), 1 deletions(-) diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-netfront.c index 44aed80..2724688 100644 --- a/drivers/net/xen-netfront.c +++

There would seem to be a potential deadlock in the netfront accelerator plugin support. When the configured accelerator changes in xenstore, netfront tries to load the new plugin using request_module(). It does this from a workqueue work item. request_module() will invoke modprobe which in some circumstances (I''m not sure exactly what - I''ve not managed to reproduce it myself)

In netfront, the current driver reserves pools of grant refs for the tx and rx paths, each big enough to satisfy one virtual nic. With more than one nic active you will run out. Both the tx and rx path will BUG() when you do. This patch creates separate tx and rx ref pools for each interface. Signed-off-by: Jim Dykman <dykman@us.ibm.com> Jim

This patch fixes the root cause of bug 183: per-interface transaction ids are being used to index global tables. Signed-off-by: Jim Dykman <dykman@us.ibm.com> Jim _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel

> How could their be more than one layer of encapsulation > greater than MTU? > When the packet comes into dom0, it is already <= MTU. It > gets encapsulated > with another layer of routing data, and sent to its > destination. So, it is > at maximum size MTU+24. Dom0 may want to put extra headers on the *front* of the packet. By having the packet starting a fair

__initcall is for things which are always built into the kernel. Kconfig says netfront is tristate (although without a module_exit, the module won''t be unloadable). Trivial fix, Rusty. --- linux-2.6.10-xen-sparse/drivers/xen/netfront/netfront.c.~1~ 2005-01-11 15:35:59.000000000 +1100 +++ linux-2.6.10-xen-sparse/drivers/xen/netfront/netfront.c 2005-01-17 15:41:21.000000000 +1100 @@

From: pbonzini@redhat.com # HG changeset patch # User Paolo Bonzini <pbonzini@redhat.com> # Date 1318837036 -7200 # Node ID eb896361fc70b60b9a257d0c82e19633a11b9d41 # Parent 3c900d6a5f6a51ff1547f21fef30ab8b92feccc9 netback: disable features not supported by netfront Netback works by first setting all possible features, and then resetting some after connection, if the front-end

The attached patch adds a netfront driver to mini-os. This version is much improved compared to the one previously posted (ie. it actually works this time). Jacob _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel

Hello, Please consider including upstream commit 08e34eb14fe4cfd934b5c169a7682a969457c4ea in the next v3.2.y release. It was included upstream as of v3.3-rc1. It has been tested and confirmed to resolve http://bugs.launchpad.net/bugs/1154608 . commit 08e34eb14fe4cfd934b5c169a7682a969457c4ea Author: Laszlo Ersek <lersek at redhat.com> Date: Sun Dec 11 01:48:59 2011 +0000

Hello, Please consider including upstream commit 08e34eb14fe4cfd934b5c169a7682a969457c4ea in the next v3.2.y release. It was included upstream as of v3.3-rc1. It has been tested and confirmed to resolve http://bugs.launchpad.net/bugs/1154608 . commit 08e34eb14fe4cfd934b5c169a7682a969457c4ea Author: Laszlo Ersek <lersek at redhat.com> Date: Sun Dec 11 01:48:59 2011 +0000

Align ip header to a 16 byte boundary to avoid unaligned access like other drivers. Without this patch, xen-netfront doesn't work well on ia64. Signed-off-by: Isaku Yamahata <yamahata at valinux.co.jp> --- drivers/net/xen-netfront.c | 5 ++++- 1 files changed, 4 insertions(+), 1 deletions(-) diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-netfront.c index 3c3dd40..7416f41

Align ip header to a 16 byte boundary to avoid unaligned access like other drivers. Without this patch, xen-netfront doesn't work well on ia64. Signed-off-by: Isaku Yamahata <yamahata at valinux.co.jp> --- drivers/net/xen-netfront.c | 5 ++++- 1 files changed, 4 insertions(+), 1 deletions(-) diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-netfront.c index 3c3dd40..7416f41

cleanup accelerators list on netfront unload Signed-off-by <kmansley@solarflare.com> diff -r fdfd708d2ec4 drivers/xen/netfront/accel.c --- a/drivers/xen/netfront/accel.c Wed Oct 24 15:38:35 2007 +0100 +++ b/drivers/xen/netfront/accel.c Wed Oct 24 16:25:57 2007 +0100 @@ -75,6 +75,24 @@ void netif_init_accel(void) spin_lock_init(&accelerators_lock); } +void netif_exit_accel(void) +{

Hi all, I''ve written earlier to this list concerning building a hardware-assisted network receive path. We have finished the prototype, and done some testing, but are continuing our work for something more general and usable. We have rewritten our Xen code for the current xen-unstable, but we are hitting this limit when we send too many packets (over 25) too quickly to domU. After 25