Steven Smith [Tue, 30 Jun 2009 11:55:48 +0000 (12:55 +0100)]
There's no point in sending lots of little packets to a copying
receiver if we can instead arrange to copy them all into a single RX
buffer. We need to copy anyway, so there's no overhead here, and this
is a little bit easier on the receiving domain's network stack.
Steven Smith [Tue, 30 Jun 2009 11:55:48 +0000 (12:55 +0100)]
Ensure that packet csums are computed correctly when sending a GSO
packet to an interface which supports scatter-gather but not transmit
checksum offloads.
Signed-off-by: Steven Smith <ssmith@xensource.com>
Steven Smith [Tue, 30 Jun 2009 11:55:48 +0000 (12:55 +0100)]
[NETBACK] Try to pull a minimum of 72 bytes into the skb data area
when receiving a packet into netback. The previous number, 64, tended
to place a fragment boundary in the middle of the TCP header options
and led to unnecessary fragmentation in Windows <-> Windows
networking.
Signed-off-by: Steven Smith <ssmith@xensource.com>
Steven Smith [Tue, 30 Jun 2009 11:55:48 +0000 (12:55 +0100)]
It is possible for a frontend to generate a TSO request which doesn't
actually need segmentation (i.e. with size < MTU). Make sure this
doesn't crash the backend.
Steven Smith [Tue, 30 Jun 2009 11:55:48 +0000 (12:55 +0100)]
The Windows drivers push the network frontend to state Closed, then
Initialised, then Closed again as part of device disable. Make sure
the backend doesn't get stuck at closed.
Steven Smith [Tue, 30 Jun 2009 11:55:48 +0000 (12:55 +0100)]
Arrange that netback waits for the hotplug scripts to complete before
going to state Connected. WHQL gets quite upset if it sends packets
which don't arrive, and that can happen if our hotplug scripts are
slow and don't hook the network interface up to the bridge in time.
Steven Smith [Tue, 30 Jun 2009 11:55:48 +0000 (12:55 +0100)]
It turns out that Windows occasionally generates packets in which the
IP and TCP headers are in different fragments. Make sure that the
backends can handle this.
Steven Smith [Tue, 30 Jun 2009 11:55:47 +0000 (12:55 +0100)]
CA-27974: Fix blktap shutdown race due to improper event ordering.
Writing shutdown-done before switching device state to closed (6)
opens a remarkably small race window to fall through: The agent
removes the device directory just before the write to the 'state'
field will recreate it again. This in turn leads to xenbus failing to
remove the device, since removal is guided by directory existence.
With shutdown-done and connection state being rather independent,
trivially fixing event ordering to write shutdown-done last appears
safe but mandatory. Comment this tiny detail.
Steven Smith [Tue, 30 Jun 2009 11:55:47 +0000 (12:55 +0100)]
Close block devices when the pv drivers take over and flush the buffer cache.
- close and free the block devices in qemu when we switch to pv drivers in
the guest
- use BLKFLSBUF to flush the buffer cache, both in qemu and in blkback
Steven Smith [Tue, 30 Jun 2009 11:55:47 +0000 (12:55 +0100)]
sys_mlock and sys_munlock are needed to build the microcode driver as a module.
Index: tmp-mlock/mm/mlock.c
===================================================================
Steven Smith [Tue, 30 Jun 2009 11:55:47 +0000 (12:55 +0100)]
Fix build failure with gcc 4.3
LD .tmp_vmlinux1
arch/x86/kernel/built-in.o: In function `timer_interrupt':
/data/work/linux-2.6.27/linux-2.6/arch/x86/kernel/time_32-xen.c:467: undefined reference to `__udivdi3'
drivers/acpi/ec.c: In function 'acpi_ec_ecdt_probe':
drivers/acpi/ec.c:1015: warning: ISO C90 forbids mixed declarations and code
Signed-off-by: Hannes Eder <hannes@hanneseder.net> Acked-by: Alexey Starikovskiy <astarikovskiy@suse.de> Signed-off-by: Len Brown <len.brown@intel.com>
Steven Smith [Tue, 30 Jun 2009 11:55:47 +0000 (12:55 +0100)]
[BLKTAP] If a frontend moves its request producer pointer backwards
over the backend's request consumer, blktap will currently count to
infinity trying to make the consumer catch up with the producer again.
During this time, it's impossible to shut down the tap device, and
this makes the toolstack very sad. Fix it by deliberately breaking
the interface whenever we notice that this has happened.
Signed-off-by: Steven Smith <steven.smith@eu.citrix.com>
Don't discard NTP sync when updating Xen wallclock time from dom0,
as that's almost the first thing we do when we become synced.
Move the call to ntp_clear() into do_settimeofday(), which is the
only caller of __update_wallclock() that looks like it should break
NTP sync.
This fixes the timer chain that sets Xen's wallclock every minute when
dom0 is NTP synced, which in turn greatly improves wallclock accuracy
in PV domU.
projects / people / ssmith / nc2-2.6.27.git / log