summaryrefslogtreecommitdiffstats
path: root/server/spicevmc.c
Commit message (Collapse)AuthorAgeFilesLines
* red_channel: monitor connection latency using MSG_PINGYonit Halperin2013-04-221-0/+1
|
* server: add "port" channel supportMarc-André Lureau2012-12-051-16/+136
| | | | | | | | | | | | | | | | | A Spice port channel carry arbitrary data between the Spice client and the Spice server. It may be used to provide additional services on top of a Spice connection. For example, a channel can be associated with the qemu monitor for the client to interact with it, just like any qemu chardev. Or it may be used with various protocols, such as the Spice Controller. A port kind is identified simply by its fqdn, such as org.qemu.monitor, org.spice.spicy.test or org.ovirt.controller... The channel is based on Spicevmc which simply tunnels data between client and server, with a few additional messages. See the description of the channel protocol in spice-common history.
* red_channel: remove unused migrate flag from RedChannelYonit Halperin2012-08-271-1/+0
| | | | The relevant flags reside in RedChannelClient and RedClient
* char_device: don't connect a migrated client if the state of the device ↵Yonit Halperin2012-08-271-2/+6
| | | | | | | | might have changed since it was created If reading/writing from the device have occured before migration data has arrived, the migration data might no longer be relvant, and we disconnect the client.
* spicevmc migration: restore migration dest state from migration dataYonit Halperin2012-08-271-2/+29
|
* spicevmc migration: send migration dataYonit Halperin2012-08-271-5/+55
|
* spicevmc: send MSG_MIGRATE upon vm migration completionYonit Halperin2012-08-271-6/+0
| | | | | The above is the default behaviour for red_channel_client, if client_cbs.migrate is not registered as part of red_channel_register_client_cbs
* char device migration: don't read or write from/to the device while waiting ↵Yonit Halperin2012-08-271-1/+2
| | | | for migraion data
* red_channel: handle sending SPICE_MSG_MIGRATEYonit Halperin2012-08-271-1/+2
| | | | | | | The relevant code is common to all channels. The patch also contains a fix to the return value for handle_migrate_data callback: s/uint64_t/int
* spicevmc: use SpiceCharDeviceState for writing to the guest deviceYonit Halperin2012-07-031-25/+24
| | | | | | With SpiceCharDeviceState, spicevmc now supports partial writes, and storing data that is received from the client after the device is stopped, instead of attempting to write it to the guest.
* spicevmc: employ SpiceCharDeviceState for managing reading from the guest deviceYonit Halperin2012-07-031-29/+115
| | | | | | | | This patch and the following one do not introduce tokening to the spicevmc channel. But this can be done easily later, by setting the appropriate variables in SpiceCharDeviceState (after adding the appropriate protocol messages, and implementing this in the client side).
* Use the spice-common logging functionsMarc-André Lureau2012-03-251-3/+3
| | | | | It will abort by default for critical level messages. That behaviour can be tuned at runtime.
* Use the spice-common submoduleMarc-André Lureau2012-03-251-3/+3
| | | | | | | | | | | | | | | | | | This patch will replace the common/ directory with the spice-common project. It is for now a simple project subdirectory shared with spice-gtk, but the goal is to make it a proper library later on. With this change, the spice-server build is broken. The following commits fix the build, and have been seperated to ease the review. v2 - moves all the generated marshallers to spice-common library - don't attempt to fix windows VS build, which should somehow be splitted with spice-common (or built from tarball only to avoid generation tools/libs deps) v3 - uses libspice-common-client - fix a mutex.h inclusion reported by Alon
* server: don't fail on ENOPROTOOPT from setsockoptNahum Shalman2012-03-121-1/+1
| | | | | | If we allow listening on arbitrary sockets like unix sockets, we can get ENOPROTOOPT errors from setsockopt calls that set TCP specific options. This should be allowed to happen.
* Ensure all members of ChannelCbs and ClientCbs are either assigned or NULLHans de Goede2012-03-101-2/+2
| | | | | | | | | | | | | | | While git-bisecting another issue I ended up hitting and not recognizing the bug fixed by commit 7a079b452b026d6ce38f95dcc397fa64b059fffb. While fixing this (again) I noticed that (even after the fix) not all users of ChannelCbs first zero it. So this patch ensures that all users of ChannelCbs first zero it, and does the same for ClientCbs while at it. Since before this patch there were multiple zero-ing styles, some using memset and other using a zero initializer this patch also unifies all the zero-ing to use a NULL initializer for the first element. Signed-off-by: Hans de Goede <hdegoede@redhat.com>
* server/spicevmc: Don't destroy the rcc twiceHans de Goede2012-02-201-3/+3
| | | | | | | | | | | | | | | | | | | | | | | spicevmc calls red_channel_client_destroy() on the rcc when it disconnects since we don't want to delay the destroy until the session gets closed as spicevmc channels can be opened, closed and opened again during a single session. This causes red_channel_client_destroy() to get called twice, triggering an assert, when a connected channel gets destroyed. This was fixed with commit ffc4de01e6f9ea0676f17b10e45a137d7e15d6ac for the case where: a spicevmc channel was open on client disconnected, and the main channel disconnect gets handled first. But the channel can also be destroyed when the chardev gets unregistered with the spice-server. This path still triggers the assert. This patch fixes this by adding a destroying flag to the rcc struct, and also moves the previous fix over to the same, more clean, method of detecting this special case. Signed-off-by: Hans de Goede <hdegoede@redhat.com>
* server: Don't complain if setsockopt NODELAY fails on unix socketsHans de Goede2012-01-181-2/+4
| | | | | | | | | | | | With Daniel P. Berrange's patches to allow use of pre-supplied fd's as channels, we can no longer be sure that our connections are TCP sockets, so it makes no sense to complain if a TCP/IP specific setsockopt fails with an errno of ENOTSUP. Note that this extends Daniel's commit 492ddb5d1d595e2d12208f4602b18e4432f4e6b4 which already added the same check to server/inputs_channel.c Signed-off-by: Hans de Goede <hdegoede@redhat.com>
* server: Limit the access to SpiceDataHeader of messages - only via red_channel.Yonit Halperin2012-01-121-10/+14
|
* spicevmc: Set sockopt nodelay for usbredir channelsHans de Goede2011-12-221-0/+15
| | | | | | We want as little latency as possible with usb channels. Signed-off-by: Hans de goede <hdegoede@redhat.com>
* spicevmc: Fix assert when still connected on session disconnect (fdo#43903)Hans de Goede2011-12-181-1/+5
| | | | | | | | | | | | | | | | | | | | | | | | | Currently when the main channel disconnects while a spicevmc channel (such as a usbredir channel) is still connected, qemu will abort with the following message: ring_remove: ASSERT item->next != NULL && item->prev != NULL failed This is caused by red_client_destroy() first calling: rcc->channel->client_cbs.disconnect(rcc); And then calling: red_channel_client_destroy(rcc); For each channel. This is fine, but the spicevmc disconnect code does a red_channel_client_destroy(rcc) itself since as usb devices are added / removed, the channels carrying their traffic get connected / disconnected and they get re-used for new devices, which won't work if the old channel is still there when the new connection comes in. This patch fixes the double destroy when there are still spicevmc channels connected by not doing the red_channel_client_destroy from the spicevmc disconnect code when not just the channel, but the entire client is disconnecting. Signed-off-by: Hans de Goede <hdegoede@redhat.com>
* server: set & test channel capabilities in red_channelYonit Halperin2011-11-021-1/+3
| | | | | | | The code for setting and testing channel capabilities was unnecessarily duplicated. Now it is in red_channel. RedsChannel was dropped from Reds; It was used only for holding the channels common capabilities, which are now held in RedChannel.
* Rename usbredir channel code to spicevmcHans de Goede2011-08-251-0/+275
While discussing various things with Alon in Vancouver, it came up that having a channel which simply passes through data coming out of a qemu chardev frontend unmodified, like the usbredir channel does, can be used for a lot of other cases too. To facilitate this the usbredir channel code will be turned into a generic spicevmc channel, which is just a passthrough to the client, from the spicevmc chardev. This patch renames usbredir.c to spicevmc.c and changes the prefix of all functions / structs to match. This should make clear that the code is not usbredir specific. Some examples of why having a generic spicevmc pass through is good: 1) We could add a monitor channel, allowing access to the qemu monitor from the spice client, since the monitor is a chardev frontend we could re-use the generic spicevmc channel server code, so all that is needed to add this (server side) would be reserving a new channel id for this. 2) We could allow users to come up with new channels of their own, without requiring qemu or server modification. The idea is to allow doing something like this on the qemu startup cmdline: -chardev spicevmc,name=generic,channelid=128 To ensure these new "generic" channels cannot conflict with newly added official types, they must start at the SPICE_CHANNEL_USER_DEFINED_START value (128). These new user defined channels could then either be used with a special modified client, with client plugins (if we add support for those), or by exporting them on the client side for use by an external ap, see below. 3) We could also add support to the client to make user-defined channels end in a unix socket / pipe, allowing handling of the data by an external app, we could for example have a new spice client cmdline argument like this: --custom-channel unixsocket=/tmp/mysocket,channelid=128 This would allow for something like: $random app on guest -> virtio-serial -> spicevmc chardev -> -> spicevmc channel -> unix socket -> $random app on client 4) On hind sight this could also have been used for the smartcard stuff, with a 1 channel / reader model, rather then the current multiplexing code where we've our own multiplexing protocol wrapper over the libcacard smartcard protocol. Signed-off-by: Hans de Goede <hdegoede@redhat.com>