| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
| |
The relevant flags reside in RedChannelClient and RedClient
|
| |
|
|
|
|
|
|
| |
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.
|
| | |
|
| | |
|
| |
|
|
|
| |
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
|
| |
|
|
| |
for migraion data
|
| |
|
|
|
|
|
| |
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
|
| |
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
| |
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).
|
| |
|
|
|
| |
It will abort by default for critical level messages. That behaviour
can be tuned at runtime.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
| |
|
|
|
|
|
|
|
|
|
|
| |
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>
|
| | |
|
| |
|
|
|
|
| |
We want as little latency as possible with usb channels.
Signed-off-by: Hans de goede <hdegoede@redhat.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
| |
|
|
|
|
|
| |
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.
|
|
|
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>
|
