summaryrefslogtreecommitdiffstats
path: root/server/red_channel.c
Commit message (Collapse)AuthorAgeFilesLines
* red channel: Remove unused red_channel_apply_clients_dataPavel Grunt2015-11-231-12/+0
| | | | | | | | It was introduced in 7e8e13593ee681cf04c349bca57dd225d7802494 but never used. Signed-off-by: Pavel Grunt <pgrunt@redhat.com> Acked-by: Fabiano Fidêncio <fidencio@redhat.com>
* red channel: Remove unused red_channel_push_set_ackPavel Grunt2015-11-231-5/+0
| | | | | | | It is not needed since 8e7b22b7861d2859167767822f29749bfe3ecc16 Signed-off-by: Pavel Grunt <pgrunt@redhat.com> Acked-by: Fabiano Fidêncio <fidencio@redhat.com>
* reuse red_get_monotonic_time functionFrediano Ziglio2015-11-231-10/+3
| | | | | Signed-off-by: Frediano Ziglio <fziglio@redhat.com> Acked-by: Pavel Grunt <pgrunt@redhat.com>
* server: make cursor channel privateMarc-André Lureau2015-11-031-0/+12
| | | | Acked-by: Fabiano Fidêncio <fidencio@redhat.com>
* Replace now() with get_mononotonic_time()Marc-André Lureau2015-10-291-8/+8
| | | | Acked-by: Frediano Ziglio <fziglio@redhat.com>
* fix spelling mistakes in comments (reseting to resetting & dummym to dummy)snir sheriber2015-10-191-2/+2
| | | | Acked-by: Frediano Ziglio <fziglio@redhat.com>
* server: small move to red_channelMarc-André Lureau2015-10-151-0/+9
| | | | | Acked-by: Frediano Ziglio <fziglio@redhat.com> Acked-by: Jonathon Jongsma <jjongsma@redhat.com>
* Use MAX macro to compute the maximum valueFrediano Ziglio2015-08-251-1/+1
| | | | Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
* channel: minor simplificationMarc-André Lureau2015-08-111-6/+1
|
* server: use more const CoreInterfaceMarc-André Lureau2015-08-111-2/+2
|
* Fix typo in commentFrediano Ziglio2015-06-111-1/+1
| | | | Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
* Use MIN macro to compute a minimumFrediano Ziglio2015-06-111-1/+1
| | | | Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
* ppc: Fixing endianness for channel messagesChristophe Fergeau2015-04-101-10/+10
| | | | | This is a modified version of a patch initially from Erlon R. Cruz <erlon.cruz@br.flextronics.com>
* ppc: Fix endianness handling in initial SPICE connectionChristophe Fergeau2015-04-101-0/+1
| | | | | | | | | | | | This commit fixes enough endianness issues that it's possible to connect to a spice-server/qemu running on a big-endian box with a client running on a little-endian machine. I haven't tested more than getting to the bios/bootloader and typing a bit on the keyboard as I did not manage to boot a distro afterwards :( This is based on patches send by Erlon R. Cruz <erlon.cruz@br.flextronics.com>
* Do not perform network tests on UNIX socketMarc-André Lureau2015-01-151-1/+1
| | | | | By default, stream latency is 0 and bandwidth is infinite. On UNIX socket do not perform unnecessary testing and keep those values.
* Add const to test_capability first argumentChristophe Fergeau2014-11-241-1/+1
| | | | We don't modify the capabilities content, so it can be marked as const.
* server: use a warning when disconnecting unresponsive clientMarc-André Lureau2014-05-161-2/+2
| | | | | The debug level is not visible by default, since it is an unsolicited server behaviour, make it a warning.
* Fix test_capability() typoChristophe Fergeau2014-03-131-7/+7
| | | | It was spelt 'capabilty'
* Add reds_stream.[ch]Christophe Fergeau2014-01-201-0/+1
| | | | | Gather common RedsStream code there rather than having it in reds.c
* Silence gcc false positive with -WuninitializedChristophe Fergeau2013-10-281-0/+6
| | | | | | | | | | | | | | | | | Some versions of gcc warn about: red_channel.c: In function 'red_channel_client_wait_outgoing_item': red_channel.c:2331: error: 'end_time' may be used uninitialized in this function [-Wuninitialized] red_channel.c: In function 'red_channel_client_wait_pipe_item_sent': red_channel.c:2363: error: 'end_time' may be used uninitialized in this function [-Wuninitialized] red_channel.c: In function 'red_channel_wait_all_sent': red_channel.c:2401: error: 'end_time' may be used uninitialized in this function [-Wuninitialized] This is a false positive as end_time is unitialized when timeout is -1, and we will only try to use end_time if timeout is not -1. This commit initializes end_time to UINT64_MAX to avoid that warning. As the test involving end_time will never be reached, we ensure it's always TRUE so that it would be a noop even if it was reached.
* red_channel: cleanup of red_channel_client blocking methodsYonit Halperin2013-09-261-37/+36
| | | | | | (1) receive timeout as a parameter. (2) add a return value and pass the handling of failures to the calling routine.
* red_channel: add option to monitor whether a channel client is aliveYonit Halperin2013-08-141-0/+119
| | | | | | | | | | rhbz#994175 When a client connection is closed surprisingly (i.e., without a FIN segment), we cannot identify it by a socket error (which is the only way by which we identified disconnections so far). This patch allows a channel client to periodically check the state of the connection and identify surprise disconnections.
* red_channel: add on_input callback for tracing incoming bytesYonit Halperin2013-08-141-0/+7
| | | | The callback will be used in the next patch.
* server: s/red_wait_all_sent/red_channel_wait_all_sent/Alon Levy2013-08-141-1/+1
|
* server: move three functions to red_channelAlon Levy2013-08-141-0/+106
| | | | | | | | | | | | | | | Three blocking functions, one was split to leave the display channel specific referencing of the DrawablePipeItem being sent inside red_worker, but the rest (most) of the timeout logic was moved to red_channel, including the associated constants. Moved functions: red_channel_client_wait_pipe_item_sent red_wait_outgoing_item red_wait_all_sent Introduces red_time.h & red_time.c for a small helper function dealing with time.h
* log: improve debug information related to client disconnectionYonit Halperin2013-07-291-3/+6
|
* red_channel: add ref count to RedClientYonit Halperin2013-07-291-3/+20
|
* red_channel: prevent adding and pushing pipe items after a channel_client ↵Yonit Halperin2013-07-291-6/+24
| | | | | | | | | | | | | | | | | | | | | | | | has diconnected Fixes: leaks of pipe items & "red_client_destroy: assertion `rcc->send_data.size == 0'" red_channel_disconnect clears the pipe. It is called only once. After, it was called, not items should be added to the pipe. An example of when this assert can occur: on_new_cursor_channel (red_worker.c), pushes 2 pipe items. When it pushes the first pipe item, if the client has disconnected, it can hit a socket error, and then, red_channel_client_disconnect is called. The second call to adding a pipe item, will add the item to the pipe. red_channel_client_pipe_add_type also calls red_channel_client_push, which will update the send_data.size. Then, the push will also hit a socket error, but red_channel_client_disconnect won't clear the pending pipe item again, since it was already called. When red_client_destory is called, we hit assertion `rcc->send_data.size == 0'. Note that if a pipe item is added to the pipe after red_channel_client_disconnect was called, but without pushing it, we should hit "spice_assert(rcc->pipe_size == 0)".
* server/red_channel: fix unused variableAlon Levy2013-07-281-10/+13
| | | | unused variable 'so_unsent_size' [-Werror=unused-variable]
* TIOCOUTQ -> SIOCOUTQ and portability ifdefsNahum Shalman2013-07-221-2/+11
| | | | | | | | The ioctl on sockets is actually named SIOCOUTQ though its value is identical to TIOCOUTQ which is for terminals. SIOCOUTQ is linux specific so we add a header check and ifdef based on the presence of the header This prevents bogus ioctls on non-Linux platforms
* red_channel: replace RING_FOREACH with RING_FOREACH_SAFE in some placesUri Lublin2013-07-161-4/+4
| | | | | | | | This was originally intended to fix the problem fixed by commit 53488f0275d6c8a121af49f7ac817d09ce68090d. What is left are FOREACH loops that are at less risk and maybe safe (no read/write or disconnect/destroy are called from within them).
* Use RING_FOREACH_SAFE in red_channel.c functions which are missing itDavid Gibson2013-07-051-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently, both red_channel_pipes_add_type() and red_channel_pipes_add_empty_msg() use plaing RING_FOREACH() which is not safe versus removals from the ring within the loop body. Although it's rare, such a removal can occur in both cases. In the case of red_channel_pipes_add_type() we have: red_channel_pipes_add_type() -> red_channel_client_pipe_add_type() -> red_channel_client_push() And in the case of red_channel_client_pipes_add_empty_msg() we have: red_channel_client_pipes_add_empty_msg() -> red_channel_client_pipe_add_empty_msg() -> red_channel_client_push() But red_channel_client_push() can cause a removal from the clients ring if a network error occurs: red_channel_client_push() -> red_channel_client_send() -> red_peer_handle_outgoing() -> handler->cb->on_error callback = red_channel_client_default_peer_on_error() -> red_channel_client_disconnect() -> red_channel_remove_client() -> ring_remove() When this error path does occur, the assertion in RING_FOREACH()'s ring_next() trips, and the process containing the spice server is aborted. i.e. your whole VM dies, as a result of an unfortunately timed network error on the spice channel. Please apply. Signed-off-by: David Gibson <dgibson@redhat.com>
* spice: silencing most of the ping/pong loggingYonit Halperin2013-06-241-11/+2
| | | | Those messages are too frequent and don't contribute much
* red_channel: replace an assert upon threads mismatch with a warningYonit Halperin2013-05-241-3/+25
| | | | | | | | | | | | | | | | | | | | | | | The assert: spice_assert(pthread_equal(pthread_self(), client->thread_id)) and the assert: spice_assert(pthread_equal(pthread_self(), rcc->channel->thread_id)) were coded in order to protect data that is accessed from the main context (red_client and most of the channels), from access by threads of other channels (namely, the display and cursor channels), and vice versa. However, some of the calls to the sound channel interface, and also the char_device interface, can be done from the vcpu thread. It doesn't endanger these channels internal data, since qemu use global mutex for the vcpu and io threads. Thus, pthread_self() can be != channel->thread_id, if one of them is the vcpu thread and the other is the io-thread, and we shouldn't assert. Future plans: A more complete and complicated solution would be to manage our own thread for spice-channels, and push input from qemu to this thread, instead of counting on the global mutex of qemu rhbz#823472
* red_channel: notify and shutdown a channel client when its ↵Yonit Halperin2013-05-081-2/+5
| | | | handle_migrate_data fails
* red_channel: on migration target, start sending ping messages only after the ↵Yonit Halperin2013-05-011-1/+15
| | | | | | | | | | client's migration has completed The connection to the target server is established before migration starts. However, the client reads and replies to messages from the server only after migration completes. Thus, we better not send ping msgs from the target before migration completes (because the observed roundtrip duration will be bigger than the real one).
* red_channel: stop sending ping messages after migration has completedYonit Halperin2013-05-011-0/+5
| | | | | We mustn't send any msg to the client, besides MSG_MIGRATE_DATA, after we send MSG_MIGRATE.
* red_channel: fix not handling self pipe items in red_channel_client_release_itemYonit Halperin2013-04-301-0/+3
| | | | | | | When a client disconnects, red_channel_client_pipe_clear is called. Releasing pipe items of type == MIGRATE||EMPTY_MSG||PING wasn't handled, and was passed to channel_cbs.release_item. There, an error occured since the pipe items were not recognized.
* red_channel: monitor connection latency using MSG_PINGYonit Halperin2013-04-221-0/+228
|
* server: freezed->froze, missing whitespace after declarationsAlon Levy2012-08-301-0/+1
|
* red_channel: set send_data.last_sent_serial in ↵Yonit Halperin2012-08-271-0/+1
| | | | | | | | red_channel_client_set_message_serial red_channel_client_set_message_serial is called for setting the serial of the display channel messages after migration (on the destination side). The serial is retrieved from the migration data.
* red_channel: remove unused migrate flag from RedChannelYonit Halperin2012-08-271-4/+3
| | | | The relevant flags reside in RedChannelClient and RedClient
* red_channel (dummy): fix not adding dummy RedChannelClient to the clientYonit Halperin2012-08-271-11/+23
| | | | | | | | | | | snd channel wasn't added to be part of the client's channels list. As a result, when the client was destroyed, or migrated, snd channel client wasn't destroy, or its migration callback wasn't called. However, due to adding dummy channels to the client, we need special handling for calls to disconnecting dummy channel clients. TODO: we need to refactor snd_worker to use red_channel
* main: send MSG_MIGRATE upon vm migration completionYonit Halperin2012-08-271-1/+1
| | | | | | | | | Before sending the above msg, if there is a pending partial msg that has been read from the agent, we send it to the client. The alternative was to keep the msg as part of the migration data, and then to send it to the destination server via the client and to wait there for the msg chunk completion, before sending it to the client. Of course, the latter is less efficient.
* red_channel: introduce PIPE_ITEM_TYPE_EMPTY_MSGYonit Halperin2012-08-271-0/+39
| | | | The pipe item is used for sending messages that don't have body.
* seamless migration: migration completion on the destination sideYonit Halperin2012-08-271-9/+98
| | | | | | Tracking the channels that wait for migration data. If there is a new migration process pending, when all the channels have restored their state, we begin the new migration.
* red_channel: handle sending SPICE_MSG_MIGRATEYonit Halperin2012-08-271-4/+34
| | | | | | | 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
* red_channel: fix pipe item leakYonit Halperin2012-08-271-0/+1
|
* red_channel: add red_channel_test_remote_capYonit Halperin2012-08-271-0/+28
| | | | for checking if all the channel clients connected support the cap
* server/red_channel: s/channle/channelAlon Levy2012-06-071-3/+3
|