| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
| |
When the server is a migration target and spice_server_migrate_connect
is called before SPICE_MSGC_MIGRATE_END has been received, we start
the mig_timer. We handle the migrate_connect only when receiving SPICE_MSGC_MIGRATE_END.
If the mig_timer expires before that, we dismiss the request, and should call the
migrate_connect completion callback. Since reds->mig_inprogress
wasn't set appropriately, it wasn't called.
|
|
|
|
| |
target fails
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
(1) not sending anything to the client till we recieve SPICE_MSGC_MIGRATE_END
(2) start a new migration (handle client_migrate_info) only after SPICE_MSGC_MIGRATE_END
from the previous migration has been received
(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 client.
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
migraton starts
(1) send SPICE_MSG_MAIN_MIGRATE_BEGIN upon spice_server_migrate_connect
(2) wait for SPICE_MSGC_MAIN_MIGRATE_(CONNECTED|CONNECT_ERROR), or a timeout, in order
to complete client_migrate_info monitor command
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
| |
In C, the latter isn't a prototype for a function with no arg,
but declares a function with an undefined number of args.
[picked from master with changes since no main_channel, spice_common,
and a bunch of functions aren't there yet]
|
|
|
|
|
|
|
| |
The C specification reserves use of identifiers starting with __
to the compiler so we shouldn't use one such symbol.
[cherry-pick from master]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When qemu creates a channel, reds.c contains code to check the
minor/major channel versions known to QEMU (ie the ones that were
current in spice-server when QEMU was compiled) and to compare these
versions against the current ones the currently installed spice-server
version.
According to kraxel [1], the rules for these interface numbers are:
"The purpose of the versions is exactly to avoid the need for a new
soname. The rules are basically:
(1) You add stuff to the interface, strictly append-only to not break
binary compatibility.
(2) You bump the minor version of the interface.
(3) You check the minor version at runtime to figure whenever the
added fields contain valid stuff or not.
An example is here (core interface, minor goes from 2 to 3, new
channel_event callback):
http://cgit.freedesktop.org/spice/spice/commit/?id=97f33fa86aa6edd25111b173dc0d9599ac29f879
"
The code currently refuses to create a channel if QEMU minor version is
less than the current spice-server version. This does not correspond
to the intended behaviour, this patch changes to fail is qemu was compiled
with a spice-server that is *newer* than the one currently installed. This
case is something we cannot support nicely.
[1] http://lists.freedesktop.org/archives/spice-devel/2011-July/004440.html
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We introduce 2 public functions to integrate with the library user.
spice_server_set_sasl() - turn on SASL
spice_server_set_sasl_appname() - specify the name of the app (It is
used for where to find the default configuration file)
The patch for QEMU is on its way.
https://bugs.freedesktop.org/show_bug.cgi?id=34795
Conflicts:
server/reds.c
server/reds.h
|
|
|
|
| |
https://bugs.freedesktop.org/show_bug.cgi?id=34795
|
|
|
|
|
|
|
|
|
|
| |
Try to have a common base dispose() method for channels. For now, it
just free the caps.
Make use of it in snd_worker, and in sync_write() - sync_write() is
going to have default caps later on.
https://bugs.freedesktop.org/show_bug.cgi?id=34795
|
|
|
|
|
|
| |
+ symplify, improving style of code using it.
https://bugs.freedesktop.org/show_bug.cgi?id=34795
|
|
|
|
|
|
| |
+ a couple of indent, style change
https://bugs.freedesktop.org/show_bug.cgi?id=34795
|
|
|
|
|
|
| |
We are going to reuse it for SASL/SSF encode write().
https://bugs.freedesktop.org/show_bug.cgi?id=34795
|
|
|
|
|
|
|
|
| |
This is stylish change again. We are talking about a RedStream object,
so let's just name the variable "stream" everywhere, to avoid
confusion with a non existent RedPeer object.
https://bugs.freedesktop.org/show_bug.cgi?id=34795
|
|
|
|
| |
https://bugs.freedesktop.org/show_bug.cgi?id=34795
|
|
|
|
| |
https://bugs.freedesktop.org/show_bug.cgi?id=34795
|
|
|
|
| |
https://bugs.freedesktop.org/show_bug.cgi?id=34795
|
|
|
|
|
|
| |
Be carefull removing the watch before, like __release_link
https://bugs.freedesktop.org/show_bug.cgi?id=34795
|
|
|
|
| |
https://bugs.freedesktop.org/show_bug.cgi?id=34795
|
|
|
|
| |
https://bugs.freedesktop.org/show_bug.cgi?id=34795
|
|
|
|
| |
https://bugs.freedesktop.org/show_bug.cgi?id=34795
|
|
|
|
|
|
| |
Let's not bother with it since nobody uses it, and it's not implemented for SSL anyway
https://bugs.freedesktop.org/show_bug.cgi?id=34795
|
|
|
|
|
|
|
|
| |
The check this patch removes causes us to not set vdagent to NULL, nor
update the mouse mode when the guest agent disconnects when no client is
attached. Which leads to a non working mouse, and on agent reconnect a
"spice_server_char_device_add_interface: vdagent already attached" message
instead of a successful re-add of the agent interface .
|
|
|
|
|
| |
This can happen for example when a SPICE_MSGC_MAIN_AGENT_START message
from the client and the vdagent disconnecting race.
|
|
|
|
|
|
|
| |
This ensures that if the client or agent connects to the client-agent
"tunnel" while the other side is halfway through sending a multi part
message, the rest of the message gets discarded, and the connecting
party starts getting data at the beginning of the next message.
|
| |
|
|
|
|
|
| |
Filter all data from client, even when there is no agent connected
to keep filter state correct.
|
|
|
|
|
|
| |
The agent message filter keeps track of messages as they are being send
reset the relevant filter to its initial state when one of the 2 ends
of the agent<->client "tunnel" disconnects.
|
|
|
|
|
|
|
| |
read_from_vdi_port calls dispatch_vdi_port data, which will disconnect
the guest agent if it sends invalid data. It would then try to read more
data from the disconnected guest agent resulting in a NULL ptr dereference,
this patch fixes this.
|
|
|
|
|
|
|
|
| |
write_to_vdi_port() was checking for reds->agent_state.connected to determine
wether it could write queued data. But agent_state.connected reflects if
*both* ends are connected. If the client has disconnected, but the guest agent
is still connected and some data is still pending (like a final clipboard
release from the client), then this data should be written to the guest agent.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We were calling reds_reset_vdp on client disconnect, which is not a good
idea. reds_reset_vdp does 3 things:
1) It resets the state related to reading chunks from the spicevmc virtio
port. If the client disconnects while the guest agent is in the middle
of sending a chunk, this will lead to an inconsistent state, and lots
of printing of "dispatch_vdi_port_data: invalid port" messages caused
by this inconsistent state sometimes followed by a segfault.
This can be triggered by copy and pasting something large (say
a screenshot) from the guest to the spice-gtk client, as the spice-gtk
client currently has a bug causing it to crash when receiving a multi
chunk vdagent messages. Without this patch (and with the spice-gtk bug
present) I can consistently reproduce this.
2) It clears any buffered writes from the client to the guest still pending
because the virtio port cannot consume data fast enough. Since the agent
itself is still running fine, throwing away writes for it because the
client has disconnected makes no sense. Esp, since on clean exit the
client may very well send a clipboard release message directly
before closing the connection, and this may get lost this way.
3) It sets client_agent_started to false, this is the only thing which
actually makes sense to do on client disconnect.
Note that since we no longer reset the vdp state on client disconnect, we
must now reset it on agent disconnect even if we don't have a client. So
the reds_reset_vdp call in reds_agent_remove() gets moved to the top,
above both the agent_state.connected and reds->peer checks which will
both fail in the no client case.
|
|
|
|
|
|
| |
Also bump SPICE_SERVER_VERSION to 0x000801 as 0.8.1 will be the
first version with the new API for this, and we need to be able to
detect the presence of this API in qemu.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The current assert(reds->agent_state.connected) tiggers if when
the agent disconnected there was still data waiting to be sent (for
instance if there is a bug in the client handling clipboard and it
is killed while a large clipboard transfer is in progress). So first
call to reds_agent_remove happens from spice_server_char_device_remove_interface,
and then it is called again (triggering the assert) from free_item_data
from read_from_vdi_port because of the channel destruction.
Other option would be to not call it from one of the paths - but that
is suboptimal:
* if there is no data in the pipe, the second call never happens.
* the second call has to be there anyway, because it may fail during
parsing data from the agent.
This patch fixes a segfault on this assert when a client starts passing
from guest agent to client a large clipboard and dies in the middle. There
is still another assert happening occasionally at marshaller which I don't
have a fix for (but it doesn't seem to be related).
|
|
|
|
|
|
|
| |
spice-server tries to use the migration information without checking
whenever this is available in the first place ...
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
|
|
|
|
|
| |
gcc 4.6.0 added "[-Werror=unused-but-set-variable]", this and the next
few fixes tend to that. Mostly harmless.
|
|
|
|
|
| |
disable some code that only makes sense when USE_TUNNEL is defined
in client and server channel security level setting.
|
|
|
|
|
| |
The name to channel id mapping for the smartcard channel is missing,
add it in client and server.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Implement server-side support for switch-host client migration. Client
side support is present already in the tree.
Setting the migration information is done using the existing
spice_server_migrate_info() function. A new
spice_server_migrate_switch() function has been added which triggers
sending out the switch-host message.
Seamless migration functions are left there for now.
spice_server_migrate_start() has been chamnged to just fail
unconditionally though as seamless migration is broken anyway.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
(cherry picked from commit 4b1ea4e102bb8a737487dab51dd0f3fc94352948)
|
|
|
|
|
|
|
|
|
| |
We should pass up errors instead of aborting. Do that at least
for bind() failures which actually happen in real live due to the
tcp port being busy.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
(cherry picked from commit aafd8eea74acb23fc818b49824a74c4d885c3504)
|
| |
|