summaryrefslogtreecommitdiffstats
path: root/server
Commit message (Collapse)AuthorAgeFilesLines
...
* red_worker: stream agent - fix miscounting of framesYonit Halperin2013-04-221-4/+12
| | | | | Frames counting was skipped when the previous frame was already sent completely to the client.
* snd_worker: Make sure we never send an empty volume messageHans de Goede2013-04-191-3/+7
| | | | | | | | | | | | My commit 71315b2e "snd_worker: Don't send empty audio-volume messages", fixes only one case of sending an empty volume message, if the client connects to a vm early during its boot sequence, while the snd hardware is being reset by the guest driver, qemu will call spice_server_playback_set_volume() with 0 channels from the reset handler. This patch also applies both fixes to the record channel. Signed-off-by: Hans de Goede <hdegoede@redhat.com>
* red_worker.c: fix not destroying streams before sending MSG_MIGRATEYonit Halperin2013-04-081-1/+24
| | | | | | | | | | | | | | | | When qemu migration completes, we need to stop the streams, and to send the corresponding upgrade_items to the client. Otherwise, (1) the client might display lossy regions that we don't track (streams are not part of the migration data). (2) streams_timeout may occur after MSG_MIGRATE has been sent, leading to messages being sent to the client after MSG_MIGRATE and before MSG_MIGRATE_DATA (e.g., STREAM_CLIP, STREAM_DESTROY, DRAW_COPY). No message besides MSG_MIGRATE_DATA should be sent after MSG_MIGRATE. When a msg other than MIGRATE_DATA reached spice-gtk after MSG_MIGRATE, spice-gtk sent it to dest server as the migration data, and the dest server crashed with a "bad message size" assert.
* red_worker.c: s/red_display_destroy_streams/red_display_destroy_streams_agentsYonit Halperin2013-04-081-2/+2
| | | | | In order not to confuse it with red_destroy_streams in the following patch.
* snd_worker: Don't send empty audio-volume messagesHans de Goede2013-04-011-1/+4
| | | | | | | | | | | If no volume has been set it, we end up sending a volume message with audio-volume for 0 channels (iow an empty message). This is not useful and triggers the following warning in spice-gtk: (remote-viewer:8726): GSpice-WARNING **: set_sink_input_volume() failed: Invalid argument Signed-off-by: Hans de Goede <hdegoede@redhat.com>
* char_device: Don't set active when stopped and don't access dev after unrefHans de Goede2013-03-291-2/+4
| | | | | | | | | | 2 closely related changes in one: 1) When leaving the read or write loop because the chardev has been stopped active should not be updated. It has been set to FALSE by spice_char_device_stop and should stay FALSE 2) The updating of dev->active should be done *before* unref-ing dev Signed-off-by: Hans de Goede <hdegoede@redhat.com>
* char_device: Don't set the write-retry timer when not runningHans de Goede2013-03-291-4/+7
| | | | | | | The write-retry timer should not be set when we're leaving spice_char_device_write_to_device because the char-dev has been stopped. Signed-off-by: Hans de Goede <hdegoede@redhat.com>
* char_device: Properly update buffer status when leaving the write loop on stopHans de Goede2013-03-291-4/+1
| | | | | | | | Before this patch the write-loop in spice_char_device_write_to_device would break on running becoming 0, after having written some data, without updating the buffer status, causing the same data to be written *again* when started. Signed-off-by: Hans de Goede <hdegoede@redhat.com>
* inputs-channel: Don't send insecure keyb notify to in migrate clientHans de Goede2013-03-151-1/+1
| | | | | | | This fixes spice-gtk printing message like these on migration: (remote-viewer:18402): GSpice-CRITICAL **: spice_channel_iterate_read: assertion `c->state != SPICE_CHANNEL_STATE_MIGRATING' failed Signed-off-by: Hans de Goede <hdegoede@redhat.com>
* inputs-channel: Handle printing of insecure keyboard notifyHans de Goede2013-03-152-5/+6
| | | | | | | | | This is clearly something which should be handled in the inputs_channel code, rather then having a special case for it in the generic channel handling code in reds.c. Moving it here also fixes the TODO we had on only sending this message to new clients. Signed-off-by: Hans de Goede <hdegoede@redhat.com>
* main-channel: Add a main_channel_client_push_notify functionHans de Goede2013-03-152-1/+7
| | | | | | | Sometimes we want to send a notify to a single client, rather then to all of them. Signed-off-by: Hans de Goede <hdegoede@redhat.com>
* main-channel: Make main_channel_push_notify deal with dynamic memoryHans de Goede2013-03-153-22/+14
| | | | | | | | | | | Currently main_channel_push_notify only gets passed a static string, but chances are in the future it may get passed dynamically allocated strings, prepare it for this. While at it also make clear that its argument is a string, and simplify things a bit by making use of this knowledge (pushing the strlen call down). Signed-off-by: Hans de Goede <hdegoede@redhat.com>
* server/reds: Send the agent a CLIENT_DISCONNECTED msg on client disconnectHans de Goede2013-03-071-1/+23
| | | | | | | | | | | | | | | | | | | | | | | | | | Client -> agent messages can spawn multiple VDIChunks. When this happens the agent re-assembles the chunks into a complete VDAgentMessage before processing it. The server only guarentees coherency at the chunk level, so it is not possible for a partial chunk to get delivered to the agent. But it is possible for some chunks of a VDAgentMessage to be delivered to the agent followed by a client to disconnect without the rest of the VDAgentMessage being delivered! This will leave the agent in a wrong state, and the first messages send to it by the next client to connect will get seen as the rest of the VDAgentMessage from the previous client. This patch sends the agent a new VD_AGENT_CLIENT_DISCONNECTED message from the VDP_SERVER_PORT, on which the agent can then reset its VDP_CLIENT_PORT state. Note that no capability check is done for this, since the capabilities are something negotiated between client and agent. The server will simply always send this message on client disconnect, relying on older agents discarding the message since it has an unknown type (which both the windows and linux agents already do). Signed-off-by: Hans de Goede <hdegoede@redhat.com>
* char_device: Add spice_char_device_write_buffer_get_server_no_token()Hans de Goede2013-03-072-15/+29
| | | | | | | To allow the server to send agent messages without needing to wait for a self-token. IE for sending VD_AGENT_CLIENT_DISCONNECTED messages. Signed-off-by: Hans de Goede <hdegoede@redhat.com>
* Silence __spice_char_device_write_buffer_get: internal buf is not availableHans de Goede2013-03-041-1/+0
| | | | | | | | | | | | | | | | | These messages are printed when the server tries to push a mouse event to the agent before the previous one has been flushed. This is a normal condition (which gets tracked by the reds->pending_mouse_event boolean), and as such it should *not* trigger the printing of error messages. I've seen these messages occasionally before, but with agent file-xfer they are trivial to trigger, simply send a large file to the agent and while it is transferring move the mouse over the client window. Note that due to the client tokens not allowing the client to completely saturate the agent channel mouse events do still get send to the agent, just with a slightly larger interval. So everything is working as designed and this spice_printerr is just leading to people chasing ghosts. Signed-off-by: Hans de Goede <hdegoede@redhat.com>
* worker_update_monitors_config: Drop bogus real_count accountingHans de Goede2013-01-151-14/+1
| | | | | | | | | | | | | 1) This does not buy us much, as red_marshall_monitors_config() also removes 0x0 sized monitors and does a much better job at it (also removing intermediate ones, not only tailing ones) 2) The code is wrong, as it allocs space for real_count heads, where real_count always <= monitors_config->count and then stores monitors_config->count in worker->monitors_config->count, causing red_marshall_monitors_config to potentially walk worker->monitors_config->heads past its boundaries. Signed-off-by: Hans de Goede <hdegoede@redhat.com>
* server: Fix SpiceWorker-CRITICAL **: ↵Hans de Goede2013-01-151-2/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | red_worker.c:10968:red_push_monitors_config: condition `monitors_config != NULL' failed During my dynamic monitor support testing today, I hit the following assert in red_worker.c: "red_push_monitors_config: condition `monitors_config != NULL' failed" This is caused by the following scenario: 1) Guest causes handle_dev_monitors_config_async() to be called 2) handle_dev_monitors_config_async() calls worker_update_monitors_config() 3) handle_dev_monitors_config_async() pushes worker->monitors_config, this takes a ref on the current monitors_config 4) Guest causes handle_dev_monitors_config_async() to be called *again* 5) handle_dev_monitors_config_async() calls worker_update_monitors_config() 6) worker_update_monitors_config() does a decref on worker->monitors_config, releasing the workers reference, this monitor_config from step 2 is not yet free-ed though as the pipe-item still holds a ref 7) worker_update_monitors_config() creates a new monitors_config with an initial ref-count of 1 and stores that in worker->monitors_config 8) The pipe-item of the *first* monitors_config is send, upon completion a decref is done on the monitors_config, and monitors_config_decref not only frees the monitor_config, but *also* sets worker->monitors_config to NULL, even though worker->monitors_config no longer refers to the monitor_config being freed, it refers to the 2nd monitor_config! 9) The client which was connected when this all happened disconnects 10) A new client connects, leading to the assert: at red_worker.c:9519 num_common_caps=1, common_caps=0x5555569b6f60, migrate=0, stream=<optimized out>, client=<optimized out>, worker=<optimized out>) at red_worker.c:10423 at red_worker.c:11301 Note that red_worker.c:9519 is: red_push_monitors_config(dcc); gdb does not point to the actual line of the assert because the function gets inlined. The fix is easy and obvious, don't set worker->monitors_config to NULL in monitors_config_decref. I'm a bit baffled as to why that code is there in the first place, the whole point of ref-counting is to not have one single unique place to store the reference... This fix should not have any adverse side-effects as the 4 callers of monitors_config_decref fall into 2 categories: 1) Code which immediately after the decref replaces worker->monitors_config with a new monitors_config: worker_update_monitors_config() set_monitors_config_to_primary() 2) pipe-item freeing code, which should not touch the worker state at all to being with Signed-off-by: Hans de Goede <hdegoede@redhat.com>
* link libspice server with libm libpthreadMichael Tokarev2013-01-141-0/+1
| | | | | | | | | | | server/Makefile apparently forgot to link libspice-server with -lm -lpthread, but it uses symbols from these libraries directly. These libs are detected by configure and stored in $(SPICE_NONPKGCONFIG_LIBS) make variable, but this variable is never referenced at link time. Add it to server/Makefile.am, to libspice_server_la_LIBADD variable. Signed-off-By: Michael Tokarev <mjt@tls.msk.ru>
* red_worker.c: clearing the stream vis_region, after it has been detachedYonit Halperin2013-01-081-2/+3
| | | | | | The stream vis_region should be cleared after the stream region was sent to the client losslessly. Otherwise, we might send redundant stream upgrades if we process more drawables that are dependent on the stream region.
* red_worker.c: insert a drawable to its position in the current tree before ↵Yonit Halperin2013-01-081-13/+42
| | | | | | | | | | | | | | | calling red_detach_streams_behind resolves: rhbz#891326 Starting from commit 81fe00b08ad4f, red_detach_streams_behind can trigger modifications in the current tree (by update_area calls). Thus, after calling red_detach_streams_behind it is not safe to access tree entries that were calculated before the call. This patch inserts the drawable to the tree before the call to red_detach_streams_behind. This change also requires making sure that rendering operations that can be triggered by red_detach_streams_behind will not include this drawable (which is now part of the tree).
* server: guest_set_client_capabilities: protect against NULL ↵Uri Lublin2013-01-011-1/+2
| | | | | | | | | | | | | | worker->display_channel Reported-by: Michal Luscon <mluscon@redhat.com> Found by a Coverity scan: in handle_dev_start - Checking "worker->display_channel" implies that "worker->display_channel" might be NULL. Passing "worker" to function "guest_set_client_capabilities" in guest_set_client_capabilities - Directly dereferencing parameter "worker->display_channel"
* Release 0.12.2v0.12.2Hans de Goede2012-12-201-0/+1
|
* red_parse_qxl: fix throwing away drawables that have masksYonit Halperin2012-12-202-19/+16
| | | | | | | Non rgb bitmaps are allowed to not have a palette in case they are masks (which are 1BIT bitmaps). Related: rhbz#864982
* reds: Use g_strlcpy instead of strncpyChristophe Fergeau2012-12-121-15/+17
| | | | | | | | | reds.c is using strncpy with a length one byte less than the destination buffer size, and is relying on the fact that the destination buffers are static global variables. Now that we depend on glib, we can use g_strlcpy instead, which avoids relying on such a subtle trick to get a nul-terminated string.
* build: Use glib2Christophe Fergeau2012-12-121-0/+2
| | | | | Now that QEMU depends on glib, it won't really hurt if we depend on it as well, and we won't have to reinvent our own helpers.
* Fail reds_init_socket when getaddrinfo failsChristophe Fergeau2012-12-121-0/+1
| | | | | | We currently output a warning when getaddrinfo fails, but then we go on trying to use the information it couldn't read. Make sure we bail out of reds_init_socket if getaddrinfo fails.
* Make sure strncpy'ed string are 0-terminatedChristophe Fergeau2012-12-121-2/+2
| | | | | | | | | | spice_server_set_ticket and spice_server_set_addr get (library) user-provided strings as arguments, and copy them to fixed-size buffers using strncpy. However, if these strings are too long, the copied string will not be 0-terminated, which will cause issues later. This commit copies one byte less than the size of the destination buffer. In both cases, this buffer is a static global variable, so its memory will be set to 0.
* red_worker: revert 8855438aYonit Halperin2012-12-051-5/+0
| | | | | | | | | | | | | | | | | | | red_proccess_commands calls were added after calling guest_set_client_capabilities in order to cleanup the command ring from old commands that the client might not be able to handle. However, calling red_process_commands at this stage does send messages to the client. In addition, since setting the client capabilities at the guest is not synchronized, emptying the command ring is not enough in order to make sure the following commands will be supported by the client. The call to red_proccess_commands before initializing the display streams (the call to red_display_start_streams), caused inconsistencies related to video streaming upon reconnecting (rhbz#883564). I'm reverting this patch till another solution for the capabilities mismatch is introduced. Resolves: rhbz#883564
* server: add "port" channel supportMarc-André Lureau2012-12-054-18/+155
| | | | | | | | | | | | | | | | | 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.
* server: bump SPICE_SERVER_VERSION to 0.12.2Marc-André Lureau2012-12-051-1/+1
|
* agent: fix mishandling of agent data received from the client after agent ↵Yonit Halperin2012-11-301-6/+22
| | | | | | | | | | | | | | disconnection The server can receive from the client agent data even when the agent is disconnected. This can happen if the client sends the agent data before it receives the AGENT_DISCONNECTED msg. We should receive and handle such msgs, instead of disconnecting the client. This bug can also lead to a server crash if the agent gets reconnected fast enough, and it receives an agent data msg from the client before MSGC_AGENT_START. upstream bz#55726 rhbz#881980
* red_worker: no need to align the stride of internal imagesYonit Halperin2012-11-291-1/+1
| | | | | Internal images are just read from the surface, compressed, and sent to the client. Then, they are destroyed. I can't find any reason for aligning their memory.
* red_worker: fix sending internal images with stride > bpp*width to lz ↵Yonit Halperin2012-11-281-13/+13
| | | | | | | | | | compression rhbz#876685 The current lz implementation does not support such bitmaps. The following patch will actually prevent allocating stride > bpp*width for internal images.
* red_worker.c: fix memory corruption when data from client is bigger than ↵Yonit Halperin2012-11-261-0/+12
| | | | | | | | | 1024 bytes Previously, there was no check for the size of the message received from the client, and all messages were read into a buffer of size 1024. However, migration data can be bigger than 1024. In such cases, memory corruption occurred.
* red_worker.c: fix not sending all pending messages when the device is stoppedYonit Halperin2012-11-261-21/+25
| | | | | | | | | | | | | | | | | | | | | red_wait_outgoing_item only waits till the currently outgoing msg is completely sent. red_wait_outgoing_items does the same for multi-clients. handle_dev_stop erroneously called red_wait_outgoing_items, instead of waiting till all the items in the pipes are sent. This waiting is necessary because after drawables are sent to the client, we release them from the device. The device might have been stopped due to moving to the non-live phase of migration. Accessing the device memory during this phase can lead to inconsistencies. Also, MSG_MIGRATE should be the last message sent to the client, before MSG_MIGRATE_DATA. Due to this bug, msgs were marshalled and sent after handle_dev_stop and after handle_dev_display_migrate which sometimes led to the release of surfaces, and inserting MSG_DISPLAY_DESTROY_SURFACE after MSG_MIGRATE. This patch also removes the calls to red_wait_outgoing_items, from dev_flush_surfaces. They were unnecessary.
* smartcard.c: avoid marshalling migration data with reference to a memory ↵Yonit Halperin2012-11-261-1/+1
| | | | | | | | | that might be released before send has completed The current solution just copy the buffer. Currently data that is read from the guest is always copied before sending it to the client. When we will have ref count for these buffers, we can also use it for marshalling the migration data.
* red_worker.c: fix marshalling of migration dataYonit Halperin2012-11-261-6/+5
| | | | fix calling spice_marhsaller_add_ref with memory on stack
* reds.c: fix calls to spice_marshaller_add_ref with ptr to memory that might ↵Yonit Halperin2012-11-261-10/+14
| | | | be released before sending
* char_device.c: when the state is destroyed, also free the buffer that is ↵Yonit Halperin2012-11-261-0/+3
| | | | being written to the device
* char_device.c: add ref count for write-to-device buffersYonit Halperin2012-11-262-10/+44
| | | | | | The ref count is used in order to keep buffers that were in the write queue and now are part of migration data, in case the char_device state is destroyed before we complete sending the migration data.
* char_device.c: fix call to spice_marshaller_add_ref with memory on stackYonit Halperin2012-11-211-6/+8
| | | | rhbz#862352
* red_worker.c: fix calling set_client_capabilities when it is unsupported by qemuYonit Halperin2012-11-121-10/+8
| | | | | | The erroneous call was in handle_dev_start. This patch also fixes not calling set_client_capabilities when the qxl major_version is > 3.
* display seamless migration: no need to trace the generation of the primary ↵Yonit Halperin2012-11-121-35/+16
| | | | | | | surface We no longer process destroy_primary or destroy_surfaces while waiting for migration data.
* display seamless migration: don't process both cmd ring and dispatcher queue ↵Yonit Halperin2012-11-121-7/+36
| | | | | | | | | | | | | | | | | | till migration data is received fix: rhbz#866929 At migration destination side, we need to restore the client's surfaces state, before sending surfaces related messages. Before this patch, we stopped the processing of only the cmd ring, till migration data arrived. However, some QXL_IOs require reading and rendering the cmd ring (e.g., update_area). Moreover, when the device is reset, after destroying all surfaces, we assert (in qemu) if the cmd ring is not empty (see rhbz#866929). This fix makes the red_worker thread wait till the migration data arrives (or till a timeout), and not process any input from the device after the vm is started.
* Revert "server: add websockets support via libwebsockets"Alon Levy2012-11-049-455/+32
| | | | This reverts commit 63bb37276e028ab1b1c156c9e7907bf22b6d5952.
* server/red_worker: don't call set_client_capabilities if vm is stoppedAlon Levy2012-11-011-18/+46
| | | | | | | | | We try to inject an interrupt to the vm in this case, which we cannot do if it is stopped. Instead log this and update when vm restarts. RHBZ: https://bugzilla.redhat.com/show_bug.cgi?id=870972 (that bz is on qemu, it will be cloned or just changed, not sure yet)
* server/red_worker: wip: VALIDATE_SURFACE macros, remove asserts (but too ↵Alon Levy2012-10-251-12/+50
| | | | late - should be done earlier)
* release 0.12.1Alon Levy2012-10-251-1/+1
|
* server: add websockets support via libwebsocketsAlon Levy2012-10-259-32/+455
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | New API: spice_server_set_ws_ports This adds an optional dependency on libwebsockets. You need to get my patched 0.0.3 version here: git://people.freedesktop.org/~alon/libwebsockets There is no qemu patches yet, to test change in reds.c the default value of spice_ws_port to 5959 (for the default of spice-html5). For testing there is an online client at http://spice-space.org/spice-html5/spice.html Known issues: 1. The tester (server/tests/test_display_no_ssl) gets into dropping all data after a few seconds, I think it's an issue with the implemented watches, but haven't figured it out. 2. libwebsocket's read interface is inverted to what our code expects, i.e. there is no libwebsocket_read, so there is an additional copy involved (see RedsWebSocket). This can be fixed. 3. Listening on a separate port. Since the headers are different, we could listen on the same port (first three bytes RED/GET). I don't know if we want to? Todos: 1. SSL not implemented yet. Needs some thought as to how. 2. Serve spice-html5 when accessed as a http server. Nice to have.
* server/red_worker: stride > 0 is tested, remove abortAlon Levy2012-10-251-3/+0
| | | | Tested using the wip driver and xf86-video-modesetting.
generated by cgit (git 2.34.1) at 2024-06-19 10:43:14 +0000