__copy_to_user in the swiotlb sync function. We cannot
immediately exit the sync function as there may be tail work
to do (e.g., kunmap_atomic). In fact, doing nothing is the
right thing to do and is sufficient to avoid compiler
warnings about not checking the __copy_to_user return value.
Signed-off-by: Keir Fraser <keir@xensource.com>
mapped for DMA_BIDIRECTIONAL streaming access by certain
low-level drivers. This causes an unnecessary copy to the
host buffer that previously caused a fatal kernel page fault.
Signed-off-by: Keir Fraser <keir@xensource.com>
and one for registering the watch on the otherend's path. This means that we
get the fix intended by xen-unstable changeset 8370:39a616126104 (i.e. we only
register the watch once drv->probe() has succeeded), but without breaking block
devices.
Signed-off-by: Ewan Mellor <ewan@xensource.com>
that it is clear they are fully GPL-compatible and satisfy the free
software definitions in include/linux/module.h.
Signed-off-by: Keir Fraser <keir@xensource.com>
Signed-off-by: Stephen Tweedie <sct@redhat.com>
This reverts part of the previous changeset, which prevented
console=tty0 from doing the obvious thing in a domU guest
(i.e., send output on the virtual console). This is because
the tty index ends up being 1.
I don't think setting the index to other than -1 really
buys us anything anyway. Any other driver that specifies
a name that conflicts with us will almost certainly set their
index to -1, so we cannot avoid conflicts by choosing a
more restrictive (singleton) value.
Signed-off-by: Keir Fraser <keir@xensource.com>
index is identical to the device file index. For us, the tty index is
always zero regardless of the device file index.
Signed-off-by: Alex Williamson <alex.williamson@hp.com>
I've changed this to only write "backend" (xenbus_backend.root) into
XENBUS_BASE_PATH. After appending XENBUS_TYPE (also exported) you can
construct the "base path" easily in the scripts. I've completely
removed writing XENBUS_FRONTEND_ID in favour of reading it from the
store at "$XENBUS_PATH/frontend-id".
Avoid re-reading the store over and over for the frontend domain's vm-path.
The patch also fixes a memory leak in backend_bus_id where we
leak the memory referenced by frontend if the function succeeds.
This work is by Christian Limpach.
Signed-off-by: Ewan Mellor <ewan@xensource.com>
offsets within a memory page. Also fix, skb realloc-and-copy
when copying really is required (we were forgetting whether
the packet data is known valid, and checksumming packets that
do not have the csum field filled in).
Signed-off-by: Keir Fraser <keir@xensource.com>
unusable system: it gets into a flood of
Timer ISR/0: Time went backwards: delta=-3566279 cpu_delta=16433721
shadow=2019998373 off=420435384 processed=2444000000
cpu_processed=2424000000
0: 2424000000
1: 2444000000
messages which swamps the console and leaves things almost, but not
quite, completely hung. It is a simple matter to ratelimit these
printks, which completely eliminates the problem.
the check, reading from the store rather than /sys, and checking whether the
VM for apparently-conflicting uses is actually the same (i.e. this is a
migration or a reboot in progress).
This fixes recent failures in 12_block_attach_shared_domU and recloses bug #331.
This fix includes particularly skanky path slicing inside xenbus_probe, which
it would be nice to remove very soon.
The loopback device check still suffers from the problem that filenames over
64 characters long are truncated.
Signed-off-by: Ewan Mellor <ewan@xensource.com>
devices. If you export a device so the importing domain sees it as a
whole disk rather than a partition, then add_disk will try to probe
its partition table. However, we were calling add_disk before the
device was properly connected, and then not connecting it until
add_disk had finished. This meant that we ended up never actually
connecting the device, and any accesses to it would then hang.
Fix this by not calling add_disk until we're connected.
Signed-off-by: Steven Smith, sos22@cam.ac.uk
extensible flag fields in tx requests and rx responses, in
place of specific csum_blank/csum_valid bitfields.
Signed-off-by: Keir Fraser <keir@xensource.com>
loged if the dom0 kernel mangles a packet and tries to checksum
offload it.
This should let the user know what is going wrong (instead of silently
dropping the packet).
Signed-off-by: Jon Mason <jdmason@us.ibm.com>