similar to: [PATCH net-next] MAINTAINERS: add myself as maintainer of xen-netback

The code to detect fragments in checksum_setup() was missing for IPv4 and too eager for IPv6. (It transpires that Windows seems to send IPv6 packets with a fragment header even if they are not a fragment - i.e. offset is zero, and M bit is not set). Signed-off-by: Paul Durrant <paul.durrant@citrix.com> Cc: Wei Liu <wei.liu2@citrix.com> Cc: Ian Campbell <ian.campbell@citrix.com>

time_after_eq() only works if the delta is < MAX_ULONG/2. For a 32bit Dom0, if netfront sends packets at a very low rate, the time between subsequent calls to tx_credit_exceeded() may exceed MAX_ULONG/2 and the test for timer_after_eq() will be incorrect. Credit will not be replenished and the guest may become unable to send packets (e.g., if prior to the long gap, all credit was exhausted).

Some old Windows frontends fail to transition through the xenbus Closing state and move directly from Connected to Closed. Handle this case properly. Signed-off-by: Paul Durrant <paul.durrant@citrix.com> Cc: David Vrabel <david.vrabel@citrix.com> Cc: Wei Liu <wei.liu2@citrix.com> Cc: Ian Campbell <ian.campbell@citrix.com> --- drivers/net/xen-netback/xenbus.c | 2 ++ 1

This dependence is undesirable and logically incorrect. It''s undesirable because Xen network protocol should not depend on a OS-specific constant. It''s incorrect because the ring slots required doesn''t correspond to the number of frags a SKB has (consider compound page frags). This patch removes this dependence by correctly counting the ring slots required.

When counting required slots for skb, netback directly uses DIV_ROUND_UP to get slots required by header data. This is wrong when offset in the page of header data is not zero, and is also inconsistent with following calculation for required slot in netbk_gop_skb. In netbk_gop_skb, required slots are calculated based on offset and len in page of header data. It is possible that required slots

This patch adds code to handle SKB_GSO_TCPV6 skbs and construct appropriate extra or prefix segments to pass the large packet to the frontend. New xenstore flags, feature-gso-tcpv6 and feature-gso-tcpv6-prefix, are sampled to determine if the frontend is capable of handling such packets. Signed-off-by: Paul Durrant <paul.durrant@citrix.com> Cc: Wei Liu <wei.liu2@citrix.com> Cc: David

Hi, i have just install debian wheezy and xen-hypervisor-4.1-amd64 helped with http://wiki.debian.org/Xen http://wiki.xenproject.org/wiki/Xen_Beginners_Guide#Installing_Debian_Squeeze created test.cfg http://pastebin.com/D5Wsx6eB xl create test.conf Parsing config file test.conf xc: info: VIRTUAL MEMORY ARRANGEMENT: Loader: 0000000000100000->0000000000174170 TOTAL:

We''ve been hitting the following issue on a variety of hosts and recent Xen/dom0 version combinations. Here''s an excerpt from our latest: Xen: 4.1.4 (xenbits @ 23432) Dom0: 3.7.1-x86_64 BUG: unable to handle kernel NULL pointer dereference at 000000000000001c IP: [<ffffffff8141a301>] evtchn_from_irq+0x11/0x40 PGD 0 Oops: 0000 [#1] SMP Modules linked in: ebt_comment

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

Netback and netfront only use one event channel to do tx / rx notification. This may cause unnecessary wake-up of process routines. This patch adds a new feature called feautre-split-event-channel to netback, enabling it to handle Tx and Rx event separately. Netback will use tx_irq to notify guest for tx completion, rx_irq for rx notification. If frontend doesn''t support this feature,

hyperv_net: - set min/max_mtu, per Haiyang, after rndis_filter_device_add virtio_net: - set min/max_mtu - remove virtnet_change_mtu vmxnet3: - set min/max_mtu xen-netback: - min_mtu = 0, max_mtu = 65517 xen-netfront: - min_mtu = 0, max_mtu = 65535 unisys/visor: - clean up defines a little to not clash with network core or add redundat definitions CC: netdev at vger.kernel.org CC:

hyperv_net: - set min/max_mtu, per Haiyang, after rndis_filter_device_add virtio_net: - set min/max_mtu - remove virtnet_change_mtu vmxnet3: - set min/max_mtu xen-netback: - min_mtu = 0, max_mtu = 65517 xen-netfront: - min_mtu = 0, max_mtu = 65535 unisys/visor: - clean up defines a little to not clash with network core or add redundat definitions CC: netdev at vger.kernel.org CC:

Hi All, I am sure this has been answered somewhere in the list in the past, but I can''t find it. I was wondering if the linux guest netfront driver has GRO support in it. tcpdump shows packets coming in with 1500 bytes, although the eth0 in dom0 and the vif corresponding to the linux guest in dom0 is showing that they receive large packet: In dom0: eth0 Link encap:Ethernet HWaddr

EFI_XEN_OVMF_INFO is defined to accept configurations from hvmloader. It must match the definition on Xen side. XenInfo is extended to include necessary bits as well. Currently only E820 map is in use. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Wei Liu <wei.liu2@citrix.com> --- OvmfPkg/Include/Guid/XenInfo.h | 7 +++++++ OvmfPkg/PlatformPei/Xen.h | 44

# HG changeset patch # User Wei Liu <wei.liu2@citrix.com> # Date 1329922671 0 # Node ID bb2986677df84b9709a60aea7e70ffd9f9e23f76 # Parent d433a9cb0089683b8f75458807c5437341f2cdcc Add gtags target for xen/Makefile. Also update .hgignore. Signed-off-by: Wei Liu <wei.liu2@citrix.com> diff --git a/.hgignore b/.hgignore --- a/.hgignore +++ b/.hgignore @@ -23,6 +23,7 @@ ^\.config$ ^\.pc

Hi Jan Back before 4.3 release you complaint about the hardcoded modprobe for blktap / blktap2 in xencommons script. I started to look into it this week and tried to do this modprobe automatically in libxl (that''s the idea we discussed before 4.3 IIRC). Unfortunately I didn''t manage to find any canonical documents on how a user space process can trigger a modprobe.

Some firmware, such as OVMF relies on this value to get the size of extra memory above 4GB. Seabios in Xen doesn''t need this as it gets e820 directly from Xen. Rombios doesn''t read this value. Signed-off-by: Wei Liu <wei.liu2@citrix.com> --- tools/firmware/hvmloader/hvmloader.c | 15 +++++++++++++++ 1 file changed, 15 insertions(+) diff --git

Hi All, I am working on creating storage driver domain with xen-4.3.0 . I am referring this - http://wiki.xen.org/wiki?title=Storage_driver_domains&oldid=9371 I have created Storage domain with xl utility of xen, then followed above wiki for rest of the steps, additionally I did install blktap-dkms package also- Following xen processes are running on Domain 0:

Hi All, I am working on creating storage driver domain with xen-4.3.0 . I am referring this - http://wiki.xen.org/wiki?title=Storage_driver_domains&oldid=9371 I have created Storage domain with xl utility of xen, then followed above wiki for rest of the steps, additionally I did install blktap-dkms package also- Following xen processes are running on Domain 0:

All the resources allocated based on xen_blkif_reqs are global in blkback. While (without having measured anything) I think that this is bad from a QoS perspective (not the least implied from a warning issued by Citrix''es multi-page-ring patches: if (blkif_reqs < BLK_RING_SIZE(order)) printk(KERN_WARNING "WARNING: " "I/O request space (%d reqs) < ring