Rules for replacing spice_printerr:
* if it's a client drop / agent drop, spice_error
* if it's important, spice_warning
* else, spice_info.
The fourth rule is spice_debug if it's going to fill up the log, but
nothing of the sort here.
Other things this patch does:
* changed reds_show_new_channel to reds_info_new_channel in an attempt to
advertise it doesn't always show anything, unless SPICE_DEBUG_LOG_LEVEL
>= SPICE_DEVUG_LOG_INFO (==3)
* removes two lines of whitespace.
* added "crashy" to multiple client warning (only warning introduced,
the rest are errors).
This patch and the following one do not introduce tokening to the smartcard
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).
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).
This code is never called, it was relevant for seamless migration.
Most of the data that needs to be migrated was moved to
SpiceCharDeviceState. When we implement seamless migration,
we will have routines in char_device.c for migrating the relevant data.
- Allow sending tokens to a specific client.
- Do not ignore tokens that are sent from the client to the server.
The tokens support for multiple clients and for server side tokens
is still broken in reds. It will be fixed in following patches, when
the server-side agent code will use the SpiceCharDeviceState api.
Notice that ignoring the server-side tokens didn't introduce a problem
since both the client and the server set it to ~0.
If a 'goto' statement jumps across a variable declaration
which also has an initializer, the variable is in an undefined
state. Splitting the the declaration & initialization doesn't
change that, but the compiler can at least now detect use of
the unintialized variable
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
* server/red_worker.c: Add missing const for return type
* server/reds.c: Static strings must be declared const
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
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
Add spice_server_set_name() and spice_server_set_uuid() that allows
the client to identify a Spice server (useful to associate settings
with a particular server)
The SPICE_MSG_MAIN_NAME and SPICE_MSG_MAIN_UUID messages are only sent
to capable clients, announcing SPICE_MAIN_CAP_NAME_AND_UUID.
Currently, when a ticket has already expired, or is invalid, there is
no qemu log to tell what went wrong. This commit adds such a log.
Fixes rhbz#787669
Solaris has a pitiful maximum writev vector size of only 16, so the ping
request at initial startup destroyed this call and broke things
immediately. Reimplement stream_writev_cb() to respect IOV_MAX and break
the writev() calls into chunks as necessary. Care was taken to return
the correct values as necessary so the EAGAIN handling logic can
determine where to resume the writev call the next time around.
Signed-off-by: Dan McGee <dpmcgee@gmail.com>
This removes the epoll dependency we had in red_worker, which was the
last Linux-specific call we were using in the entire Spice server. Given
we never have more than 10 file descriptors involved, there is little
performance gain had here by using epoll() over poll().
The biggest change is introduction of a new pre_disconnect callback;
this is because poll, unlike epoll, cannot automatically remove file
descriptors as they are closed from the pollfd set. This cannot be done
in the existing on_disconnect callback; that is too late as the stream
has already been closed and the file descriptor lost. The on_disconnect
callback can not be moved before the close and other operations easily
because of some behavior that relies on client_num being set to a
certain value.
Signed-off-by: Dan McGee <dpmcgee@gmail.com>
fixes rhbz 790749 use after free of SpiceChannelEventInfo.
The lifetime of the SpiceChannelEventInfo was that of RedsStream, but it
is used by main_dispatcher_handle_channel_event after the RedsStream is
freed for the cursor and display channels. Making SCEI allocation be at
RedsStream allocation, and deallocation after the DESTROY event is
processed by core->channel_event, fixes use after free.
Some non-Linux platforms return a (caddr_t *) result for the return
value of mmap(), which is very unfortunate. Add a (void *) cast to
explicitly avoid the warning when compiling with -Werror.
For the IO vector related stuff, signed vs. unsigned comes into play so
adding a (void *) cast here is technically correct for all platforms.
Signed-off-by: Dan McGee <dpmcgee@gmail.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 492ddb5d1d
which already added the same check to server/inputs_channel.c
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
When an applications passes in a pre-accepted socket for a
client, they may well have already performed suitable authentication
out of band. They should thus have the option to request that any
spice authentication is skipped.
* server/reds.c, spice.h: Add flag for skipping auth
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Allow applications to pass a pre-accepted client socket file
descriptor in. The new APIs are spice_server_add_ssl_client
and spice_server_add_client
* server/reds.c: Implement new APIs
* server/spice.h: Define new APIs
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
To allow setup of an SSL client, from a passed in client
socket, move all the SSL client initialization code out
of reds_accept_ssl_connection and into a new method called
reds_init_client_ssl_connection
* server/reds.c: Introduce reds_init_client_ssl_connection
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Remove the accept() call from __reds_accept_connection and
rename it to reds_init_client_connection. The caller is now
responsible for accepting the new socket. The method
reds_init_client_connection merely initializes it for
usage.
* server/reds.c: Add reds_init_client_connection
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Neither reds_accept_connection or reds_accept are very long,
so the split is pointless & increases code size for no gain.
Merge them together to reduce code size
* server/reds.c: Merge reds_accept_connection into reds_accept
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
We will add a qemu call to spice_server_migrate_start when migration starts.
For now, it does nothing, but we may need this notification in the future.
(cherry picked from commit b821316771 branch 0.8)
(1) not sending anything to a migrated client till we recieve SPICE_MSGC_MIGRATE_END
(2) start a new client migration (handle client_migrate_info) only after SPICE_MSGC_MIGRATE_END
from the previous migration was received for this client
(3) use the correct ticket
Note: we assume the same channles are linked before and ater migration. i.e.,
SPICE_MSGC_MAIN_ATTACH_CHANNELS is not sent from the clients.
If the migration has completed successfully:
(1) send MSG_MAIN_MIGRATE_END to the clients that are connected to the target
(2) send MSG_MAIN_SWITCH_HOST to all the other clients
If the migration failed, send MSG_MAIN_MIGRATE_CANCEL to clients that are
connected to the target.
(cherry picked from commit 4b82580fc3 branch 0.8;
Was modified to support multiple clients, and the separation of main_channel from reds)
Conflicts:
server/reds.c
(1) send SPICE_MSG_MAIN_MIGRATE_BEGIN upon spice_server_migrate_connect
(to all the clients that support it)
(2) wait for SPICE_MSGC_MAIN_MIGRATE_(CONNECTED|CONNECT_ERROR) from all the relevant clients,
or a timeout, in order to complete client_migrate_info monitor command
(cherry picked from commit 5560c56ef0 branch 0.8;
Was modified to support the separation of main channel from reds, and multiple clients)
Conflicts:
server/reds.c
semi-seamless migration details:
migration source side
---------------------
(1) spice_server_migrate_connect (*): tell client to link
to the target side - send SPICE_MSG_MAIN_MIGRATE_BEGIN.
This should be called upon client_migrate_info cmd.
client_migrate_info is asynchronous.
(2) Complete spice_server_migrate_connect only when the client has been connected
to the target - wait for SPICE_MSGC_MAIN_MIGRATE_(CONNECTED|CONNECT_ERROR) or a timeout.
(3) spice_server_migrate_end: tell client migration it can switch to the target - send
SPICE_MSG_MAIN_MIGRATE_END.
(4) client cleans up all data related to the connection to the source and switches to the target.
It sends SPICE_MSGC_MAIN_MIGRATE_END.
migration target side
---------------------
(1) the server identifies itself as a migraiton target since the client is linked with (connection_id != 0)
(2) server doesn't start the channels' logic (channel->link) till it receives SPICE_MSGC_MAIN_MIGRATE_END
from the client.
* After migration starts, the target qemu is blocked and cannot accept new spice client
connections. Thus, we trigger the connection to the target upon client_migrate_info
command.
(cherry picked from commit 6e56bea67c branch 0.8)
Conflicts:
server/spice.h
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.
add main_dispatcher, a message passing mechanism for sending messages to
the main thread. The main thread is the thread that implements
SpiceCoreInterface, which is assumed to be a single thread.
Similar to the async operation of red_worker, a socket pair is created
and used to pass messages. The messages are a fixed size to ease
parsing. A single message is defined to pass a channel_event.
RHBZ: 746950
FDBZ: 41858
This patch is 0.8 branch only, for the master branch there should be a
better approach to share code with red_dispatcher and ready the way for
later adding more threads.
cherry-pick from 0.8 80caf07e09
Conflicts:
server/reds.c
Several functions in server/ were not specifying an argument list,
ie they were declared as void foo(); When compiling with
-Wstrict-prototypes, this leads to:
test_playback.c:93:5: erreur: function declaration isn’t a prototype
[-Werror=strict-prototypes]
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>
