[Spice-commits] Changes to 'usbredir'
Hans de Goede
jwrdegoede at kemper.freedesktop.org
Tue May 3 06:55:44 PDT 2011
New branch 'usbredir' available with the following commits:
commit 14767a5ca6651695a8290063f7aec3ce28c089cd
Author: Hans de Goede <hdegoede at redhat.com>
Date: Tue May 3 13:01:07 2011 +0200
Fix a number of unused-but-set-variable warnings (new with gcc-4.6)
commit ce697793d30443d1093e451f30581a5ed7564b43
Author: Hans de Goede <hdegoede at redhat.com>
Date: Wed Feb 2 17:46:00 2011 +0100
usb: control buffer fixes
Windows allows control transfers to pass up to 4k of data, so raise our
control buffer size to 4k. For control out transfers the usb core code copies
the control request data to a buffer before calling the device's handle_control
callback. Add a check for overflowing the buffer before copying the data.
Signed-off-by: Hans de Goede <hdegoede at redhat.com>
commit 04e41f25cc705aa445598232a9ce62c22611ea22
Author: Hans de Goede <hdegoede at redhat.com>
Date: Wed Feb 2 17:36:29 2011 +0100
usb-linux: use usb_generic_handle_packet()
Make the linux usb host passthrough code use the usb_generic_handle_packet()
function, rather then the curent DYI code. This removes 200 lines of almost
identical code.
Signed-off-by: Hans de Goede <hdegoede at redhat.com>
commit 0217684699418d5a5834de42082a548e469af510
Author: Hans de Goede <hdegoede at redhat.com>
Date: Wed Feb 2 16:33:13 2011 +0100
usb: Pass the packet to the device's handle_control callback
This allows using the generic usb_generic_handle_packet function from
device code which does ASYNC control requests (such as the linux host
pass through code).
Signed-off-by: Hans de Goede <hdegoede at redhat.com>
commit 9fde6d5af0ce3203f175b3bcdcc12ec9246b4c4b
Author: Hans de Goede <hdegoede at redhat.com>
Date: Fri Nov 26 19:11:03 2010 +0100
usb-linux: Add support for buffering iso out usb packets
Extend the iso buffering code to also buffer iso out packets, this
fixes for example using usb speakers with usb redirection.
Signed-off-by: Hans de Goede <hdegoede at redhat.com>
commit fd81e6dc4dcf6addfb1e211a0b93101e61a1995f
Author: Hans de Goede <hdegoede at redhat.com>
Date: Fri Nov 26 15:02:16 2010 +0100
usb-linux: We only need to keep track of 15 endpoints
Currently we reserve room for endpoint data for 16 endpoints, but given
that we only use endpoint data for endpoints 1-15, and always index the
array with the endpoint-number - 1, 15 is enough.
Signed-off-by: Hans de Goede <hdegoede at redhat.com>
commit 073d65e7d0eef94d346aa00ea6cee02cabc82a87
Author: Hans de Goede <hdegoede at redhat.com>
Date: Fri Nov 26 14:59:35 2010 +0100
usb-linux: Refuse iso packets when max packet size is 0 (alt setting 0)
Refuse iso usb packets when then max packet size for the endpoint is 0,
this avoids an abort in usb_host_alloc_iso() caused by trying to qemu_malloc
a 0 bytes large buffer.
commit 7ea0edcbafa3f0ef180ecc31d788b4fb151a3458
Author: Hans de Goede <hdegoede at redhat.com>
Date: Fri Nov 26 14:56:17 2010 +0100
usb-linux: Refuse packets for endpoints which are not in the usb descriptor
If an endpoint is not in the usb descriptor we've no idea what kind of
endpoint it is and thus how to handle it, refuse packages in this case.
Signed-off-by: Hans de Goede <hdegoede at redhat.com>
commit 0e3c826cdbfdfdf39e778b4b68bfacab954d906e
Author: Hans de Goede <hdegoede at redhat.com>
Date: Fri Nov 26 11:41:08 2010 +0100
usb-linux: Add support for buffering iso usb packets
Currently we are submitting iso packets to the host one at a time, as we
receive them from the emulated host controller. This has 2 problems:
1) If we were fast enough to submit every packet in time for the next host host
controller usb frame, we would be generating 1000 hardware interrupts per
second on the host
2) We are not fast enough to submit every packet in time for the next host host
controller usb frame, causing us to not submit iso urbs in some usb frames
which causes devices with an endpoint with an interval of 1 ms (so every
frame) to loose data. This causes for example ubs-1.1 webcams to not work
properly (usb-2.0 is not supported at all atm).
This patch fixes both problems by changing the iso packet pass through handling
to buffer packets. This version only does so for iso input packets (webcams,
audio in) I'm working on a second patch extending this to iso output packets
(audio out).
This patch makes use of the linux batching of iso packets in one urb.
When an iso in packet gets received from the emulated host controller,
it immediately submits 3 urbs with 32 iso in packets each. This causes
the host to only get an hw interrupt every 32 packets dropping the
interrupt rate to 32 interrupts per second and gives it a queue of urbs
to work from once the first 32 iso in packets have been received to make sure
no packets are dropped.
Besides submitting a whole bunch or urbs as soon as the first urb is
received, effectively creating a buffer inside the kernel, this patch also
gets rid of the asynchroneous completion for iso in urbs. Instead they are
only marked as complete in the fd write callback (which usbfs uses to signal
complete urbs). These complete packets then get consumed by returning them
synchroneously to the emulated host controller when it submits an iso in
packet for the ep in question. When no complete packets are ready (which
happens when the stream is starting) a 0 length packet gets returned to
the emulated host controller.
With this patch I've several usb-1.1 webcams working well with usb pass
through, where as without this patch none of them work.
Signed-off-by: Hans de Goede <hdegoede at redhat.com>
commit 53fd949e133c5ab945ddde13c54068a9c14c122a
Author: Hans de Goede <hdegoede at redhat.com>
Date: Wed Nov 24 12:57:59 2010 +0100
usb-linux: Get the alt. setting from sysfs rather then asking the dev
At least one device I have lies when receiving a USB_REQ_GET_INTERFACE,
always returning 0 even if the alternate setting is different. This is
likely caused because in practice this control message is never used as
the operating system's usb stack knows which alternate setting it has
told the device to get into, and thus this ctrl message does not get
tested by device manufacturers.
When usb_fs_type == USB_FS_SYS, the active alt. setting can be read directly
from sysfs, which allows using this device through qemu's usb redirection.
More in general it seems a good idea to not send needless control msg's to
devices, esp. as the code in question is called every time a set_interface
is done. Which happens multiple times during virtual machine startup, and
when device drivers are activating the usb device.
Signed-off-by: Hans de Goede <hdegoede at redhat.com>
commit 8a2a824eb00e720e04914eba0ae4473d30584850
Author: Hans de Goede <hdegoede at redhat.com>
Date: Wed Nov 24 12:50:00 2010 +0100
usb-linux: introduce a usb_linux_alt_setting function
The next patch in this series introduces multiple ways to get the
alt setting dependent upon usb_fs_type, it is cleaner to put this
into its own function.
Note that this patch also changes the assumed alt setting in case
of an error getting the alt setting to be 0 (a sane default) rather
then the interface numberwhich makes no sense.
Signed-off-by: Hans de Goede <hdegoede at redhat.com>
commit cd12d27e40191df610a2314ae3314b5e5db5b003
Author: Hans de Goede <hdegoede at redhat.com>
Date: Sun Mar 27 16:43:54 2011 +0200
spice: add option for disabling copy paste support
Some people want to be able disable spice's guest <-> client copy paste support
because of security considerations.
commit 1707442d723608aacbc0a03f80c3575bdabf8a80
Author: Hans de Goede <hdegoede at redhat.com>
Date: Tue Mar 22 16:28:41 2011 +0100
spice-qemu-char: Fix flow control in client -> guest direction
In the old spice-vmc device we used to have:
last_out = virtio_serial_write(&svc->port, p, MIN(len, VMC_MAX_HOST_WRITE));
if (last_out > 0)
...
Now in the chardev backend we have:
last_out = MIN(len, VMC_MAX_HOST_WRITE);
qemu_chr_read(scd->chr, p, last_out);
if (last_out > 0) {
...
Which causes us to no longer detect if the virtio port is not ready
to receive data from us. chardev actually has a mechanism to detect this,
but it requires a separate call to qemu_chr_can_read, before calling
qemu_chr_read (which return void).
This patch uses qemu_chr_can_read to fix the flow control from client to
guest.
Signed-off-by: Hans de Goede <hdegoede at redhat.com>
commit 9ca85825effb4a13b438a64a344e5c69b1de8e0a
Author: Hans de Goede <hdegoede at redhat.com>
Date: Fri Mar 18 15:35:27 2011 +0100
spice-chardev: listen to frontend guest open / close
Note the vmc_register_interface() in spice_chr_write is left in place
in case someone uses spice-chardev with a frontend which does not have
guest open / close notification.
Signed-off-by: Hans de Goede <hdegoede at redhat.com>
commit 37ff04257cd8e9536f76bb2da23ec8b782794b3d
Author: Hans de Goede <hdegoede at redhat.com>
Date: Fri Mar 18 15:30:45 2011 +0100
virtio-console: notify backend of guest open / close
Signed-off-by: Hans de Goede <hdegoede at redhat.com>
commit 41e3e0d31bdef3dd9078d684a363e97f1d0a3751
Author: Hans de Goede <hdegoede at redhat.com>
Date: Fri Mar 18 15:23:21 2011 +0100
chardev: Allow frontends to notify backends of guest open / close
Some frontends know when the guest has opened the "channel" and is actively
listening to it, for example virtio-serial. This patch adds 2 new qemu-chardev
functions which can be used by frontends to signal guest open / close, and
allows interested backends to listen to this.
Signed-off-by: Hans de Goede <hdegoede at redhat.com>
commit cb2c124a428798e4ada3e55a763cb529298933c9
Author: Alon Levy <alevy at redhat.com>
Date: Tue Mar 22 12:28:00 2011 +0200
spice-qemu-char.c: remove intermediate buffer
BZ: 672191
upstream: not submitted (explained below)
virtio-serial's buffer is valid when it calls us, and we don't
access it otherwise: vmc_read is only called in response to wakeup,
or else we set datalen=0 and throttle. Then vmc_read is called back,
we return 0 (not accessing the buffer) and set the timer to unthrottle.
Also make datalen int and not ssize_t (to fit spice_chr_write signature).
This relied on the previous patch that introduces throttling, which
can't go upstream right now as explained in that patch.
commit 4d1ded86bb6ccab92f32a2ea630f8e4728819925
Author: Alon Levy <alevy at redhat.com>
Date: Tue Mar 22 12:27:59 2011 +0200
spice-qemu-char.c: add throttling
BZ: 672191
upstream: not submitted (explained below)
Adds throttling support to spicevmc chardev. Uses a timer to avoid recursing:
1. spice-server: reds.c: read_from_vdi_port
2. qemu: spice-qemu-char.c: vmc_read
3. chr_write_unblocked
(calls virtio_serial_throttle_port(port, false))
4. qemu: virtio ...
5. qemu: spice-qemu-char.c: spice_chr_write
6. qemu: spice-qemu-char.c: wakeup (calls into spice-server)
7. spice-server: ...
8. qemu: spice-qemu-char.c: vmc_read
Instead, in vmc_read if we were throttled and we are just about to return
all the bytes we will set a timer to be triggered immediately to call
chr_write_unblocked. Then we return after 2 above, and 3 is called from the
timer callback. This also means we can later remove some ugly recursion protection
from spice-server.
The other tricky point in this patch is not returning the leftover chunk twice.
When we throttle, by definition we have data that spice server didn't consume.
It is being kept by virtio-serial, and by us. The next vmc_read callback needs
to not return it, but just do unthrottling. Then virtio will give us the remaining
chunk as usual in spice_chr_write, and we will pass it to spice server in the
next vmc_read.
This patch relies on Amit's series to expose throttling to chardev's, which
was not accepted upstream, and will not be accepted upstream until the mainloop
is reworked to use glib.
commit 852ec9cfa213ee2d48110057b25aea5cdef057de
Author: Amit Shah <amit.shah at redhat.com>
Date: Mon Mar 21 22:06:41 2011 +0100
virtio-console: Enable port throttling when chardev is slow to consume data
When a chardev indicates it can't accept more data, we tell the
virtio-serial code to stop sending us any more data till we tell
otherwise. This helps in guests continuing to run normally while the vq
keeps getting full and eventually the guest stops queueing more data.
As soon as the chardev indicates it can accept more data, start pushing!
Signed-off-by: Amit Shah <amit.shah at redhat.com>
commit 45afbe470c429fcf2585bf47c8407468665f560f
Author: Amit Shah <amit.shah at redhat.com>
Date: Mon Mar 21 22:05:10 2011 +0100
char: Throttle when host connection is down#
When the host-side connection goes down, throttle the virtio-serial bus
and later unthrottle when a connection gets established. This helps
prevent any lost IO (guest->host) while the host connection was down.
Bugzilla: 621484
This commit actually helps the bug mentioned above as no writes will now
get lost because of the throttling done here. With just the patches
sent earlier for that bug, one write will end up getting lost in the
worst case (host d/c, guest write, host connect).
Signed-off-by: Amit Shah <amit.shah at redhat.com>
commit 7c7b371f94edbf7223834f2f691982f7a62f4bfb
Author: Amit Shah <amit.shah at redhat.com>
Date: Mon Mar 21 22:02:47 2011 +0100
char: Equip the unix/tcp backend to handle nonblocking writes#
Now that the infrastructure is in place to return -EAGAIN to callers,
individual char drivers can set their update_fd_handlers() function to
set or remove an fd's write handler. This handler checks if the driver
became writable.
A generic callback routine is used for unblocking writes and letting
users of chardevs know that a driver became writable again.
Signed-off-by: Amit Shah <amit.shah at redhat.com>
commit 80ab183ba79b32c57d7142f972daa423866cf5ce
Author: Amit Shah <amit.shah at redhat.com>
Date: Mon Mar 21 22:00:27 2011 +0100
char: Update send_all() to handle nonblocking chardev write requests
The send_all function is modified to return to the caller in case the
driver cannot handle any more data. It returns -EAGAIN or
WSAEWOULDBLOCK on non-Windows and Windows platforms respectively. This
is only done when the caller sets a callback function handler indicating
it's not interested in blocking till the driver has written out all the
data.
Currently there's no driver or caller that supports this. Future
commits will add such capability.
Signed-off-by: Amit Shah <amit.shah at redhat.com>
commit 03d17dbb2ecde89770a671db061437e2dad6d032
Author: Amit Shah <amit.shah at redhat.com>
Date: Mon Mar 21 21:41:42 2011 +0100
char: Add framework for a 'write unblocked' callback
The char layer can let users know that the driver will block on further
input. For users interested in not blocking, they can assign a function
pointer that will be called back when the driver becomes writable. This
patch just adds the function pointers to the CharDriverState structure,
future patches will enable the nonblocking and callback functionality.
Signed-off-by: Amit Shah <amit.shah at redhat.com>
commit c1f5760e6496840fc98f723aaa863cc9d08de14a
Author: Amit Shah <amit.shah at redhat.com>
Date: Mon Mar 21 20:32:58 2011 +0100
iohandlers: Add enable/disable_write_fd_handler() functions
These will be used to provide a cleaner API for the nonblocking case.
Signed-off-by: Amit Shah <amit.shah at redhat.com>
commit d407a2d4d033a15946003586ca7df649bfbf8eed
Author: Amit Shah <amit.shah at redhat.com>
Date: Mon Mar 21 20:31:45 2011 +0100
char: Add a QemuChrHandlers struct to initialise chardev handlers
Instead of passing each handler in the qemu_add_handlers() function,
create a struct of handlers that can be passed to the function instead.
Signed-off-by: Amit Shah <amit.shah at redhat.com>
commit 185ec3f959ec290aa81a553ff5ec046e6471483c
Author: Amit Shah <amit.shah at redhat.com>
Date: Mon Mar 21 21:57:47 2011 +0100
char: Split out tcp socket close code in a separate function
Signed-off-by: Amit Shah <amit.shah at redhat.com>
More information about the Spice-commits
mailing list