Also move the RedClient struct out of the header to avoid accessing the
internals from other files.
Signed-off-by: Jonathon Jongsma <jjongsma@redhat.com>
Acked-by: Frediano Ziglio <fziglio@redhat.com>
Instead of requiring the channel client to lock the client's lock,
re-arrange things so that all of the locking can be internal to
RedClient methods. So instead of having a pre-create validate function,
we simply move the check to red_client_add_channel() and return an error
if a channel already exists. This encapsulates the client implementation
better and also reduces code duplication in RedChannelClient and
DummyChannelClient.
Signed-off-by: Jonathon Jongsma <jjongsma@redhat.com>
Acked-by: Frediano Ziglio <fziglio@redhat.com>
Switch from a Ring to a GList so that we can hide the internals of
RedClient in a future commit.
Signed-off-by: Jonathon Jongsma <jjongsma@redhat.com>
Acked-by: Frediano Ziglio <fziglio@redhat.com>
It's already defined in the same file some lines above.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Jonathon Jongsma <jjongsma@redhat.com>
Make the order of initialization closer to what it was before
conversion to GObject.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Jonathon Jongsma <jjongsma@redhat.com>
These fields need just channel to be set to be initialized.
Move their initialization to constructor to make sure
they are initialized as soon as possible.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Jonathon Jongsma <jjongsma@redhat.com>
There was a chance that on error GQueue were not
initialized but an attempt to destroy it is made.
This ensures GQueue is initialized as soon as
possible. Note that red_channel_client_initable_init
is called after all init and construction callbacks.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Jonathon Jongsma <jjongsma@redhat.com>
Internal types use the 'Red' prefix by convention, rather than the
'Spice' prefix. In addition, this type inherits from RedChannel, so
makes the code a lot clearer to call it a 'channel' rather than a
'state'.
Signed-off-by: Jonathon Jongsma <jjongsma@redhat.com>
Acked-by: Frediano Ziglio <fziglio@redhat.com>
id field of RedChannelClient is not used and marked as debugging.
Also it's value is quite confusing.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Pavel Grunt <pgrunt@redhat.com>
In commit beec1b41, we manually limited this property value in
_set_property(). But there's a simpler way to do it: via the param spec
for the property.
This also means that we can remove the warning log in red_worker_new()
since GObject will automatically warn if a property is assigned a value
outside of its valid range.
Change the minimum and default value for this property from 0 to 1 so
that we always have a primary surface.
Signed-off-by: Jonathon Jongsma <jjongsma@redhat.com>
Acked-by: Frediano Ziglio <fziglio@redhat.com>
These functions were implementing the same stuff as empty
messages functions provided by RedChannel so reuse them.
The implementation seems a bit different but the result
is the same. Specifically:
- RedEmptyMsgPipeItem::msg is int while RedVerbItem::verb was
uint16_t however this data goes into the message type which
is uint16_t (a 16 bit on the network protocol);
- red_channel_client_send_empty_msg calls
red_channel_client_begin_send_message while red_marshall_verb
does not. However red_marshall_verb is called only by
cursor_channel_send_item and dcc_send_item which always
calls red_channel_client_begin_send_message.
Note that in dcc_send_item when an empty message is sent
red_channel_client_send_message_pending always returns
true;
- when a PipeItem is created red_channel_client_pipe_add_empty_msg
calls red_channel_client_push while red_pipe_add_verb does not.
This actually make very little difference as this kind of item are
never removed from the queue and a push is forced in every case
running the event handler for the stream watch (see
prepare_pipe_add and red_channel_client_event).
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Jonathon Jongsma <jjongsma@redhat.com>
red_drawable_unref declaration was moved to red-parse-qxl.h.
Result is that only RedDispatcher know of the existence of RedWorker.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Pavel Grunt <pgrunt@redhat.com>
No reason why RedWorker should know the capabilities of
DisplayChannel.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Christophe Fergeau <cfergeau@redhat.com>
When uncapped x264enc can compress the frames beyond recognition in low
bitrate situation. Beyond the set limit the gains are modest and it is
better to drop frames to reduce the bit rate further.
Signed-off-by: Francois Gouget <fgouget@codeweavers.com>
Acked-by: Frediano Ziglio <fziglio@redhat.com>
This was introduced with 96e94c6f32
(Convert RedChannel hierarchy to GObject).
The id of CursorChannel/DisplayChannel were always 0 causing
a wrong assertion on the code.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Christophe Fergeau <cfergeau@redhat.com>
In this case there is not much change but better
to follow that style as all other constructors
do.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Christophe Fergeau <cfergeau@redhat.com>
This was introduced with 96e94c6f32
(Convert RedChannel hierarchy to GObject).
The handle-acks settings was TRUE for CursorChannel and DisplayChannel.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Christophe Fergeau <cfergeau@redhat.com>
This was introduced with 96e94c6f32
(Convert RedChannel hierarchy to GObject).
The type for "core-interface" property should be
SpiceCoreInterfaceInternal, not SpiceCoreInterface.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Christophe Fergeau <cfergeau@redhat.com>
96e94c6f inadvertantly introduced a regression where an assert was
triggered in red_channel_constructed for DummyChannel since DummyChannel
didn't implement any of the expected RedChannel vfuncs. This patch
avoids the assert by assigning some empty vfuncs.
Acked-by: Pavel Grunt <pgrunt@redhat.com>
Signed-off-by: Jonathon Jongsma <jjongsma@redhat.com>
red-common.h included utils.h which included red-common.h
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Jonathon Jongsma <jjongsma@redhat.com>
Allow both compiled and non-compiled tests to be used with "make
check". Compiled tests should be added to check_PROGRAMS, and scripts
that do not need to be built should be added to TESTS.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Jonathon Jongsma <jjongsma@redhat.com>
This makes red_monitors_config_item_new() and
red_monitors_config_item_free() symmetric.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Jonathon Jongsma <jjongsma@redhat.com>
These are already defined in red-channel.h which is included in
red-channel-client.h header.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Jonathon Jongsma <jjongsma at redhat.com>
vdi_port_read_buf_release is registered passing data as
RedVDIReadBuf*, not RedPipeItem*. Cast opaque to proper
pointer type to avoid the assumption that first field of
RedVDIReadBuf is a RedPipeItem.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Pavel Grunt <pgrunt@redhat.com>
This patch prevents a leak in case the function returns early
Found by coverity.
Signed-off-by: Uri Lublin <uril@redhat.com>
Acked-by: Frediano Ziglio <fziglio@redhat.com>
Silence a warning:
reds.c:150:25: warning: 'lock_cs' defined but not used [-Wunused-variable]
static pthread_mutex_t *lock_cs;
Acked-by: Frediano Ziglio <fziglio@redhat.com>
This fixes a compilation error with gcc 4.4.7 on RHEL 6.8.
Signed-off-by: Francois Gouget <fgouget@codeweavers.com>
Acked-by: Frediano Ziglio <fziglio@redhat.com>
In preparation for converting RedChannel to GObject, switch to using
RED_CHANNEL()-type macros for casting. For now they just do a regular
cast, but it helps reduce the size of the GObject patch to make it
easier to review.
Acked-by: Frediano Ziglio <fziglio@redhat.com>
Move out of red-worker.c. This requires a little bit of minor
refactoring to avoid accessing some RedWorker internals in the
constructor function, etc.
Acked-by: Frediano Ziglio <fziglio@redhat.com>
CursorChannelClient is already defined in cursor-channel-client.h.
This fixes compilation errors with gcc 4.4.7 on RHEL 6.8.
Signed-off-by: Francois Gouget <fgouget@codeweavers.com>
Acked-by: Pavel Grunt <pgrunt@redhat.com>
When MainChannelClient was split to a separate file, the responsibility
for incrementing this field was supposed to belong to the MainChannel
function (main_channel_connect_semi_seamless()), but by mistake it was
incremented both there and in the client function
(main_channel_client_connect_semi_seamless()).
The bug was introduced in a11b785f19
Acked-by: Frediano Ziglio <fziglio@redhat.com>
Convert the RedChannelClient heirarchy into GObjects. Since the existing
constructors could fail and return NULL, I inherited the base channel
client from GInitable, which introduces a dependency on gio.
When using private structs with GObject, there's a maximum size of (I
think) 64k, which was exceeded by some of the private structs. To avoid
this limitation I changed some members to dynamically allocated.
Attempt to use consistent naming.
Usually we use surface name for RedSurface.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Christophe Fergeau <cfergeau@redhat.com>
Attempt to use consistent naming.
Usually we use surface name for RedSurface so make sure
code reader do not get confused using a different name
for RedSurfaceCmd.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Christophe Fergeau <cfergeau@redhat.com>
This function deal only with Stream.
Also the name was misleading and was not clear if it detached the stream
from the DisplayChannel.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Christophe Fergeau <cfergeau@redhat.com>
Currently this is simply avoided by the fact that Virgl with 3d means
Unix socket. Once you enable (in Qemu) tcp sockets this message will
be added to all clients (supposing multiple clients) so potentially
will be in all queues. The same check is done for dcc_gl_scanout_item_new.
dcc_gl_scanout_item_new is called when Qemu calls spice_qxl_gl_draw_async.
Technically a client can support SPICE_DISPLAY_CAP_GL_SCANOUT but server
cannot send the DRM prime directly as this require a unix socket so
if the test for SPICE_DISPLAY_CAP_GL_SCANOUT is done here it make sense
to do the check for the socket type too.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Christophe Fergeau <cfergeau@redhat.com>
Move large buffer field at the end of structure.
Due to the way machine address memory this usually can reduce code size
and make program sligthly faster.
Actually reduce size by 100 bytes.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Pavel Grunt <pgrunt@redhat.com>
In case of invalid value the original compression is unchanged.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Pavel Grunt <pgrunt@redhat.com>
These fields were added in a32e90257e
as part of the multiple client support and were never used.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Jonathon Jongsma <jjongsma@redhat.com>
All other options are documented using initial capital case letter.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Jonathon Jongsma <jjongsma@redhat.com>
serial was the future serial to send while last_sent_serial was the
last sent.
serial sent started from 1.
To make sure sequence variable is updated just before sending the
message, not every message prepared.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Jonathon Jongsma <jjongsma@redhat.com>
Avoid negative syntax. Also could prevent some memory problem is number
get too big.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Jonathon Jongsma <jjongsma@redhat.com>
Currently on Linux PRIu64 and SCNu64 are the same but just to make
sure in the future use the correct macros.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Jonathon Jongsma <jjongsma@redhat.com>
Do the check after replay_fscanf to make sure everything
is fine before calling red_replay_compat_drawable or
red_replay_native_drawable.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Jonathon Jongsma <jjongsma@redhat.com>
Change the return to ssize_t to be able to distinguish from
empty buffer to error.
Check result returned and avoid continuing potentially
deferencing NULL pointers.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Jonathon Jongsma <jjongsma@redhat.com>
To check fscanf read all needed information a dummy "%n" is appended
to any string and the value stored there is tested. This as scanf family
could return a valid value but not entirely process the string so
adding a "%n" and checking this was processed make sure all expected
string is found.
The code to check for a specific string is now a bit more complicated
as replay_fscanf use a macro which append a constant string.
The "error" field is used to mark any error happened, so in most cases
there is no explicit check beside when this could cause a problem
(for instance results of replay_fscanf used which would result in
uninitialised variable usage).
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Jonathon Jongsma <jjongsma@redhat.com>
Allocations are kept into a GList to be able to free in case some
errors happened.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Jonathon Jongsma <jjongsma@redhat.com>
FOREACH_DCC should be more DisplayChannel related.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Jonathon Jongsma <jjongsma@redhat.com>
Noting that coding by hand these loop introduced some regression
I'm trying to introduce back from macros.
Before trying something harder to make possible to bind the type of
the content I'm trying some simple macro as were before.
I added the type to avoid some blindly void* casts.
Also the GListIter is introduced to avoid the possibility to exchange
easily some parameters.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Jonathon Jongsma <jjongsma@redhat.com>
The check for free_list->wait.header.wait_count was always true.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Uri Lublin <uril@redhat.com>
In anticipation of porting to GObject, use casting macros (e.g.
MAIN_CHANNEL_CLIENT()) to cast RedChannelClient types. This will help
reduce the changeset slightly porting to GObject and thus make it easier
to review those upcoming changes.
Acked-by: Frediano Ziglio <fziglio@redhat.com>
Instead of using a Ring (and having a ring item link in every pipe
item), store them in a GQueue. This also necesitated changing
RedCharDeviceVDIPort->priv->read_bufs to a GList as well.
Also Optimise client pipe by passing pipe position instead of data.
This avoids having the search the data scanning all the queue changing
the order of these operations from O(n) to O(1).
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Move all of the DisplayChannel data memembers into a private struct to
encapsulate things better. This necessitated a few new 'public' methods
and a small bit of refactoring to avoid poking into DisplayChannel
internals from too many places. The DisplayChannel and the
DisplayChannelClient are still far too intertwined to completely avoid
accessing private data, so at the moment the private struct is defined
in display-channel.h and the DisplayChannelClient implementation
still accesses it sometimes.
The eof variable and enumeration will be used for all errors
so avoid confusion.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Pavel Grunt <pgrunt@redhat.com>
read_binary do not allocate a buffer for no-NULL pointers.
Avoid using uninitialized data and allocate proper buffer.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Pavel Grunt <pgrunt@redhat.com>
Explicitely discard AGENT_MSG_FILTER_MONITORS_CONFIG messages
from the agent.
Also remove unused AGENT_MSG_FILTER_END
Acked-by: Frediano Ziglio <fziglio@redhat.com>
Make RedsState::mig_target_clients into a GList to improve encapsulation
and maintainability. Also RedsMigTargetClient::pending_links. With
GList, a type implementation can be ignorant of whether they're
contained within a list or not.
Acked-by: Frediano Ziglio <fziglio@redhat.com>
Encapsulate private data of CursorChannel in a private struct. This
isn't very useful at the moment, but it will help prepare the way for
porting the RedChannel heirarchy to GObject.
Acked-by: Pavel Grunt <pgrunt@redhat.com>
Both src->stride and src->y are uint32_t
Fixed by making one of them uint64_t
Found by coverity
Signed-off-by: Uri Lublin <uril@redhat.com>
Acked-by: Frediano Ziglio <fziglio@redhat.com>
Previously we were creating a variable named 'dev_state' and then
apparently not using it. Well, we *were* actually using it, but in a
convoluted sort of way. Creating a new RedCharDevice has a
side-effect of setting itself as the 'st' attribute of
SpiceCharDeviceInstance. So 'dev_state' and 'char_device->st' are in
fact the same variable. But they were being used interchangeably, which
was rather confusing. For example
if (dev_state)
// do something with char_device->st
So this patch doesn't actually change anything, but it makes the code a
bit easier to follow.
Acked-by: Frediano Ziglio <fziglio@redhat.com>
main_channel_client_start_net_test() checks MainChannelClient already
which is the single reason why main_channel_client_push_ping() could
fail. Reorganizing this code a little bit.
Acked-by: Frediano Ziglio <fziglio@redhat.com
These need to be introduced at the same time since cache-item.tmpl.c
assumes that both of these classes will have a cache in the same place:
either within the channel client struct itself or (now) within a priv
struct owned by the channel client.
This encapsulates private data and prepares for porting to GObject.
Acked-by: Frediano Ziglio <fziglio@redhat.com
Agent properties like file transfer or copy & paste can be disabled by
calling spice_server_set_agent_{copypaste, file_xfer} before the spice
server is initialized. In that case the call crashes the server because
the agent device is created after the initialization.
To avoid the crash this commit introduce a helper function for setting
the agent properties after the server is initialized.
Acked-by: Frediano Ziglio <fziglio@redhat.com>
More preparation for separating RedChannelClient into a separate file.
Rename function slightly for improved readability:
red_channel_client_blocked() -> red_channel_client_is_blocked()
Encapsulate the structure a bit more and avoid poking into it from other
class implementations. Getting ready to split RedChannelClient out to a
separate file.
Instead of having all other classes poke into the RedChannelClient
struct to get the RedClient associated with the channel client, call the
accessor function. This commit allows us to encapsulate RedChannelClient
and move it to its own file soon.
Don't poke into the structure to get the channel
This prepares for encapsulating RedChannelClient a bit more and
separating it into its own source file.
spice-server.h cannot include glib.h because it is a public header and
is used by projects that do not use GLib.
Signed-off-by: Francois Gouget <fgouget@codeweavers.com>
Acked-by: Frediano Ziglio <fziglio@redhat.com>
This avoid a check for NULL.
Also will be used to catch invalid values when table will be extended.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Pavel Grunt <pgrunt@redhat.com>
Reduce structure length using static allocated string inside the
structure.
This will also avoid using .data.rel.ro section and relocations
reducing even more library size.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Pavel Grunt <pgrunt@redhat.com>
The field is only used by DisplayChannelClient, not by CursorChannelClient
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Jonathon Jongsma <jjongsma@redhat.com>
The function was just calling another function with same parameters
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Jonathon Jongsma <jjongsma@redhat.com>
This reduces the number of arguments that need to be passed to the
function, and also avoids changing a different object within a function
that is supposed to just create a new object
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Jonathon Jongsma <jjongsma@redhat.com>
Add a few more methods and accessors so that other files don't need to
manipulate the struct members directly. Move the struct definition to a
private header which only the dcc-* files will include.
Signed-off-by: Jonathon Jongsma <jjongsma@redhat.com>
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Frediano Ziglio <fziglio@redhat.com>
This allow option string to contain separator so you could set as
"field=value ! format".
This is useful as some encoders use the output format to specify
compression types (for instance with some H264 encoders you can
specify the profile to use).
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Pavel Grunt <pgrunt@redhat.com>
Do not handle them as normal keys.
State is not saved for these keys.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Pavel Grunt <pgrunt@redhat.com>
key and key_ext in SpiceKbdState are indexed using
state[scan & 0x7f]
where scan is a 8 bit value got from client. In theory client can send
any value causing scan & 0x7f to be 0x7f. However these arrays contains
only 0x7f values so 0x7f cause a off one overflow.
This potentially cause key_ext to overflow in reds pointer following.
Happily this is not exploitable in either 32 or 64 bit environment.
On 64 bit key_ext is followed by a 4 byte (sizeof(bool) == 4) padding
which is written by the possible overflow.
On 32 bit reds will be overwritten with either 0 or 1 which will cause
a SIGSEGV leading to a DoS. Considering that you have to have access
to the machine with a client you are just shutting down only guests you
can access to.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Uri Lublin <uril@redhat.com>
Eventually, during a seamless migration, qemu may finish to migrate
before the spice client even finished to connect all channels to
destination and informed the server. In this case,
main_channel_client_migrate_src_complete() will fall back to
switch-host method, and reds_mig_fill_wait_disconnect() is called to
complete the migration (disconnecting all channels).
reds_mig_cleanup() is called when all channels are disconnected, but
reds->mig_wait_connect is still TRUE, and it will call
migrate_connect_complete() instead of the expected
migrate_end_complete(). Setting reds->mig_wait_connect to FALSE when
reds_mig_fill_wait_disconnect() solves the issue.
Fixes:
https://bugzilla.redhat.com/show_bug.cgi?id=1352836
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Without a video encoder no frame will be streamed anyway.
This fixes the case where the client does not support any of the
server's codecs, such as if it was compiled with --enable-gstvideo=no
--disable-builtin-mjpeg.
Signed-off-by: Francois Gouget <fgouget@codeweavers.com>
g_object_new is a variadic function which takes property values.
As the compiler cannot check if these property values are correct,
make sure they are using casts.
This actually fixes a crash in reds.c for 32 bit architectures.
Based on a patch by Frediano Ziglio <fziglio@redhat.com>
Signed-off-by: Francois Gouget <fgouget@codeweavers.com>
This happens during VM shutdown.
Qemu should never send a draw command without scanout.
This should be fixed in Qemu or in Virgl driver.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Uri Lublin <uril@redhat.com>
This is related to CVE-2016-0749
==529== ERROR: AddressSanitizer: heap-buffer-overflow on address 0x60040009c098 at pc 0x7fffee0eda6d bp 0x7fffffffcd00 sp 0x7fffffffccf0
WRITE of size 4 at 0x60040009c098 thread T0
#0 0x7fffee0eda6c in smartcard_char_device_notify_reader_add /home/elmarco/pkg/spice/spice-0.12.4/server/smartcard.c:334
#1 0x7fffee0ef783 in smartcard_add_reader /home/elmarco/pkg/spice/spice-0.12.4/server/smartcard.c:642
#2 0x7fffee0f0568 in smartcard_channel_handle_message /home/elmarco/pkg/spice/spice-0.12.4/server/smartcard.c:757
#3 0x7fffee032f3f in red_peer_handle_incoming /home/elmarco/pkg/spice/spice-0.12.4/server/red_channel.c:304
#4 0x7fffee033216 in red_channel_client_receive /home/elmarco/pkg/spice/spice-0.12.4/server/red_channel.c:322
#5 0x7fffee03bf1f in red_channel_client_event /home/elmarco/pkg/spice/spice-0.12.4/server/red_channel.c:1561
#6 0x555555c3c53d in qemu_iohandler_poll /home/elmarco/src/qemu/iohandler.c:143
#7 0x555555c3b800 in main_loop_wait /home/elmarco/src/qemu/main-loop.c:504
#8 0x5555556f160c in main_loop /home/elmarco/src/qemu/vl.c:1818
#9 0x5555556f160c in main /home/elmarco/src/qemu/vl.c:4394
#10 0x7fffed80eb14 in __libc_start_main /usr/src/debug/glibc-2.17-c758a686/csu/libc-start.c:274
#11 0x5555556f9c20 in _start (/home/elmarco/src/qemu/x86_64-softmmu/qemu-system-x86_64+0x1a5c20)
0x60040009c098 is located 0 bytes to the right of 8-byte region [0x60040009c090,0x60040009c098)
allocated by thread T0 here:
#0 0x7ffff4e612be in __interceptor_realloc /usr/src/debug/gcc-4.8.5-20150702/obj-x86_64-redhat-linux/x86_64-redhat-linux/libsanitizer/asan/../../../../libsanitizer/asan/asan_malloc_linux.cc:92
#1 0x7fffee121308 in spice_realloc /home/elmarco/pkg/spice/spice-0.12.4/spice-common/common/mem.c:123
#2 0x7fffee004a48 in __spice_char_device_write_buffer_get /home/elmarco/pkg/spice/spice-0.12.4/server/char_device.c:516
#3 0x7fffee004e87 in spice_char_device_write_buffer_get /home/elmarco/pkg/spice/spice-0.12.4/server/char_device.c:557
#4 0x7fffee0ed8b9 in smartcard_char_device_notify_reader_add /home/elmarco/pkg/spice/spice-0.12.4/server/smartcard.c:325
#5 0x7fffee0ef783 in smartcard_add_reader /home/elmarco/pkg/spice/spice-0.12.4/server/smartcard.c:642
#6 0x7fffee0f0568 in smartcard_channel_handle_message /home/elmarco/pkg/spice/spice-0.12.4/server/smartcard.c:757
#7 0x7fffee032f3f in red_peer_handle_incoming /home/elmarco/pkg/spice/spice-0.12.4/server/red_channel.c:304
#8 0x7fffee033216 in red_channel_client_receive /home/elmarco/pkg/spice/spice-0.12.4/server/red_channel.c:322
#9 0x7fffee03bf1f in red_channel_client_event /home/elmarco/pkg/spice/spice-0.12.4/server/red_channel.c:1561
#10 0x555555c3c53d in qemu_iohandler_poll /home/elmarco/src/qemu/iohandler.c:143
SUMMARY: AddressSanitizer: heap-buffer-overflow /home/elmarco/pkg/spice/spice-0.12.4/server/smartcard.c:334 smartcard_char_device_notify_reader_add
Signed-off-by: Marc-Andre Lureau <marcandre.lureau@redhat.com>
There is an unref when the message is sent.
This is related to CVE-2016-0749
==17204== ERROR: AddressSanitizer: heap-use-after-free on address 0x6008000144a8 at pc 0x7fffee0ce245 bp 0x7fffffffc630 sp 0x7fffffffc620
READ of size 4 at 0x6008000144a8 thread T0
#0 0x7fffee0ce244 in smartcard_unref_vsc_msg_item /home/elmarco/src/spice/spice/server/smartcard.c:608
#1 0x7fffee0cb451 in smartcard_unref_msg_to_client /home/elmarco/src/spice/spice/server/smartcard.c:178
#2 0x7fffedfcdf14 in spice_char_device_read_from_device /home/elmarco/src/spice/spice/server/char-device.c:330
#3 0x7fffedfd1763 in spice_char_device_wakeup /home/elmarco/src/spice/spice/server/char-device.c:901
#4 0x7fffee05da98 in spice_server_char_device_wakeup /home/elmarco/src/spice/spice/server/reds.c:2990
#5 0x55555593fa34 in spice_chr_write /home/elmarco/src/qemu/spice-qemu-char.c:189
#6 0x5555559375f1 in qemu_chr_fe_write /home/elmarco/src/qemu/qemu-char.c:220
#7 0x555555b3b682 in ccid_card_vscard_send_msg.isra.2 /home/elmarco/src/qemu/hw/usb/ccid-card-passthru.c:76
#8 0x555555b3c466 in ccid_card_vscard_send_error /home/elmarco/src/qemu/hw/usb/ccid-card-passthru.c:91
#9 0x555555b3c466 in ccid_card_vscard_handle_message /home/elmarco/src/qemu/hw/usb/ccid-card-passthru.c:242
#10 0x555555b3c466 in ccid_card_vscard_read /home/elmarco/src/qemu/hw/usb/ccid-card-passthru.c:289
#11 0x55555593f169 in vmc_write /home/elmarco/src/qemu/spice-qemu-char.c:41
#12 0x7fffedfcee6d in spice_char_device_write_to_device /home/elmarco/src/spice/spice/server/char-device.c:477
#13 0x7fffedfcfd31 in spice_char_device_write_buffer_add /home/elmarco/src/spice/spice/server/char-device.c:629
#14 0x7fffee0ce9df in smartcard_channel_write_to_reader /home/elmarco/src/spice/spice/server/smartcard.c:675
#15 0x7fffee0cc7db in smartcard_char_device_notify_reader_add /home/elmarco/src/spice/spice/server/smartcard.c:341
#16 0x7fffee0ce4f3 in smartcard_add_reader /home/elmarco/src/spice/spice/server/smartcard.c:648
#17 0x7fffee0cf2e2 in smartcard_channel_handle_message /home/elmarco/src/spice/spice/server/smartcard.c:763
#18 0x7fffedffe21f in red_peer_handle_incoming /home/elmarco/src/spice/spice/server/red-channel.c:307
#19 0x7fffedffe4f6 in red_channel_client_receive /home/elmarco/src/spice/spice/server/red-channel.c:325
#20 0x7fffee00726c in red_channel_client_event /home/elmarco/src/spice/spice/server/red-channel.c:1566
#21 0x555555c3c53d in qemu_iohandler_poll /home/elmarco/src/qemu/iohandler.c:143
#22 0x555555c3b800 in main_loop_wait /home/elmarco/src/qemu/main-loop.c:504
#23 0x5555556f160c in main_loop /home/elmarco/src/qemu/vl.c:1818
#24 0x5555556f160c in main /home/elmarco/src/qemu/vl.c:4394
#25 0x7fffed7d0b14 in __libc_start_main /usr/src/debug/glibc-2.17-c758a686/csu/libc-start.c:274
#26 0x5555556f9c20 in _start (/home/elmarco/src/qemu/x86_64-softmmu/qemu-system-x86_64+0x1a5c20)
0x6008000144a8 is located 24 bytes inside of 40-byte region [0x600800014490,0x6008000144b8)
freed by thread T0 here:
#0 0x7ffff4e61009 in __interceptor_free /usr/src/debug/gcc-4.8.5-20150702/obj-x86_64-redhat-linux/x86_64-redhat-linux/libsanitizer/asan/../../../../libsanitizer/asan/asan_malloc_linux.cc:61
#1 0x7fffee0ce2a1 in smartcard_unref_vsc_msg_item /home/elmarco/src/spice/spice/server/smartcard.c:610
#2 0x7fffee0cdd58 in smartcard_channel_release_pipe_item /home/elmarco/src/spice/spice/server/smartcard.c:548
#3 0x7fffee000668 in red_channel_client_release_item /home/elmarco/src/spice/spice/server/red-channel.c:602
#4 0x7fffee0006ef in red_channel_client_release_sent_item /home/elmarco/src/spice/spice/server/red-channel.c:609
#5 0x7fffee0007b5 in red_channel_peer_on_out_msg_done /home/elmarco/src/spice/spice/server/red-channel.c:620
#6 0x7fffedffed7e in red_peer_handle_outgoing /home/elmarco/src/spice/spice/server/red-channel.c:385
#7 0x7fffee0057bb in red_channel_client_send /home/elmarco/src/spice/spice/server/red-channel.c:1294
#8 0x7fffee0076e6 in red_channel_client_begin_send_message /home/elmarco/src/spice/spice/server/red-channel.c:1605
#9 0x7fffee0cdccd in smartcard_channel_send_item /home/elmarco/src/spice/spice/server/smartcard.c:541
#10 0x7fffee000570 in red_channel_client_send_item /home/elmarco/src/spice/spice/server/red-channel.c:588
#11 0x7fffee005bfb in red_channel_client_push /home/elmarco/src/spice/spice/server/red-channel.c:1347
#12 0x7fffee007ef7 in red_channel_client_pipe_add_push /home/elmarco/src/spice/spice/server/red-channel.c:1673
#13 0x7fffee0cde4d in smartcard_channel_client_pipe_add_push /home/elmarco/src/spice/spice/server/smartcard.c:571
#14 0x7fffee0cb567 in smartcard_send_msg_to_client /home/elmarco/src/spice/spice/server/smartcard.c:187
#15 0x7fffedfcdba2 in spice_char_device_send_msg_to_clients /home/elmarco/src/spice/spice/server/char-device.c:282
#16 0x7fffedfcdea4 in spice_char_device_read_from_device /home/elmarco/src/spice/spice/server/char-device.c:329
#17 0x7fffedfd1763 in spice_char_device_wakeup /home/elmarco/src/spice/spice/server/char-device.c:901
#18 0x7fffee05da98 in spice_server_char_device_wakeup /home/elmarco/src/spice/spice/server/reds.c:2990
#19 0x55555593fa34 in spice_chr_write /home/elmarco/src/qemu/spice-qemu-char.c:189
Signed-off-by: Marc-Andre Lureau <marcandre.lureau@redhat.com>
Users should not change the list of supported subtypes.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Jonathon Jongsma <jjongsma@redhat.com>
Was used as write variable only for testing.
Avoid usage of not constant globals.
Making globals constants avoid future race condition
usages.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Jonathon Jongsma <jjongsma@redhat.com>
Avoid multiple initializations of this library.
Also initialize using thread safe code to avoid possible race
conditions.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Pavel Grunt <pgrunt@redhat.com>
Current Linux pthread implementation should use futex so there should
be no leak but calling destroy avoid possible future leaks.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Jonathon Jongsma <jjongsma@redhat.com>
Encoding image requires a RedDrawable (where the data is stored) and
a Ring where to store information to free Glz structures.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Jonathon Jongsma <jjongsma@redhat.com>
Remove some coupling, we mainly need to store a list of RedGlzDrawables.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Jonathon Jongsma <jjongsma@redhat.com>
Do not access too much encoders data.
Slightly different as now if glz is frozen lz compression is used.
Glz is frozen only during migration.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Jonathon Jongsma <jjongsma@redhat.com>
RedCompressBuf are no longer pooled.
The usage was removed in 92d9b782bd.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Jonathon Jongsma <jjongsma@redhat.com>
Let's follow the 'standard' for optional components. This commit also
drops (now) unecessary #ifdef USE_LZ4 from lz4-encode.c, as the decision
to build this file is now made in Makefile.
Signed-off-by: Eduardo Lima (Etrunko) <etrunko@redhat.com>
Acked-by: Christophe Fergeau <cfergeau@redhat.com>
gpointer definition was not included causing the header to fails to
compile if included first.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Francois Gouget <fgouget@codeweavers.com>
Introduced by commit 903c91cd30, this
variable is used only for LZ4 code. Move the declaration to the proper
block of code.
Build log:
spicevmc.c: In function 'handle_compressed_msg':
spicevmc.c:346:14: error: variable 'decompressed' set but not used [-Werror=unused-but-set-variable]
uint8_t *decompressed;
^
Signed-off-by: Eduardo Lima (Etrunko) <etrunko@redhat.com>
Acked-by: Christophe Fergeau <cfergeau@redhat.com>
This was introduced by commit 903c91cd30.
To fix it, we simply protect the try_compress_lz4 function with proper
ifdef guards.
Build log:
spicevmc.c: In function 'try_compress_lz4':
spicevmc.c:143:5: error: implicit declaration of function 'LZ4_compress_default' [-Werror=implicit-function-declaration]
compressed_data_count = LZ4_compress_default((char*)&msg_item->buf,
^
spicevmc.c:143:5: error: nested extern declaration of 'LZ4_compress_default' [-Werror=nested-externs]
spicevmc.c: At top level:
spicevmc.c:124:24: error: 'try_compress_lz4' defined but not used [-Werror=unused-function]
static RedVmcPipeItem* try_compress_lz4(SpiceVmcState *state, int n, RedVmcPipeItem *msg_item)
^
Signed-off-by: Eduardo Lima (Etrunko) <etrunko@redhat.com>
Acked-by: Christophe Fergeau <cfergeau@redhat.com>
This buffer was just written and then used, no reason to store into
a more persistent structure.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Jonathon Jongsma <jjongsma@redhat.com>
Rename this function to red_glz_drawable_free() and remove the
ImageEncoders argument since the RedGlzDrawable already holds a pointer
to the ImageEncoders structure
Acked-by: Frediano Ziglio <fziglio@redhat.com>
Rename this function to glz_drawable_instance_item_free() and remove the
ImageEncoders argument since the RedGlzDrawable already holds a pointer
to the ImageEncoders structure.
Acked-by: Frediano Ziglio <fziglio@redhat.com>
The field was used just as a flag.
This has the advantage to make clear to not use the pointer as we don't
have ownership.
Also makes the structure a bit smaller.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Jonathon Jongsma <jjongsma@redhat.com>
configure will use GStreamer 1.0 if present and fall back to
GStreamer 0.10 otherwise.
ffenc_mjpeg takes its bitrate as a long so extend set_gstenc_bitrate().
Signed-off-by: Francois Gouget <fgouget@codeweavers.com>
This is faster and lets the encoder leverage past bitrate shaping
history to attain the target faster.
Signed-off-by: Francois Gouget <fgouget@codeweavers.com>
This typically happens when sending very small frames (less than
16 pixels in one dimension) to the x264enc encoder.
This avoids repeatedly wasting time rebuilding the pipeline.
Signed-off-by: Francois Gouget <fgouget@codeweavers.com>
The video encoder uses the client reports and/or notifications of
server frame drops as its feedback mechanisms. In particular it keeps
track of the maximum video margin and reduces the bit rate whenever the
margin goes below certain thresholds or decreases too sharply.
It uses these to figure out the lowest bit rate that causes negative
feedback, and the highest bit rate that allows a return to positive
feedbacks. It then works to narrow this range and settles on the lower
end once the spread has gone below a given threshold.
All the while it monitors the effective bit rate to ensure the target
bit rate does not grow significantly beyond what the GStreamer encoder
will produce: this avoids target bit rate 'bubbles' which would
invariably be followed by a bit rate crash with accompanying frame loss.
As soon as the network feedback indicates a significant degradation the
bit rate is lowered to minimize the risk of frame loss and/or long
freezes.
It also relies on the existing shaping of the GStreamer output bit rate
to minimize the pipeline reconfigurations.
Signed-off-by: Francois Gouget <fgouget@codeweavers.com>
The GStreamer codecs don't follow the specified bit rate very closely:
they can decide to exceed it for ten seconds or more if they consider
the scene deserves it. Such long bursts are enough to cause network
congestion, resulting in many lost frames which cause significant
display corruption.
So the GStreamer video encoder now uses a short 300ms virtual buffer
to shape the compressed video output and ensure we don't exceed the
target bit rate for any significant length of time.
It could instead rely on the network feedback (when available) to lower
the bit rate. However frequent GStreamer bit rate changes lower the
overall compression level and also result in a lower average bit rate,
both of which result in lower video quality.
The GStreamer video encoder also keeps track of the encoded frame size
so it can gather statistics and call update_client_playback_delay()
with accurate information and also annotate the client report debug
traces with the corresponding bit rate information.
Signed-off-by: Francois Gouget <fgouget@codeweavers.com>
Note that we can only avoid copies for the first 1 Mpixels or so.
That's because Spice splits larger frames into more chunks than we can
fit GstMemory fragments in a GStreamer buffer. So if there are more
pixels we will avoid copies for the first 3840 KB and copy the rest.
Furthermore, while in practice the GStreamer encoder will only modify
the RedDrawable refcount during the encode_frame(), in theory the
refcount could be decremented from the GStreamer thread after
encode_frame() returns.
Signed-off-by: Francois Gouget <fgouget@codeweavers.com>
If an error occurs for whatever reason (e.g. codec not supporting odd
frame sizes), the GStreamer pipeline will drop the current buffer,
causing the encoder to be stuck waiting for the sample. So this patch
tracks error notifications and ensures we don't wait for a sample if
none will come.
Signed-off-by: Francois Gouget <fgouget@codeweavers.com>
This way the video encoder is not forced to use malloc()/free().
This also allows more flexibility in how the video encoder manages the
buffer which allows for a zero-copy implementation in both video
encoders.
Signed-off-by: Francois Gouget <fgouget@codeweavers.com>
The Spice server administrator can specify the encoder and codec
preferences to optimize for CPU or bandwidth usage. Preferences are
described in a semi-colon separated list of encoder:codec pairs.
The server has a default preference list which can explicitly be
selected by specifying 'auto'.
Signed-off-by: Francois Gouget <fgouget@codeweavers.com>
The server picks a codec supported by the client based on the following
new client capabilities:
* SPICE_DISPLAY_CAP_MULTI_CODEC which denotes a recent client that
supports multiple codecs. This capability is needed to not have to
hardcode that MJPEG is supported. This makes it possible to write
clients that don't support MJPEG.
* SPICE_DISPLAY_CAP_CODEC_XXX, where XXX is a supported codec. Note
that for now the server only supports the MJPEG codec.
Signed-off-by: Francois Gouget <fgouget@codeweavers.com>
This introduces a pared down GStreamer-based video encoder to serve as
the basis for later enhancements.
In this form the new encoder supports both regular and sized streams
but lacks any rate control. It should still work fine if bandwidth is
sufficient such as on LANs.
Signed-off-by: Francois Gouget <fgouget@codeweavers.com>
encode_frame() needs the QXL_DRAW_COPY operation's SpiceCopy.src_area
field anyway, so the width and height parameters were redundant.
Signed-off-by: Francois Gouget <fgouget@codeweavers.com>
Video frames correspond to QXL_DRAW_COPY operations where the frame area
is defined by the SpiceCopy.src_area field.
Signed-off-by: Francois Gouget <fgouget@codeweavers.com>
After the removal of Drawable::sized_stream, we no longer need to detect
if the stream changes size in is_next_stream_frame() so it can return a
boolean rather than a value from an enum.
Only red_marshall_stream_data() needs to know whether to send the frame
using a SpiceMsgDisplayStreamDataSized or a regular StreamData message.
So check whether we have a sized frame there and simplify the rest of
the code.
Signed-off-by: Francois Gouget <fgouget@codeweavers.com>
This code just refactors the function without doing any functional
changes. The actual changes will be in the next commit, and this will
make the next commit much more obvious.
Usually the RedDrawable bbox dimensions match the src_area dimensions
so that checking that the bbox matches the stream's original dest_area
should be enough to determine if sized stream support is needed to
send the frame.
But making the bbox different could be used to have the scaling be
performed on the client side. So it's better not to assume the bbox and
src_area have the same dimensions.
Signed-off-by: Francois Gouget <fgouget@codeweavers.com>
Compressed message type is CompressedData which contains compression
type (1 byte) followed by the uncompressed data size (4 bytes - exists
only if data was compressed) followed by the compressed data
If SPICE_USBREDIR_CAP_DATA_COMPRESS_LZ4 capability is available &&
data_size > COMPRESS_THRESHOLD && !AF_LOCAL data will be sent
compressed otherwise data will be sent uncompressed (also if
compression has failed)
Update the required protocol to 0.12.12
Signed-off-by: Snir Sheriber <ssheribe@redhat.com>
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Frediano Ziglio <fziglio@redhat.com>
Encoders function should not use DisplayChannelClient
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Jonathon Jongsma <jjongsma@redhat.com>
This change is less clean the other similar patches as zlib and
glz require more steps.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Jonathon Jongsma <jjongsma@redhat.com>
dcc-encoders should be in change of allocate and free the structure
don't put internal assumptions (which functions are used for memory
management) in different files.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Christophe Fergeau <cfergeau@redhat.com>
Use red_time_t to make sure timestamp has the right precision even
on 32 bit systems.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Jonathon Jongsma <jjongsma@redhat.com>
Primary surface, as additional surfaces, can be used to access
host memory from the guest using invalid parameters.
The removed warning is not enough to prevent all cases. Also a warning
is not enough to stop an escalation to happen.
The red_validate_surface do different checks to make sure surface
request is valid and not cause possible buffer/integer overflows:
- format is valid;
- width is not large to cause overflow compared to stride;
- stride is not -2^31 (a number which negate is still <0);
- stride * height does not overflow.
This fixes https://bugzilla.redhat.com/show_bug.cgi?id=1312980.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Christophe Fergeau <cfergeau@redhat.com>
Make possible to reuse it outside red-parse-qxl.c.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Christophe Fergeau <cfergeau@redhat.com>
There is no reason to initialize these fields in two different places.
Note that an usage between dcc_new and the function where these
field were initialised would have resulted in a crash.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Jonathon Jongsma <jjongsma@redhat.com>
This function is never used outside this compile unit.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Jonathon Jongsma <jjongsma@redhat.com>
As the tokens counter were not being reset you could enter in a
situation where client thinks it has more tokens then server which
would eventually lead to client's disconnection from 0c5eca97f1
onwards (before it was crashing).
It is easy to check the above situation if you track the amount of
tokens you have in the client and simply kill and restart the agent
while doing some file transfer: the client could reach more then 13
tokens which should not really be possible.
Based on patch from Frediano Ziglio <fziglio@redhat.com>
Acked-by: Frediano Ziglio <fziglio@redhat.com>
Use red_record_cursor_cmd to be able to record cursor commands.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Jonathon Jongsma <jjongsma@redhat.com>
The segment_size computation on 32 bit can lead to big numbers which
can lead to negative offset. Let'ss avoid to underrun the buffer,
as it's not checked.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Fabiano Fidêncio <fidencio@redhat.com>
Use 64 bit arithmetic to avoid overflows.
The multiplication between count and a constant can overflow.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Fabiano Fidêncio <fidencio@redhat.com>
The source area should not extend outside the source bitmap, or have
swapped coordinates.
Signed-off-by: Francois Gouget <fgouget@codeweavers.com>
Acked-by: Frediano Ziglio <fziglio@redhat.com>
This variable was always the same value as
dispatcher_allows_client_mouse.
Acked-by: Frediano Ziglio <fziglio@redhat.com>
Signed-off-by: Jonathon Jongsma <jjongsma@redhat.com>
Possibly used for debugging or an initial recursive lock.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Jonathon Jongsma <jjongsma@redhat.com>
This fixes a regression introduced by
4028fb1c79, where clients_num
was not updated correctly anymore.
There is no reason to cache the number of elements on that list,
as the expected number of clients is quite small.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Eduardo Lima (Etrunko) <etrunko@redhat.com>
SpiceCharDeviceInstance is not a GObject, the GObject is char_device->st
as the above line is stating.
The crash never happen as Qemu never calls spice_server_remove_interface
for smartcards.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Jonathon Jongsma <jjongsma@redhat.com>
Setting "sin" property is equivalent to call
red_char_device_reset_dev_instance so there is no need for a if/else
as the code is doing mostly (beside setting agent_attached) the
same thing
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Jonathon Jongsma <jjongsma@redhat.com>
RedCharDevice used for the agent has flow control enabled.
This make possible for red_char_device_write_buffer_get to return NULL.
Handle such situation without crashing avoiding NULL dereference.
This fixes https://bugs.freedesktop.org/show_bug.cgi?id=95416.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Uri Lublin <uril@redhat.com>
Upcast conversions are by definition unsafe. There are however some
location where such conversion are more safe. In this case send_item
callback is registered specifically for this type of RedChannel making
the conversion more reliable.
The other conversion (CursorChannel -> RedChannel) became safe.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Jonathon Jongsma <jjongsma@redhat.com>
Avoid converting from RedChannelClient* to DisplayChannelClient* and
DisplayChannelClient* to RedChannelClient* just to use RedChannelClient*
('display_channel->clients' is a list of RedChannelClients).
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Uri Lublin <uril@redhat.com>
Avoid converting RedChannelClient* to CursorChannelClient* and then
CursorChannelClient* to RedChannelClient* just to use RedChannelClient*.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Uri Lublin <uril@redhat.com>
Rename red_record_dev_input_primary_surface_create to
red_record_primary_surface_create.
Name is more concise and was not clear what "dev_input" was supposed
to specify.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Jonathon Jongsma <jjongsma@redhat.com>
This allows compression using external programs or any type
of filters.
To use it set SPICE_WORKER_RECORD_FILTER environment to the
filter command you want to use. The command is executed with
g_spawn_async_with_pipes (which uses execve) so is not a shell
command although the command is parsed using g_shell_parse_argv
which split arguments as shell does.
One easy way to use it is to just use a compressor like gzip with
export SPICE_WORKER_RECORD_FILENAME=/tmp/qemu_record.gz
export SPICE_WORKER_RECORD_FILTER=gzip
qemu ...
The filter will receive the recording on standard input and is
supposed to write in output filename (which is the standard output).
You can use additional arguments in SPICE_WORKER_RECORD_FILTER to
specify for instance compression level.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Jonathon Jongsma <jjongsma@redhat.com>
Remove global/static from red_record_qxl.c.
Defined a structure and use it to hold record state.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Jonathon Jongsma <jjongsma@redhat.com>
The existence of this class can be hidden to user of CursorChannel class
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Jonathon Jongsma <jjongsma@redhat.com>
This function was handling mainly CursorChannel state
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Jonathon Jongsma <jjongsma@redhat.com>
Actually not exactly the same as this fix a bug if base is not the
first element (in this case if dpi_ring_item is NULL dpi is not)
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
The id type is already uint64_t, no need to cast using some low
level casts.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Jonathon Jongsma <jjongsma@redhat.com>
This reduce a bit the structure size and make clear that
the field is used only when the item is a cache item.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Jonathon Jongsma <jjongsma@redhat.com>
since display_channel_print_stats is now static, the compiler complains
when RED_WORKER_STAT is undefined since this function is not used:
../../server/display-channel.c:853:13: error: 'display_channel_print_stats' defined but not used [-Werror=unused-function]
To fix, don't define the function when RED_WORKER_STAT is undefined.
Acked-by: Victor Toso <victortoso@redhat.com>
Instead of using a Ring, use a GList to store the list of channel
clients. This allows us to iterate the clients without poking inside of
the client struct to get the channel_link. This is required in order to
make the RedChannelClient struct private.
This was proposed by Christophe as improvement over some typesafe
patches.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Christophe Fergeau <cfergeau@redhat.com>
Scan remaining code searching for problems with structure
layout assumptions in the code.
Where code required some restructuring put some verify checks
to make sure code won't compile if these assumptions are not
in place anymore.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Jonathon Jongsma <jjongsma@redhat.com>
Make code more type safe. This allow to move or delete structure
fields more safely
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Jonathon Jongsma <jjongsma@redhat.com>
All other classes using RedPipeItem as base use base as parent name
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Jonathon Jongsma <jjongsma@redhat.com>
This avoids having to retain a pointer just to check item is still in
the queue with ring_item_is_linked(&item->link).
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Jonathon Jongsma <jjongsma@redhat.com>
Remove the need to release the item inside send_item callbacks.
This looks like a partial rollback of previous patch but is
to make clear the intention of the change.
The lifetime of items could extend a bit further but there
are no cases this small lag should cause problems.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Jonathon Jongsma <jjongsma@redhat.com>
This is quite confusing and prone to errors.
Use RedPipeItem reference counting instead.
To compensate for the additional reference due to red_pipe_item_ref
in RedChannel sub class with empty hold_item have to add a
red_pipe_item_unref call in send_item.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Jonathon Jongsma <jjongsma@redhat.com>
There is some inconsistent naming of RedChannelClient methods. Some
include the word 'peer' (which normally seems to refer to RedsStream).
Remove the 'peer' terminology from those functions that are basically
RedChannelClient methods.
Acked-by: Frediano Ziglio <fziglio@redhat.com>
Following commit e8017dd366 here
are some more ifdef simplification.
For PIXEL_ID and PIXEL_DIST macros,
the ifndef LZ_PLT defines are special cases of the LZ_PLT
(#else) defines, when pix_per_byte is 1
Now do_match can accept pix_per_byte param for all different
definitions (implementations).
Signed-off-by: Uri Lublin <uril@redhat.com>
Acked-by: Fabiano Fidêncio <fidencio@redhat.com>
This is a public RedClient API that handles updating itself rather than
having the RedChannelClient poke around at the internal structure in
rec_channel_client_seamless_migration_done().
spice-server-replay is built with the same settings as tests.
Currently the tests links to a convenience spice-server library.
A convenience library is a static library build with object file
for a dynamic library.
This make all tests contain all spice-server library code and not
linking to the spice-server dynamic library (the .so).
It's not a problem for most tests however this make impossible for
spice-server-replay utility to be used with a dynamic spice-server
library (you have to recompile it including the library).
This is a pity as you could for instance compare your system
library behavior with the library you are developing.
Also if we decide to install in a future the utility for testing
we would have lot of code duplication.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Christophe Fergeau <cfergeau@redhat.com>
With my compile switches (which are mostly derived from RedHat spec
file) I'm getting this warning:
stream-test.c: In function 'sock_fd_read':
stream-test.c:66:43: warning: dereferencing type-punned pointer will
break strict-aliasing rules [-Wstrict-aliasing]
*fd = *((int *) CMSG_DATA(cmsg));
^
memcpy could decrease performance but as this is a test it's not
an issue.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Christophe Fergeau <cfergeau@redhat.com>
Make sure is possible to include any headers alone.
I used this script to check independence (run under server directory):
----
#!/bin/bash
set -e
# check not already modified
if grep -q libheaders.la Makefile.am; then
echo "Header library already prepared" >&2
exit 1
fi
add_lib() {
local hdr="$1"
hdr=${hdr%.h}
c="mao_${hdr}.c"
echo "#include \"${hdr}.h\"" > $c
echo -e "\t$c \\" >&3
}
# add library to compile all headers alones
exec 3>> Makefile.am
echo "
noinst_LTLIBRARIES += libheaders.la
libheaders_la_SOURCES = \\" >&3
for hdr in *.h; do
case $hdr in
spice-bitmap-utils.h)
add_lib $hdr
;;
spice*.h)
;;
*)
add_lib $hdr
;;
esac
done
echo -e "\t\$(NULL)" >&3
exec 3>&-
----
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Jonathon Jongsma <jjongsma@redhat.com>
Avoid having to provide a lot of empty implementations
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Jonathon Jongsma <jjongsma@redhat.com>
All RedPipeItems can be freed with red_pipe_item_unref.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Jonathon Jongsma <jjongsma@redhat.com>
The items of these pipe items were allocated staticaly inside the
StreamAgent structure. All others RedPipeItem are allocated dynamically.
This could solve possible future maintenance as the life of these
item is more easier to understand.
It's more easier to understand why reference where incremented.
It also make the StreamAgent structure a bit smaller.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Jonathon Jongsma <jjongsma@redhat.com>
Putting base as first item the default free function is fine.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Jonathon Jongsma <jjongsma@redhat.com>
Move ring_remove to the function to release this type of item.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Jonathon Jongsma <jjongsma@redhat.com>
Make macro have same prototype even if we need an extra argument.
This avoids having different calls for LZ_PLT.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Uri Lublin <uril@redhat.com>
Change from %f to %g. This allows printf to choose format based on
order of numbers.
Also increase precision making sure that number of precision is
respected, not matter the order of the number.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Pavel Grunt <pgrunt@redhat.com>
Use some utility function to show and compute statistics.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Pavel Grunt <pgrunt@redhat.com>
This regression was introduced by commit
18d3876b78
("UpgradeItem: use base PipeItem for refcounting")
This fix https://bugs.freedesktop.org/show_bug.cgi?id=95365.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Christophe Fergeau <cfergeau@redhat.com>
This doesn't cause problems at the moment, because the files that
include this file also include the other files that are needed, but just
for completeness...
Acked-by: Pavel Grunt <pgrunt@redhat.com>
This function was wrongly marked as deprecated in commit b41220b144.
Signed-off-by: Marc-André Lureau <marcandre.lureau@gmail.com>
Acked-by: Frediano Ziglio <fziglio@redhat.com>
Removing an interface cause SpiceBaseInstance->st to be set to NULL.
This pointer was then deferenced in agent code.
As SpiceBaseInstance should not be used after this call make sure
we don't keep pointers to it.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Christophe Fergeau <cfergeau@redhat.com>
This code make easier to be sure we don't have dangling pointers
resetting in the function which free the structure.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Christophe Fergeau <cfergeau@redhat.com>
The include directory is specified with the -I which is the directory
used directly by #include<>.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Pavel Grunt <pgrunt@redhat.com>
When a client disconnects remove it from the list of clients connected
to the spice char-device.
This was caused by commit 1cec1c5118
("reds: Make VDIPortState a GObject") as the lifespan of RedCharDevice
was changed.
This could be reproduced with:
- start rhel7 machine
- connect remote viewer (RV)
- RV: login
- connect ssh
- SSH: stop agent
- disconnect RV
- SSH: start agent
- connect to RV
and caused (using address sanitizer):
main_channel_handle_parsed: agent start
=================================================================
==29592==ERROR: AddressSanitizer: heap-use-after-free on address 0x60c00001cff0 at pc 0x7fa85b6e8595 bp 0x7ffde3801940 sp 0x7ffde3801930
READ of size 8 at 0x60c00001cff0 thread T0
#0 0x7fa85b6e8594 in red_client_get_main /home/freddy/work/spice-server/server/red-channel.c:2190
#1 0x7fa85b7311e6 in vdi_port_send_msg_to_client /home/freddy/work/spice-server/server/reds.c:880
#2 0x7fa85b69383e in red_char_device_send_msg_to_client /home/freddy/work/spice-server/server/char-device.c:138
#3 0x7fa85b69383e in red_char_device_send_msg_to_clients /home/freddy/work/spice-server/server/char-device.c:356
#4 0x7fa85b69383e in red_char_device_read_from_device /home/freddy/work/spice-server/server/char-device.c:403
#5 0x55a2633b81c1 (/usr/bin/qemu-system-x86_64+0x5561c1)
#6 0x55a2633afe7a (/usr/bin/qemu-system-x86_64+0x54de7a)
#7 0x55a2634cb7b1 (/usr/bin/qemu-system-x86_64+0x6697b1)
#8 0x55a2632078d0 (/usr/bin/qemu-system-x86_64+0x3a58d0)
#9 0x55a26379b2e8 (/usr/bin/qemu-system-x86_64+0x9392e8)
#10 0x55a26379a7a0 (/usr/bin/qemu-system-x86_64+0x9387a0)
#11 0x55a26313fb78 in main (/usr/bin/qemu-system-x86_64+0x2ddb78)
#12 0x7fa85a3cc57f in __libc_start_main (/lib64/libc.so.6+0x2057f)
#13 0x55a26314b0c8 (/usr/bin/qemu-system-x86_64+0x2e90c8)
0x60c00001cff0 is located 48 bytes inside of 128-byte region [0x60c00001cfc0,0x60c00001d040)
freed by thread T0 here:
#0 0x7fa869e3667a in __interceptor_free (/lib64/libasan.so.2+0x9867a)
#1 0x7fa85b6d75f7 in red_client_unref /home/freddy/work/spice-server/server/red-channel.c:2076
#2 0x7fa85b6ead74 in dispatcher_handle_single_read /home/freddy/work/spice-server/server/dispatcher.c:291
#3 0x7fa85b6ead74 in dispatcher_handle_recv_read /home/freddy/work/spice-server/server/dispatcher.c:314
#4 0x55a26379b2e8 (/usr/bin/qemu-system-x86_64+0x9392e8)
#5 0x55a26379a7a0 (/usr/bin/qemu-system-x86_64+0x9387a0)
#6 0x55a26313fb78 in main (/usr/bin/qemu-system-x86_64+0x2ddb78)
#7 0x7fa85a3cc57f in __libc_start_main (/lib64/libc.so.6+0x2057f)
previously allocated by thread T0 here:
#0 0x7fa869e36b19 in __interceptor_calloc (/lib64/libasan.so.2+0x98b19)
#1 0x7fa85b7d6858 in spice_malloc0 /home/freddy/work/spice-server/spice-common/common/mem.c:109
#2 0x7fa85b6e760c in red_client_new /home/freddy/work/spice-server/server/red-channel.c:2053
#3 0x7fa85b7449e4 in reds_handle_main_link /home/freddy/work/spice-server/server/reds.c:1762
#4 0x7fa85b7449e4 in reds_handle_link /home/freddy/work/spice-server/server/reds.c:2002
#5 0x7fa85b745d3a in reds_handle_ticket /home/freddy/work/spice-server/server/reds.c:2056
#6 0x55a26379b2e8 (/usr/bin/qemu-system-x86_64+0x9392e8)
#7 0x55a26379a7a0 (/usr/bin/qemu-system-x86_64+0x9387a0)
#8 0x55a26313fb78 in main (/usr/bin/qemu-system-x86_64+0x2ddb78)
#9 0x7fa85a3cc57f in __libc_start_main (/lib64/libc.so.6+0x2057f)
SUMMARY: AddressSanitizer: heap-use-after-free /home/freddy/work/spice-server/server/red-channel.c:2190 red_client_get_main
Shadow bytes around the buggy address:
0x0c187fffb9a0: fd fd fd fd fd fd fd fd fa fa fa fa fa fa fa fa
0x0c187fffb9b0: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
0x0c187fffb9c0: fa fa fa fa fa fa fa fa fd fd fd fd fd fd fd fd
0x0c187fffb9d0: fd fd fd fd fd fd fd fd fa fa fa fa fa fa fa fa
0x0c187fffb9e0: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
=>0x0c187fffb9f0: fa fa fa fa fa fa fa fa fd fd fd fd fd fd[fd]fd
0x0c187fffba00: fd fd fd fd fd fd fd fd fa fa fa fa fa fa fa fa
0x0c187fffba10: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
0x0c187fffba20: fa fa fa fa fa fa fa fa fd fd fd fd fd fd fd fd
0x0c187fffba30: fd fd fd fd fd fd fd fd fa fa fa fa fa fa fa fa
0x0c187fffba40: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Eduardo Lima (Etrunko) <etrunko@redhat.com>
Acked-by: Uri Lublin <uril@redhat.com>
This replaces the original mjpeg_encoder API with a VideoEncoder base
class which can be reimplemented by other encoders.
This also renames the members and enums from mjpeg_* to video_*.
Signed-off-by: Francois Gouget <fgouget@codeweavers.com>
Acked-by: Christophe Fergeau <cfergeau@redhat.com>
We may get stream reports after the stream has been closed, and even, in
extreme cases, after a new stream has started reusing the same stream
id. Neither case should cause the server to crash.
So restore dcc_handle_stream_report() to how it was before being moved
to dcc.c.
Signed-off-by: Francois Gouget <fgouget@codeweavers.com>
Acked-by: Victor Toso <victortoso@redhat.com>
Change red_channel_client_set_migration_seamless() so that it returns a
boolean which RedClient can use to update its internal count of
num_migrated_channels rather than having RedChannelClient reaching into
the internals of RedClient
This variable belongs to SpiceServerConfig rather than being a static
global variable hidden in sound.c
Acked-by: Jonathon Jongsma <jjongsma@redhat.com>
channels_info->num_of_channels is assigned, its value is not used, and
then it's assigned a different value. The first assignment can be
removed.
Acked-by: Jonathon Jongsma <jjongsma@redhat.com>
Instead of exporting 2 methods to get number of channels, and to fill
channel information, and use that from the main channel code, it's
better to do everything in one go in reds.c, and call that single method
from the main channel code.
Acked-by: Jonathon Jongsma <jjongsma@redhat.com>
This wraps/groups the various parameters that can be set by spice-server
users through the spice_server_set_xxx public API.
Acked-by: Jonathon Jongsma <jjongsma@redhat.com>
RedCharDevice implementation had to callback into reds.c in order to let
it know a char device was being destroyed. Now that RedCharDevice is a
gobject, a weak reference can be used instead allowing to remove that
coupling.
Acked-by: Jonathon Jongsma <jjongsma@redhat.com>
There was an extra RedCharDeviceMsgToClientItem type whose only
purpose was to manage a linked list of items to send. GQueue has the
same purpose as this type in addition to being generic. As the length of
the send queue is tracked, a GQueue is more appropriate than a GList and
allow to remove RedCharDevice::send_queue_size.
Acked-by: Frediano Ziglio <fziglio@redhat.com>
If the Drawable keeps a pointer to the Display channel that it is
associated with, we can unref it directly and not need to pass the
'display' parameter separately to the unref function
Acked-by: Frediano Ziglio <fziglio@redhat.com>
We want the cursor to be initialized even if there is no canvas,
especially when using a GL scanout. This solves some client warnings
when using qemu with GL scanout-only (patches under review on qemu ML).
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Acked-by: Frediano Ziglio <fziglio@redhat.com>
We can get 'reds' from the RedCharDevice accessible from the
SpiceCharDeviceInstance passed as an argument.
Acked-by: Pavel Grunt <pgrunt@redhat.com>
Acked-by: Frediano Ziglio <fziglio@redhat.com>
Internally, use the method to set the 'sin' member variable so that we
don't have to duplicate the g_object_notify() calls, and there are
consistent debug statements whenever this value is modified. This also
means that we need to handle NULL arguments to this function.
Acked-by: Frediano Ziglio <fziglio@redhat.com>
Since the type name was changed, use variable names / debug statements
that are consistent with the new name.
Acked-by: Frediano Ziglio <fziglio@redhat.com>
Since the device instance ("sin") is a gobject property, we should make
sure to notify when it changes, particularly since we do some
initialization in response to the "notify::sin" signal.
Acked-by: Frediano Ziglio <fziglio@redhat.com>
Now that all derived classes use a type deriving from PipeItem for their
RedCharDeviceMsgToClient, we can make this explicit in the
RedCharDeviceClass vfuncs, and remove the RedCharDeviceMsgToClient
typedef.
Since PipeItem is already refcounted, this allows to remove various
layers of ref/unref helpers from reds.c, and use the generic
pipe_item_{ref, unref} instead.
A user-defined callback is called when the refcount drops to 0.
Reference counting is manually coded for several classes deriving from
PipeItem, so this change will help to share this code, and allow to remove
some ref/unref virtual functions in some interfaces when we can assume
every instance derives from this base class.
Signed-off-by: Christophe Fergeau <cfergeau@redhat.com>
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Reviewed-by: Jonathon Jongsma <jjongsma@redhat.com>
These function are called on both sides of dispatcher so the
increment/decrement of the counter is done in multiple threads.
This caused the counter to not get incremented correctly and
freed the structure too early, leaving a dangling pointer in
the other thread.
This fixes https://bugzilla.redhat.com/show_bug.cgi?id=1253375.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Christophe Fergeau <cfergeau@redhat.com>
Acked-by: Jonathon Jongsma <jjongsma@redhat.com>
One more duplicate typedef, once in reds.c and another time in
reds-private.h
RedsState::agent_dev is defined in reds-private.h but only used in
reds.c, so longer term this could all be moved back to reds.c
This structure holding virtual function pointers was kept until now as a
RedCharDevice member in order to make the GObject conversion easier.
Now that all RedCharDevice children are converted to GObject, it can be
moved into RedCharDeviceClass.
This inherits from RedCharDevice. Once all char device states are
converted, we can turn the associated vfuncs into RedCharDeviceClass
vfuncs.
Signed-off-by: Christophe Fergeau <cfergeau@redhat.com>
This allows to stop using struct RedsState * rather than RedsState * in
headers which cannot include reds.h. This also allows to remove the
duplicate RedsState typedef in reds.h and reds-stream.h which is causing
issues with older gcc versions.
We can pass it a SndChannel rather than an opaque void* data pointer
which we then blindly cast.
This came to light through a -Wshadow warning as there was a local
variable 'data' in addition to the 'data' parameter.
VDIPortState and VDIReadBuf don't really need to be defined in a header
file as they are only used in reds.c
Acked-by: Jonathon Jongsma <jjongsma@redhat.com>
make the function names match the type names. So
spice_char_device_state_* becomes red_char_device_* and
spice_char_device_* also becomes red_char_device_*.
Acked-by: Frediano Ziglio <fziglio@redhat.com>
Make it consistent with the renamed RedCharDevice and the convention of
using 'Red' namespaces for internal types
Acked-by: Frediano Ziglio <fziglio@redhat.com>
This is more consistent with internal type naming convention, and it
paves the way for a new char device GObject heirarchy
Acked-by: Frediano Ziglio <fziglio@redhat.com>
Move all internal data into a private struct so that it won't be exposed
when we move SmartCardDeviceState into the header.
Signed-off-by: Christophe Fergeau <cfergeau@redhat.com>
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Jonathon Jongsma <jjongsma@redhat.com>
Create a structure to hold private data.
This helps to make patch for GObject smaller.
Signed-off-by: Christophe Fergeau <cfergeau@redhat.com>
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Christophe Fergeau <cfergeau@redhat.com>
CursorChannel and DisplayChannel was initialized half in red_worker_new
and half in red_dispatcher_init using some accessor for RedWorker
(red_worker_get_cursor_channel and red_worker_get_display_channel).
Moving directly into red_worker_new make easier to follow code path.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Christophe Fergeau <cfergeau@redhat.com>
There is no need callbacks knows about internal QXLState.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Christophe Fergeau <cfergeau@redhat.com>
Rename the function to channel_supports_multiple_clients() as
channel_is_secondary() is unclear and was coded to return the opposite
of what was originally intended.
Also there are few channel types and whether they support multiple
clients is totally static so we might as well delegate the check to
the compiler.
Signed-off-by: Francois Gouget <fgouget@codeweavers.com>
No need to have callback registered internally no static
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Victor Toso <victortoso@redhat.com>
Initialize global images at load time:
- make sure these stuff are initialized without using runtime
resources;
- make sure stuff are initialize really earlier.
Do not use atexit function but a destructor.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Pavel Grunt <pgrunt@redhat.com>
QXLWorker is the old interface now completely deprecated.
Remove the strict dependency of having it as a base class.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Christophe Fergeau <cfergeau@redhat.com>
All other messages (even empty ones) have a structure defined.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Christophe Fergeau <cfergeau@redhat.com>
This should be the final piece of removing the global reds variable. We
still need a global variable to clean up during the atexit() function,
but we use a GList of servers (even though we technically don't support
multiple servers in the same process yet).
Acked-by: Fabiano Fidêncio <fidencio@redhat.com>
Acked-by: Frediano Ziglio <fziglio@redhat.com>
Add helper functions wrapping calls to the virtual functions
defined in SpiceCharDeviceCallbacks.
Acked-by: Pavel Grunt <pgrunt@redhat.com>
Acked-by: Frediano Ziglio <fziglio@redhat.com>
This makes it easier to move the VDIPort API to a different file, and
make it as self-contained as possible.
Acked-by: Frediano Ziglio <fziglio@redhat.com>
AgentMsgFilter needs to know whether monitors config messages need to be
filtered or not. This used to be done from within
agent_msg_filter_config() using the global RedsState, but this got more
tricky as it was removed.
A first attempt a1e62fa5ae caused crashes on qemu startup with
"qemu-system-x86_64 -spice port=5900" (without -vga qxl). A second
attempt added a RedsState* argument to agent_msg_filter_config() which
in my opinion is not really nice from a layering point of view.
This new attempt makes sure AgentMsgFilter state is correct when the
filter is set to stop discarding all data, which allows to remove direct
use of RedsState from within AgentMsgFilter.
Acked-by: Frediano Ziglio <fziglio@redhat.com>
Passing Reds into agent-msg-filter.[ch] isn't the right thing to do from
a layering point of view.
This reverts commit a1e62fa5ae.
Acked-by: Frediano Ziglio <fziglio@redhat.com>
It's always called at the same time as red_channel_register_client_cbs()
and the data is used by the callbacks, so we can pass the data as an
argument to red_channel_register_client_cbs().
Acked-by: Jonathon Jongsma <jjongsma@redhat.com>
Add red_qxl_ methods wrapping the QXLInterface vfuncs. This allows to
remove most of the qxl_get_interface() use outside of red-qxl.c
Acked-by: Frediano Ziglio <fziglio@redhat.com>
This seems to make more sense this way, QXLInstance is the 'main' object
with QXLState being its private data. External users then use QXLInstance
rather than passing a pointer to the private data to red-qxl.h methods.
Acked-by: Frediano Ziglio <fziglio@redhat.com>
Note that the commands are executed by spice-server.
The "skip" is only done on the "sleep" part of the
"slow" command-line option.
This is helpful to run quickly through uninsteresting commands
in a beginning of a recorded file and going slowly when
interesting parts appear
Acked-by: Frediano Ziglio <fziglio@redhat.com>
This public API is no longer needed as the keepalive interval does not
need to be configurable.
This API was present in the 0.13.0 release, but was never added to a
stable release, in my opinion it's still acceptable to remove it without
changing soname.
APDUBufSize is only used within smartcard.c, no need to expose it in
smartcard.h
Acked-by: Pavel Grunt <pgrunt@redhat.com>
Acked-by: Frediano Ziglio <fziglio@redhat.com>
The RedChannel argument is not used by pipe_item_init. Removing it
will make code simpler in places where we don't have a RedChannel
directly available.
This is acting on a PipeItem object so correct name is pipe_item_init.
Acked-by: Pavel Grunt <pgrunt@redhat.com>
The code was introducing an intermediate RedsMigWaitDisconnectClient type to
hold linked list elements, resulting in a memory handling behaviour very
similar to a GList. Using GList directly makes the code shorter and more
readable.
Acked-by: Frediano Ziglio <fziglio@redhat.com>
The code was introducing an intermediate SpiceCharDevStateItem type to
hold linked list elements, resulting in a memory handling behaviour very
similar to a GList. Using GList directly makes the code shorter and more
readable.
Acked-by: Frediano Ziglio <fziglio@redhat.com>
st field in QXLInstance was not checked for NULL before
initialisation.
The additional check make Xspice crash during startup.
Reported-by: Francois Gouget <fgouget@codeweavers.com>
Acked-by: Christophe Fergeau <cfergeau@redhat.com>
Commit e9ed125d introduced a dead-lock regression by taking twice the
same lock recursively. The previous code checked if a dmabuf was set
without taking the lock, for queuing scanout messages. Since the message
is being processed later on, it make sense to queue and delay until it
is sent to check if there is a scanout.
backtrace:
#0 red_qxl_get_gl_scanout (qxl_state=0x5555582373c0) at red-qxl.c:828
#1 0x00007fffec1ae654 in marshall_gl_scanout (rcc=0x7fffda6a7010,
#m=0x7fff44025e60, item=0x7fff440958a0) at dcc-send.c:2310
#2 0x00007fffec1aec7b in dcc_send_item (dcc=0x7fffda6a7010,
#pipe_item=0x7fff440958a0) at dcc-send.c:2441
#3 0x00007fffec1730f6 in send_item (rcc=0x7fffda6a7010,
#item=0x7fff440958a0) at display-channel.c:1963
#4 0x00007fffec1504c3 in
#red_channel_client_send_item (rcc=0x7fffda6a7010, item=0x7fff440958a0)
#at red-channel.c:578
#5 0x00007fffec152d98 in red_channel_client_push (rcc=0x7fffda6a7010)
#at red-channel.c:1365
#6 0x00007fffec1a387e in dcc_push_monitors_config (dcc=0x7fffda6a7010)
#at dcc.c:563
#7 0x00007fffec1a3489 in dcc_start (dcc=0x7fffda6a7010) at dcc.c:475
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Acked-by: Frediano Ziglio <fziglio@redhat.com>
Get the server variable from the QXLState instead of using the
global variable
Acked-by: Fabiano Fidêncio <fidencio@redhat.com>
Acked-by: Frediano Ziglio <fziglio@redhat.com>
Remove use of global 'reds' variable from QXLState functions.
Instead store the owning RedsState variable inside the QXLState
struct and use that when necessary.
Acked-by: Fabiano Fidêncio <fidencio@redhat.com>
Acked-by: Frediano Ziglio <fziglio@redhat.com>
Considering that:
- QXLState is the state of QXLInstance implementation;
- RedDispatcher is the implementation of QXL;
- qif (QXLInterface*) field can be computed really easy from QXLInstance;
- most of its state is private.
Make all structure private and use QXLState instead of RedDispatcher.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Jonathon Jongsma <jjongsma@redhat.com>
Acked-by: Christophe Fergeau <cfergeau@redhat.com>
RedDispatcher is basically implementing QXLInstance.
After some internal discussion we decided to use QXLState structure
and red_qxl_ as function prefix.
This is the first of 3 patches that rename functions, structure
and files.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Jonathon Jongsma <jjongsma@redhat.com>
Avoid to include headers in cursor-channel.h which are only
used by cursor-channel.c
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Christophe Fergeau <cfergeau@redhat.com>
These methods wrap the RedsCoreInterface::watch_add,
RedsCoreInterface::watch_remove and RedsCoreInterface::watch_update_mask
vfuncs.
Acked-by: Frediano Ziglio <fziglio@redhat.com>
Apparently, after using g_option_context_parse with G_OPTION_REMAINING
argv is modified and should not be used.
This patch uses "file" instead of "argv" and makes sure
file is freed later.
No free is called upon error - exit takes care of it.
It has the same lifetime as the corresponding structure so this
simplifies keeping track of it.
Signed-off-by: Francois Gouget <fgouget@codeweavers.com>
Acked-by: Christophe Fergeau <cfergeau@redhat.com>
Acked-by: Frediano Ziglio <fziglio@redhat.com>
The first part updates the .gitignore file in the root directory
because the file is obviously generated by automake but poison
our working tree.
The second part updates the .gitignore under server/tests/
directory because since 0db1137d we have a noinst test library
libtest.a. However, like in previous case, git should never track
this file.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Acked-by: Frediano Ziglio <fziglio@redhat.com>
Was possible to have ping_timer_cb called with a NULL pointer.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Jonathon Jongsma <jjongsma@redhat.com>
Patch 1f21008060 ("Remove use of global
'reds' from AgentMsgFilter") introduced a regression. This because
QXLInterface->client_monitors_config was called before returning
from spice_add_interface. Some client of spice-server expect the
spice_add_interface already returned and some state change was done
before client_monitors_config was called.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Pavel Grunt <pgrunt@redhat.com>
Remove version_string variable.
Was never changed and used in a single place.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Pavel Grunt <pgrunt@redhat.com>
Rename this struct to make it clear that it's only the base class for
graphics channels (e.g. display and cursor), not all channels.
Also renamed CommonChannelClient to CommonGraphicsChannelClient.
Signed-off-by: Jonathon Jongsma <jjongsma@redhat.com>
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Pavel Grunt <pgrunt@redhat.com>
Rules are now:
Compression type:
off -> uncompressed
quic -> jpeg if possible else quic else off
lz -> lz if possible else off
glz -> glz if possible else lz else off
auto_lz -> lz if possible else jpeg else quic else off
auto_glz -> glz if possible else lz else jpeg else quic else off
lz4 -> lz4 if possible else lz else off
jpeg is used only when jpeg-wan-compression allows it
Acked-by: Frediano Ziglio <fziglio@redhat.com>
The structure is strictly used by the parser only, no reason to make it
public.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Pavel Grunt <pgrunt@redhat.com>
Was not used by CursorChannelClient but only by DisplayChannelClient.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Pavel Grunt <pgrunt@redhat.com>
The 'port' argument can be determined from VDIPortState, so no need to
pass both (through RedsState) to vdi_port_read_buf_process().
Acked-by: Frediano Ziglio <fziglio@redhat.com>
Pass RedsState variable to snd_attach_(playback|record) and get a
reference to this variable when needed by various functions.
Acked-by: Fabiano Fidêncio <fidencio@redhat.com>
Requires changing a bunch of internal API to take MainDispatcher
arguments, etc. The main dispatcher object is now owned by RedsState,
since that is the object that previously created (initialized) it.
Acked-by: Fabiano Fidêncio <fidencio@redhat.com>
Allows us to remove use of global 'reds' variable from reds-stream.c.
Requires changing the RedsStream constructor to accept a RedsState arg.
Acked-by: Fabiano Fidêncio <fidencio@redhat.com>
Since these are server-level variables, move them into RedsState.
However, num_active_workers was removed because:
- each dispatcher always has 1 active worker, so we can determine the
number of active workers by counting the dispatchers
- it was never actually set correctly. Even if there was more than one
worker, this variable was always only set to either 0 or 1.
This change required moving a bunch of helper code into RedsState as
well, an providing some RedDispatcher interfaces to access dispatcher
information from RedsState.
Signed-off-by: Jonathon Jongsma <jjongsma@redhat.com>
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Fabiano Fidêncio <fidencio@redhat.com>
Instead of using list in RedDispatcher (which is going to be removed)
use the one in RedsState.
Signed-off-by: Jonathon Jongsma <jjongsma@redhat.com>
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Fabiano Fidêncio <fidencio@redhat.com>
This duplicate the other list which will be removed
Signed-off-by: Jonathon Jongsma <jjongsma@redhat.com>
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Fabiano Fidêncio <fidencio@redhat.com>
They are now carried in the appropriate command through
QXLReleaseInfoExt, so we don't need to pass them around explicitly.
Acked-by: Frediano Ziglio <fziglio@redhat.com>
Now it no longer needs external state in order to destroy the
RedDrawable instance when needed, so we can remove this from the
prototype.
Acked-by: Frediano Ziglio <fziglio@redhat.com>
Storing a QXLReleaseInfoExt rather than a QXLReleaseInfo in RedDrawable
gives us a place to store group_id for free. Since we are building a
QXLReleaseInfoExt from QXLReleaseInfo and group_id when destroying a
RedDrawable instance, this is a move in the right direction.
Acked-by: Frediano Ziglio <fziglio@redhat.com>
It's only used in a few debug printfs. If we want these stats, we'll
have to find a better way than forcing a dependency on a high-level
class in a lower-level _unref method just to maintain the stats.
Acked-by: Frediano Ziglio <fziglio@redhat.com>
Was causing sporadic crashes.
Also cause compatibility problems with RHEL 6.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Christophe Fergeau <cfergeau@redhat.com>
Check that cancelling a timer the timer callback is not called.
This can happen in latency code (red-channel.c).
In red_channel_client_cancel_ping_timer latency timer is cancelled and
state is set to PING_STATE_NONE however if timer was already active what
happens is that the red_channel_client_ping_timer is called and the line
spice_assert(rcc->latency_monitor.state == PING_STATE_TIMER);
is triggered causing spice-server to abort.
This happens as GLib loop add all active sources to an array but if the
timer is deactivated before the event is dispatched the event will be
dispatched unless the source is destroyed.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Christophe Fergeau <cfergeau@redhat.com>
Add RedsState arg to main_channel_new(), and use the 'reds' property
that is stored in the base RedChannel struct rather than the global
'reds' variable.
Acked-by: Frediano Ziglio <fziglio@redhat.com>
These automatic variable are used just inside the function.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Jonathon Jongsma <jjongsma@redhat.com>
CommonChannel does not need to know about RedWorker.
This reduce a bit dependencies between objects.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Jonathon Jongsma <jjongsma@redhat.com>
The only usage of this ring was to have a message when there was no
commands on the list.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Jonathon Jongsma <jjongsma@redhat.com>
Add a new 'state' property to VDIReadBuf so that we can refer back to
the VDIPortState struct from the readbuf functions.
Acked-by: Frediano Ziglio <fziglio@redhat.com>
Store a reference to the server in the SpiceCharDeviceState struct and
use that rather than the global 'reds' variable
Acked-by: Frediano Ziglio <fziglio@redhat.com>
This allows us to use local 'reds' variables in all of the various async
callbacks rather than using the global 'reds' variable.
Acked-by: Frediano Ziglio <fziglio@redhat.com>
Rather than relying on a global 'reds' variable, we can pass the needed
instance through the callback user data.
Acked-by: Frediano Ziglio <fziglio@redhat.com>
Commit 3a66b75 changed reds_accept_ssl_connection() to expect a RedState
instance when its called, but the core->watch_add() which is calling it
was not changed accordingly. This causes a crash when connecting through
SSL.
Acked-by: Frediano Ziglio <fziglio@redhat.com>
When a client is done with drawing and sends
SPICE_MSGC_DISPLAY_GL_DRAW_DONE, or when it ends, update the number of
async counts.
Signed-off-by: Marc-André Lureau <marcandre.lureau@gmail.com>
[reduce critical message to a warning; do not reset gl_draw_ongoing
- Frediano Ziglio]
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Create an async, and marshall the GL_DRAW message. Count number of
clients, and wait until gl_draw_async_count is 0 to complete the async.
The count is going to be updated in the following patch when the client
is done with the draw.
Signed-off-by: Marc-André Lureau <marcandre.lureau@gmail.com>
[removed unused sent field; move gl_draw_async_count to DisplayChannel
- Frediano Ziglio]
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Go through dispatcher and marshall scanout message. Since the marshaller
and the QXL state are manipulated from different threads, add a mutex to
protect the current scanout.
Signed-off-by: Marc-André Lureau <marcandre.lureau@gmail.com>
- spice_qxl_gl_scanout() to take the current scanout
- spice_qxl_gl_draw_async() to draw the scanout, is like other Spice async
functions, it takes a cookie and will return in the
QXLInterface.async_complete()
Two new fields are also added to QXLState, in order to save the current
scanout, and the pending async.
A scanout can't be updated if there are pending draw atm. Discarding
outdated draws is left as a future improvement to allow updating the
scanout without waiting for draw async to be done.
Signed-off-by: Marc-André Lureau <marcandre.lureau@gmail.com>
[make QXL function names more coherent - Frediano Ziglio]
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Instead of using CPU time use a timer depending on real times.
Currently that time in the record log is not used.
However if we want to reproduce problems with stream would be useful
to have real times instead.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Pavel Grunt <pgrunt@redhat.com>
Now that processing is correctly restored there is no need to keep
polling to avoid main loop hangs. Reduce the polling count to 1
(just try once).
This reduce cpu usage if guests are mainly idle.
If you consider 100 guests waiting to login with cursor blinking
and considering the polling was done 200 times every 10ms (maximum)
just the cursor blinking was causing 10100 loop iterations per second
while now only 200 are needed (considering cursor blinking every
second).
Signed-by: Frediano Ziglio <figlio@redhat.com>
Acked-by: Jonathon Jongsma <jjongsma@redhat.com>
Make sure we process commands after we can send data to client.
If during processing we detected that there was too much data in the
clients queues the processing of commands just stop till the next
iteration.
However if all data are pushed in a single iteration of the loop
and commands were already processed there was the (remote) possibility
that the loop hangs till a separate event (like a screen resize on
client window) arrive.
I manage to reproduce and after half an hour no events arrived.
This patch detect that processing was stuck and now we can process new
commands and force a new iteration.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Jonathon Jongsma <jjongsma@redhat.com>
The req_cmd_notification callback is called by spice-server when it
has processed all commands and wants to be notified (by a wakeup) that
new commands have been appended to the command queue.
Replay utility tries to fill the commands when it detects that
spice-server is trying to read commands but there are no more commands.
However, new commands are appended in a separate thread so if the main
red worker loop on spice-server is really tight this request can
happen.
Avoid printing any message on this condition, message will be appended
and loop woken up when replay code can do it.
Signed-by: Frediano Ziglio <figlio@redhat.com>
Acked-by: Jonathon Jongsma <jjongsma@redhat.com>
During every iteration of the main worker loop, outgoing data was pushed to
the client. However, there was no guarantee that the loop would be woken up
in every situation. So there were some conditions where the loop would stop
iterating until a new event was sent.
Currently, the events that can wake up the main worker loop include:
- data from dispatcher (including wakeups from the guest)
- data from clients
- timeouts on a stream
- other timeouts
- polling
This patch adds a new wakeup event: when we have items that are queued to
be sent to a client, we set up a watch event for writing data to the
client. If no items are waiting to be sent, this watch will be disabled.
This allows us to remove the explicit push from the main worker loop.
This has some advantages:
- it could lower latency as we don't have to wait for a polling timeout.
From my experiments using a tight loop (so not really the ideal
condition to see the improvements) the total time was reduced by 2-3%)
- helps reduce the possibility of hanging loops
- avoids having to scan all clients to detect which one can accept data.
Signed-by: Frediano Ziglio <figlio@redhat.com>
Acked-by: Jonathon Jongsma <jjongsma@redhat.com>
This patch use old code to implement timer events.
The new version use some function from GLib 2.34 however some systems
(like RHEL 6) have former GLib version (RHEL 6 has GLib 2.28 installed)
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Christophe Fergeau <cfergeau@redhat.com>
Since this is public API, we can't easily change the signature of the
function to take a RedsState argument, so instead we apply a hack and
store the reds argument inside the device state struct when the
interface is added, and retrieve it for use later when it is removed.
Acked-by: Pavel Grunt <pgrunt@redhat.com>
Send the fd associated to the last message sent.
Signed-off-by: Marc-André Lureau <marcandre.lureau@gmail.com>
Acked-by: Frediano Ziglio <fziglio@redhat.com>
The default rule being "all", it builds noinst_PROGRAMS but not
check_PROGRAMS. Let's build all the tests by default.
Signed-off-by: Marc-André Lureau <marcandre.lureau@gmail.com>
Acked-by: Frediano Ziglio <fziglio@redhat.com>
Was used to just assure there was at least one renderer in the list.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Pavel Grunt <pgrunt@redhat.com>
Use the glib mainloop instead of writing our own. The glib loop is both
cleaner to use and is more extensible. It is also very mature and
reduces the maintenance burden on the spice server.
Signed-off-by: Marc-André Lureau <marcandre.lureau@gmail.com>
Signed-off-by: Jonathon Jongsma <jjongsma@redhat.com>
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Jonathon Jongsma <jjongsma@redhat.com>
Make the RedsState object own an InputsChannel object rather than
having a global inputs channel. This means changing a lot of
inputs-related API to take an InputsChannel* argument and moving the
keyboard, mouse, and tablet objects into the InputsChannel object.
Acked-by: Frediano Ziglio <fziglio@redhat.com>
red_channel_max_pipe_size returns 0 if no client (channel disconnected)
no need to check if cursor_channel/display_channel are NULL or
connected.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Jonathon Jongsma <jjongsma at redhat.com>
Calling cursor_channel_disconnect does not free cursor_display
so this causes a leak.
Is the only code where this pointer is reset preventing any
further cursor channel connection. If a client is lazy reading
cursor data during the flush connection is closed and further clients
won't be able to use the cursor.
This also prevents future use of a NULL pointer.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Jonathon Jongsma <jjongsma at redhat.com>
Use a custom GSource.
This to avoid having to allocate a timer all the time we add one.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Christophe Fergeau <cfergeau@redhat.com>
Send wakeups only when a command is available.
This emulate better what a guest driver should do (append the command
to the ring and then signal).
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Pavel Grunt <pgrunt@redhat.com>
This increase code reuse and make Glib integration more straight forward.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Christophe Fergeau <cfergeau@redhat.com>
This is mainly question of style.
Instead of repeating same conversion use the variable we set at the
beginning of the function.
Note also that I used same name to make the two functions more
similar.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Pavel Grunt <pgrunt@redhat.com>
All checks for full channel pipes have to be consistents
so there is no point in passing as a parameter.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Pavel Grunt <pgrunt@redhat.com>
If the creator was not able to produce the item, no need to call
pipe_add().
Signed-off-by: Marc-André Lureau <marcandre.lureau@gmail.com>
Acked-by: Frediano Ziglio <fziglio@redhat>
The replay file should start with a header such as
SPICE_REPLAY 1
Instead of soldiering on if we don't encounter this header, print a
warning and return NULL. Also exit with a failure if spice_replay_new()
returns a NULL object in main.
Acked-by: Pavel Grunt <pgrunt@redhat.com>
In preparation for getting rid of the global 'reds' variable, we need to
pass the RedsState variable to all functions where it is needed. For now
the callers just pass in the global reds variable.
Functions changed:
- reds_mig_fill_wait_disconnect;
- reds_mig_cleanup_wait_disconnect;
- reds_mig_remove_wait_disconnect_client;
- reds_migrate_channels_seamless;
- reds_mig_finished;
- reds_mig_switch;
- reds_enable_mm_time;
- reds_disable_mm_time;
- attach_to_red_agent;
- reds_char_device_add_state;
- reds_char_device_remove_state;
- reds_on_char_device_state_destroy;
- spice_server_char_device_remove_interface;
- migrate_timeout.
Acked-by: Frediano Ziglio <fziglio@redhat.com>
Since SpiceCoreInterfaceInternal is a private data structure, we can
extend it as we see fit without breaking ABI. In particular, adding a
GMainContext member to it allows us to remove the need for
the event loop template which is currently included in the
basic_event_loop.c test file.
Acked-by: Frediano Ziglio <fziglio@redhat.com>
They call the functions provided by event_loop_core, but with a NULL
SpiceCoreInterfaceInternal parameter. It makes more sense to pass
event_loop_core rather than NULL.
This will allow to pass the GMainContext to be used through
SpiceCoreInterfaceInternal rather than through a template parameter.
Acked-by: Frediano Ziglio <fziglio@redhat.com>
In preparation for getting rid of the global 'reds' variable, we need to
pass the RedsState variable to all functions where it is needed. For now
the callers just pass in the global reds variable.
Functions changed:
- reds_link_mig_target_channels;
- reds_on_migrate_dst_set_seamless;
- reds_on_client_seamless_migrate_complete;
- reds_on_client_semi_seamless_migrate_complete;
- reds_handle_other_links;
- reds_handle_link;
- reds_send_mm_time;
- reds_set_client_mm_time_latency;
- reds_init_net;
- do_spice_init;
- reds_init_ssl;
- on_activating_ticketing;
- reds_mig_release to take RedsState arg
- reds_mig_started.
Acked-by: Pavel Grunt <pgrunt@redhat.com>
In preparation for getting rid of the global 'reds' variable, we need to
pass the RedsState variable to all functions where it is needed. For now
the callers just pass in the global reds variable.
Functions changed:
- reds_on_main_migrate_connected;
- reds_on_main_mouse_mode_request;
- reds_on_main_channel_migrate;
- reds_marshall_migrate_data;
- reds_agent_state_restore;
- reds_handle_migrate_data;
- reds_send_link_ack;
- reds_mig_target_client_add;
- reds_mig_target_client_find;
- reds_mig_target_client_free;
- reds_mig_target_client_disconnect_all;
- reds_find_client;
- reds_get_client;
- reds_handle_main_link;
- reds_set_client_mouse_allowed.
Acked-by: Frediano Ziglio <fziglio@redhat.com>
This fixes a crash if red_channel_client disconnect is called
handling a message.
This can happen for instance while handling SPICE_MSGC_ACK which calls
red_channel_client_push which tries to detect write errors while writing
to a socket (for instance socket disconnection).
Messages are read in a loop and red_channel_client_disconnect would
cause rcc->stream to be NULL which will result in a use-after-free
problem (stream in red_peer_handle_incoming will use cached stream value).
Signed-off-by: Marc-André Lureau <marcandre.lureau@gmail.com>
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Jonathon Jongsma <jjongsma@redhat.com>
This could happen for instance if a given timer remove all clients
which have associated timers.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Jonathon Jongsma <jjongsma@redhat.com>
Make sure we don't handle event reserved to other loop contexts.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Jonathon Jongsma <jjongsma@redhat.com>
spice_warn_if_fail() is doing the same thing except for the inverted
condition. spice_warn_if() is being removed from spice-common to avoid
having potentially confusing redundancy.
More consistent with glib naming conventions. Also make the function
static since it's not used outside of this source file.
Acked-by: Pavel Grunt <pgrunt@redhat.com>
In preparation for getting rid of the global 'reds' variable, we need to
pass the RedsState variable to all functions where it is needed. For now
the callers just pass in the global reds variable.
Functions changed:
- vdi_port_read_buf_process;
- vdi_port_read_buf_get;
- vdi_port_read_buf_unref;
- reds_handle_agent_mouse_event;
- reds_num_of_channels;
- reds_num_of_clients;
- reds_fill_channels;
- reds_on_main_agent_start;
- reds_get_agent_data_buffer;
- reds_release_agent_data_buffer;
- reds_client_monitors_config_cleanup;
- red_on_main_agent_data.
Acked-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Pavel Grunt <pgrunt@redhat.com>
This make happy address sanitizer during make check.
Otherwise memory leak detector can keep in and make tests fails.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Pavel Grunt <pgrunt@redhat.com>
This allows us to access the RedsState variable non-globally without
changing the signature of the callback functions.
Acked-by: Pavel Grunt <pgrunt@redhat.com>
In preparation for getting rid of the global 'reds' variable, we need to
pass the RedsState variable to all functions where it is needed. For now
the callers just pass in the global reds variable.
Functions changed:
- reds_register_channel;
- reds_unregister_channel;
- reds_get_mouse_mode;
- reds_set_mouse_mode;
- reds_update_mouse_mode;
- reds_agent_remove;
- reds_find_channel;
- reds_mig_cleanup;
- reds_reset_vdp;
- reds_main_channel_connected;
- reds_client_disconnect;
- reds_disconnect;
- reds_mig_disconnect.
Acked-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Pavel Grunt <pgrunt@redhat.com>
This allows it to be accessed from other files. This is a temporary step
toward getting rid of the global-ness of this variable, and it allows us
to update the function signature bit-by-bit.
Acked-by: Frediano Ziglio <fziglio@redhat.com>
Check that two consecutive msgfd are read back from two different reads.
Signed-off-by: Marc-André Lureau <marcandre.lureau@gmail.com>
Acked-by: Frediano Ziglio <fziglio@redhat.com>
These function report memory allocation errors.
spice_malloc0 also reset memory after allocation.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Victor Toso <victortoso@redhat.com>
Group the test utility in a library, to avoid repeating the same
sources. In this case, automake already figues out what the source of
the programs to build is.
Signed-off-by: Marc-André Lureau <marcandre.lureau@gmail.com>
Acked-by: Frediano Ziglio <fziglio@redhat.com>
This commit reworks a bit the management of RedCompressBuf so that
compress_buf_new/compress_buf_free become unneeded.
Since d25d6ca0 and the introduction of encoder_data_reset,
compress_buf_free is already unused outside of dcc-encoders.c and could
be static. This in turn makes compress_buf_new a bit odd as the matching
destructor is never used in dcc.c.
This commit introduces an encoder_data_init() method which is hiding
the initialization of the EncoderData structure from the dcc.c code,
allowing to get rid of compress_buf_new() calls from dcc.c code.
It also uses this as an opportunity to stop using GSlice for
RedCompressBuf.
Acked-by: Frediano Ziglio <fziglio@redhat.com>
A new function to send fd with unix socket anciliary data.
Signed-off-by: Marc-André Lureau <marcandre.lureau@gmail.com>
Acked-by: Frediano Ziglio <fziglio@redhat.com>
This allow tests programs to link with statically built library to access all symbols
Signed-off-by: Marc-André Lureau <marcandre.lureau@gmail.com>
Acked-by: Frediano Ziglio <fziglio@redhat.com>
When redirecting a USB webcam over a slow link, it's currently possible
to hit an assertion in spice-server by running cheese (application using
the webcam), killing the client with ctrl+c and then restarting the
client:
qemu-kvm: spicevmc.c:324: spicevmc_red_channel_alloc_msg_rcv_buf:
Assertion `!state->recv_from_client_buf' failed.
This happens when red_peer_handle_incoming tries to allocate memory for
a message using spicevmc:
handler->msg = handler->cb->alloc_msg_buf(handler->opaque, msg_type,
msg_size);
red_peer_handle_incoming() is called when there is client data to be
read, and does
- call alloc_msg_buf() to allocate memory for the message
- read the message
- if the read was partial, return early, the main loop will call again
red_peer_handle_incoming() when there is more data available for that
channel
- parse the message
- call release_msg_buf() to free the message
For channels based on spicevmc (usbredir and port), alloc_msg_buf()
stores message data in SpiceVmcState::recv_from_client_buf and before
allocating new memory, it asserts that it's NULL.
This is what causes this crash in the following scenario:
- SpiceVmc::alloc_msg_buf() is called and allocates memory for a new
message in SpiceVmcState::recv_from_client_buf
- red_peer_handle_incoming() returns early as all the spicevmc message
data hasn't been received yet
- the client gets killed
- the main channel notices the disconnect and calls
main_dispatcher_client_disconnect() which will disconnect all the
channels
- SpiceVmc::on_disconnect is called
- after the new client connects, SpiceVmc::alloc_msg_buf() is called,
notices that SpiceVmcState::recv_from_client_buf is already set, and
asserts()
This commit makes sure the partial SpiceVmcState::recv_from_client_buf
data is cleared on disconnect so that the assert does not trigger.
This fixes https://bugzilla.redhat.com/show_bug.cgi?id=1264113
When COMPRESS_STAT is not set, and RED_WORKER_STAT is set,
stat_time() will be a no-op, but stat_start_time_init() will try to use
stat_info_t::clock. This causes a compile warning on 32 bit arches (not
sure why not on 64 bit builds), as well as an error from valgrind.
Since stat_time() and stat_compress_time() are both doing the same work,
this commit makes them the same function, which ensures
stat_info_t::clock will be set and stat_start_time_init() can be used
regardless of the _init() method which is called.
This avoids compilation errors with -Werror on 32 bit systems as the
pointer size differs from that of a QXLPHYSICAL.
Signed-off-by: Francois Gouget <fgouget@codeweavers.com>
This avoids a compilation error with -Werror on 32 bit systems as the
pointer size differs from that of an uint64_t.
Signed-off-by: Francois Gouget <fgouget@codeweavers.com>
Now we can use the iface parameter to distinguish the context instead
of doing strange assumption on opaque and its state.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Christophe Fergeau <cfergeau@redhat.com>
This patch and previous ones want to solve the problem of not having a
context in SpiceCoreInterface. SpiceCoreInterface defines a set of
callbacks to handle events in spice-server. These callbacks allow to
handle timers, watch for file descriptors and send channel events.
All these callbacks do not accept a context (usually in C passed as a
void* parameter) so it is hard for them to differentiate the interface
specified.
Unfortunately this structure is used even internally from different
contexts for instance every RedWorker thread has a different context. To
solve this issue some workarounds are used. Currently for timers a variable
depending on the current thread is used while for watches the opaque
parameter to pass to the event callback is used as it currently points just
to RedChannelClient structure. This however imposes some implicit
maintainance problem in the future. What happens for instance if for some
reason a timer is registered during worker initialization, run in another
thread? What if we decide to register a file descriptor callback for
something not a RedChannelClient? Could be that the program will run
without any issue till some bytes change and weird things could happen.
The implementation of this solution is done implementing an internal "core"
interface that has context specific and use it to differentiate the
context instead of relying on some other, hard to maintain, detail. Then an
adapter structure (name inpired to the adapter pattern) will provide the
internal core interface using the external, public, definition (in the
future this technique can be used to extend the external interface without
breaking the ABI).
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Christophe Fergeau <cfergeau@redhat.com>
Add wrapper functions for SpiceCoreInterface in order to present
a SpiceCoreInterfaceInternal. These functions just expect
SpiceCoreInterfaceInternal API and forward request to
SpiceCoreInterface.
This allows to change ABI details of internal one.
See comments in "channel: add interface parameters to
SpiceCoreInterfaceInternal" patch.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Christophe Fergeau <cfergeau@redhat.com>
Define an internal structure that matches 100% the ABI of the public one.
The structure will be changed by following patches.
See comments in "channel: add interface parameters to
SpiceCoreInterfaceInternal" patch.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Christophe Fergeau <cfergeau@redhat.com>
Use CLOCK_THREAD_CPUTIME_ID instead of getting the clock
with pthread_getcpuclockid.
This avoids to call red_worker_get_clockid. This function returns
uninitialized value at the time DisplayChannel is built resulting in setting
statistics to CLOCK_REALTIME (which is 0) instead to cpu time as expected.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Christophe Fergeau <cfergeau@redhat.com>
Client can always send report even if a stream is not available.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Christophe Fergeau <cfergeau@redhat.com>
Instead of returning 0 which could be a valid value returns an invalid
one and check on the caller.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Christophe Fergeau <cfergeau@redhat.com>
For zlib+glz compression image if first compressed with glz then the
resulting buffer is compressed again with zlib then the buffer from
zlib is returned to the caller.
However the temporary glz buffer was not freed resulting in a memory
leak.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Christophe Fergeau <cfergeau@redhat.com>
As reported in https://bugs.freedesktop.org/show_bug.cgi?id=93520, the
build from git is failing in Archlinux systems with undefined
references to glib symbols.
This patch fixes the problem by simply reordering the order libraries
will be linked. Also, removes duplicate $(GLIB_LIBS) variable.
Signed-off-by: Eduardo Lima (Etrunko) <etrunko@redhat.com>
Acked-by: Frediano Ziglio <fziglio@redhat.com>
Don't disconnect the display channel, when unsupported compression is
requested from the client. Not changing the compression is enough.
https://bugs.freedesktop.org/show_bug.cgi?id=92821
Acked-by: Victor Toso <victortoso@redhat.com>
Acked-by: Frediano Ziglio <fziglio@redhat.com>
The size_t definition is different between 32 and 64 bit systems so that
neither '%u' nor '%lu' work for both. '%zu' should be used instead.
Signed-off-by: Francois Gouget <fgouget@codeweavers.com>
Acked-by: Jonathon Jongsma <jjongsma@redhat.com>
The corresponding code has been moved elsewhere during the refactoring.
Signed-off-by: Francois Gouget <fgouget@codeweavers.com>
Acked-by: Jonathon Jongsma <jjongsma@redhat.com>
Some integer type definitions are different between 32 and 64 bit
systems which causes problems in printf. The PRI macros automatically
provide the printf format appropriate for the system.
Signed-off-by: Francois Gouget <fgouget@codeweavers.com>
Acked-by: Jonathon Jongsma <jjongsma@redhat.com>
For coherency use COMMON_BASE macro instead of including single
files.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Victor Toso <victortoso@redhat.com>
Do not free memory allocated with C functions (like calloc) using g_free;
although this is possible with default Glib allocator this is not safe.
Also use consistent allocation functions. All other spice-server code
does not use Glib allocations so for coherence do not use them for
watches.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Victor Toso <victortoso@redhat.com>
Since commit febaed3, spice.h and spice-experimental.h are listed both
in libspice_server_la_HEADERS and libspice_server_la_SOURCES. Since we
want these headers to be installed, we can remove them from _SOURCES.
Signed-off-by: Christophe Fergeau <cfergeau@redhat.com>
Acked-by: Frediano Ziglio <fziglio@redhat.com>
They clarify the time unit being used and simplify calculations.
Signed-off-by: Francois Gouget <fgouget@codeweavers.com>
Acked-by: Christophe Fergeau <cfergeau@redhat.com>
They clarify the time unit being used, reduce the need for casts and
simplify calculations.
Signed-off-by: Francois Gouget <fgouget@codeweavers.com>
Acked-by: Christophe Fergeau <cfergeau@redhat.com>
Given that it is used for both cursor and display, COMMON_CLIENT_TIMEOUT
seems more appropriate. Also define it only in red-worker.h.
Signed-off-by: Francois Gouget <fgouget@codeweavers.com>
Acked-by: Frediano Ziglio <fziglio@redhat.com>
With multiple cards configured you can have multiple workers running in
different thread.
With such configuration static variables not syncronized could lead
to undefined behavior.
Acked-by: Jonathon Jongsma <jjongsma@redhat.com>
The rest of code is using spice_malloc* functions, use them for
consistency.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Jonathon Jongsma <jjongsma@redhat.com>
This is a generic function not tied to the red_xxx functionality and the
new name clarifies that it returns the time in nanoseconds (unlike
g_get_monotonic_time()).
Signed-off-by: Francois Gouget <fgouget@codeweavers.com>
Acked-by: Frediano Ziglio <fziglio@redhat.com>
This way the video encoder can actually count on a real estimate when
it is initializing.
Note that the server only creates a video stream if at least 20 bitmap
'blits' of the same size and type arrive, each within a maximum time
interval from the previous one. So it was only keeping track of the
frame to frame interval. Thus to get an average frame rate over all the
20 frames it's necessary to also keep track of the first_frame_time.
Signed-off-by: Francois Gouget <fgouget@codeweavers.com>
During display_channel_handle_migrate_data the pointer is passed
to different functions which could release it making the pointer
invalid. Make sure pointer is not freed while processing.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Jonathon Jongsma <jjongsma@redhat.com>
Make clear that these funcion are just checking a condition.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Jonathon Jongsma <jjongsma@redhat.com>
Make sure code compile with and without statistics enabled (beside
printing functions).
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Jonathon Jongsma <jjongsma@redhat.com>
make sure code compile with statistics enabled or disabled.
Dummy (empty) structures and functions are used instead of preprocessor.
Also fix a problem as stat_compress_init did not initialize clock
field.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Jonathon Jongsma <jjongsma@redhat.com>
Assure stat_time_t is 64 bit on all architectures.
long is not 64 bit on 32 bit systems so use uint64_t intead.
Also avoid 32 bit overflows for such architectures.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Jonathon Jongsma <jjongsma@redhat.com>
Note that if frame_size == bytes_per_sec == 0 this now returns
MJPEG_MAX_FPS but this should not happen anyway.
Signed-off-by: Francois Gouget <fgouget@codeweavers.com>
This improves consistency with spice-deps.m4 which names its
AM_CONDITIONAL() variables HAVE_XXX.
Signed-off-by: Francois Gouget <fgouget@codeweavers.com>
In some case the member specified to SPICE_CONTAINEROF was not
exactly the same type of the pointer passed.
This can cause issues if structure changes so use proper member.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Fabiano Fidêncio <fidencio@redhat.com>
If surface_id is not valid we should still release resource allocated
by red_get_update_cmd and from the guest.
This to reduce leaks in case of a race or another error in the guest
driver.
Also not issue a warning on invalid surface number to avoid filling
log space unconditionally.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Pavel Grunt <pgrunt@redhat.com>
Make possible to safely call display_channel_drawable_unref straight
after calling get_drawable.
Problem was function definitions and dependency.
display_channel_drawable_try_new is supposed to return an uninitialized
pointer (or NULL on failure) to a Drawable structure.
(display_channel_)get_drawable is supposed to return an initialized
pointer (or NULL) to a Drawable structure.
(display_channel_)add_drawable is supposed to add the Drawable to the
list/tree of drawing to draw.
Now, with these definitions after get_drawable the Drawable state (if
pointer is not NULL) should be consistent and we should be able to call
display_channel_drawable_unref.
In the current code this was not true as for instance surface_id was
copied to Drawable but the reference counter of the surface was not
incremented leading possible unref call to decrement the counter and
free the surface. This can happen if any call between get_drawable and
unref does not increment the reference in a consistent way. This
basically means that every present or future code in the path between
get_drawable and unref have to know this unconsistency and handle it.
This is a maintaining problem as people need to know these details when
editing existing code (actually this is display_channel_add_drawable
code).
This basically create a dependency between get_drawable and
add_drawable.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Jonathon Jongsma <jjongsma@redhat.com>
For compression statistics clock field was not initialized but used
computing statistics.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Jonathon Jongsma <jjongsma@redhat.com>
Allocation on stack is sufficient and code is more similar to
QXL_CMD_MESSAGE and QXL_CMD_UPDATE cases.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Fabiano Fidêncio <fidencio@redhat.com>
A NULL get_roundtrip_ms() callback simply disables rate control so
that mjpeg_encoder_get_source_fps() will not be called.
Should it be called despite this, simply return the highest allowed
framerate (get_source_fps()'s value is only an estimate anyway).
Finally update_client_playback_delay() is always checked before use.
Signed-off-by: Francois Gouget <fgouget@codeweavers.com>
Do not check if worker->display_channel is NULL as we are already using
to get some field so must be not NULL.
Reuse display_red_channel variable.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Uri Lublin <uril@redhat.com>
Set pointers to NULL after releasing encoders.
This to make sure no further access will occurs.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Victor Toso <victortoso@redhat.com>
Acked-by: Pavel Grunt <pgrunt@redhat.com>
Use mnemonic instead of constant to return enumeration value
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Fabiano Fidêncio <fidencio@redhat.com>
Display client can ask to change the preferred compression.
Previously this setting change the entire worker setting
so every future client created would have this setting.
Remove the setting in the worker make the change only to the
current client.
Signed-off-by: Marc-André Lureau <marcandre.lureau@gmail.com>
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Fabiano Fidêncio <fidencio@redhat.com>
This is really not supported, requires X11, so better to remove it for
now. Some day it might be revived, using DRM, ..
Note for later, this could be removed too (not used by client):
- spice-common/common/ogl_ctx
Acked-by: Fabiano Fidêncio <fidencio@redhat.com>
Avoid problem when compiling with lz4 and without COMPRESS_STAT
dcc.c: In function 'dcc_compress_image_lz4':
dcc.c:657:21: error: unused variable 'display_channel' [-Werror=unused-variable]
DisplayChannel *display_channel = DCC_TO_DC(dcc);
Acked-by: Frediano Ziglio <fziglio@redhat.com>
This allow different dcc to have different settings from default one.
The parameters are copied initially from default settings but then they
can change independently for each client.
Even having a single client a future client is not affected by a
previous setting on the old dcc.
Signed-off-by: Marc-André Lureau <marcandre.lureau@gmail.com>
[updated for the preferred compression]
Signed-off-by: Pavel Grunt <pgrunt@redhat.com>
Acked-by: Frediano Ziglio <fziglio@redhat.com>
Make sure an allocated buffer is correctly referenced by the marshaller,
and can't be free and reused by mistake. Simplify the code by using
GSlice
Acked-by: Jonathon Jongsma <jjongsma@redhat.com>
Ok. this one was painful.Note that in some cases, DCC_TO_DC should be
made safer (there used to be a if !dcc guard in some places, although
that looks wrong anyway)...
Acked-by: Pavel Grunt <pgrunt@redhat.com>
This fixes some compilation errors with gcc 4.4.7 on RHEL 6.
Signed-off-by: Francois Gouget <fgouget@codeweavers.com>
Acked-by: Fabiano Fidêncio <fidencio@redhat.com>
This fixes a compilation error with gcc 4.4 on RHEL 6.
Signed-off-by: Francois Gouget <fgouget@codeweavers.com>
Acked-by: Fabiano Fidêncio <fidencio@redhat.com>
After spice_char_device_state_destroy is called spicevmc should not keep
reference to that memory. state->chardev_st and sin->st point to the
same SpiceCharDeviceState and both should be set to NULL when it is
destroyed.
As SpiceCharDeviceState is only unref'ed on
spice_char_device_state_destroy the same device could be destroyed more
then once so the pointers that are freed should be set to NULL.
Related: https://bugzilla.redhat.com/show_bug.cgi?id=1281455
When no client is connect we should not need to keep the memory pool
used by char-device. In most situations this is not significant but
when using webdav this could mean freeing MAX_POOL_SIZE bytes
Related: https://bugs.freedesktop.org/show_bug.cgi?id=91350
Otherwise the amount of unused memory could grow while transfering big
chunks of data. This change only means that once the memory was used it
will not be stored again after the limit was reached.
Related: https://bugs.freedesktop.org/show_bug.cgi?id=91350
There are places were the could should definetly free the
SpiceCharDeviceWriteBuffer and places that it should only unref it. The
current use of spice_char_device_write_buffer_free was missleading.
This patch creates the spice_char_device_write_buffer_unref and properly
call these two functions.
Related: https://bugs.freedesktop.org/show_bug.cgi?id=91350
Avoid creating streams for every image due to not properly initialized
DisplayChannel->stream_video field.
Regression since: 4987df8e67
Acked-by: Frediano Ziglio <fziglio@redhat.com>
Functions that check the equality of a path, brush, etc are moved the
display channel source file to prepare for moving the surfaces to the
display channel.
Acked-by: Fabiano Fidêncio <fidencio@redhat.com>
Instead of requiring the dispatcher to send a message to the worker to
create the display channel and cursor channel, just create them when
the worker is created.
Acked-by: Jonathon Jongsma <jjongsma@redhat.com>
Same approach as in spice_server_char_device_wakeup().
Avoid segmentation fault when the webdav channel (spice port channel) is
used with the vnc display:
#0 0x00007ffff7aab734 in spice_char_device_state_opaque_get (dev=0x0)
at char_device.c:720
#1 0x00007ffff7b0850c in spice_server_port_event (sin=<optimized out>, event=<optimized out>) at spicevmc.c:578
#2 0x0000555555787ba4 in set_guest_connected (port=<optimized out>, guest_connected=1) at hw/char/virtio-console.c:89
#3 0x0000555555678d7c in control_out (len=<optimized out>, buf=0x55555775c3a0, vser=0x5555578d1540) at /home/pgrunt/RH/qemu/hw/char/virtio-serial-bus.c:404
#4 0x0000555555678d7c in control_out (vdev=0x5555578d1540, vq=0x555557941bc8)
at /home/pgrunt/RH/qemu/hw/char/virtio-serial-bus.c:441
#5 0x000055555588eb98 in aio_dispatch (ctx=0x5555562e1a50) at aio-posix.c:160
#6 0x00005555558829ee in aio_ctx_dispatch (source=<optimized out>, callback=<optimized out>, user_data=<optimized out>) at async.c:226
#7 0x00007ffff2010e3a in g_main_context_dispatch () at /lib64/libglib-2.0.so.0
#8 0x000055555588d8fb in main_loop_wait () at main-loop.c:211
#9 0x000055555588d8fb in main_loop_wait (timeout=<optimized out>)
at main-loop.c:256
#10 0x000055555588d8fb in main_loop_wait (nonblocking=<optimized out>)
at main-loop.c:504
#11 0x000055555561b664 in main () at vl.c:1891
This commit moves some DrawablePipeItem declarations to
display-channel.h, though the function implementations remain in
red_worker.c until they can be disentangled some more.
Acked-by: Frediano Ziglio <fziglio@redhat.com>
It's a regression introduced by commit e601e920bd. The logic error was
introduced when trying to achieve the following code[0]. but rewritten
to prefer an early return, which was wrogly negated.
[0]:
if (cursor_is_connected(worker)
&& !COMMON_CHANNEL(worker->cursor_channel)->during_target_migrate) {
red_channel_pipes_add_type(RED_CHANNEL(worker->cursor_channel),
PIPE_ITEM_TYPE_CURSOR_INIT);
}
Signed-off-by: Fabiano Fidêncio <fidencio@redhat.com>
Acked-by: Frediano Ziglio <fziglio@redhat.com>
In order to invalidate a single palette cache item, we were using
spice_marshall_msg_cursor_inval_one(), which is the marshal function
used to send an invalidation message for the Cursor channel's cache.
This didn't cause any problems because SPICE_MSG_CURSOR_INVAL_ONE and
SPICE_MSG_DISPLAY_INVAL_PALETTE have the same message ID and parameters,
but it's better to use the correct marshalling function.
Acked-by: Frediano Ziglio <fziglio@redhat.com>
This field is only assigned and never readed so can be removed.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Fabiano Fidêncio <fidencio@redhat.com>
Doing so allows us to remove the extra QXLInstance parameter from
cursor_item_unref() and makes the code a bit cleaner.
Also add cursor_item_ref().
Signed-off-by: Jonathon Jongsma <jjongsma@redhat.com>
Acked-by: Fabiano Fidêncio <fidencio@redhat.com>
Move the cursor-specific pipe item types to cursor-channel.h, and the
display-specific types to red_worker.c. Only leave the common
definitions in red_worker.h. This prepares for splitting the display
channel into a separate file.
Signed-off-by: Jonathon Jongsma <jjongsma@redhat.com>
Acked-by: Fabiano Fidêncio <fidencio@redhat.com>
Move function from server/red_worker.c to new server/display-channel.c.
Acked-by: Fabiano Fidêncio <fidencio@redhat.com>
Acked-by: Frediano Ziglio <fziglio@redhat.com>
There is no guarantee in the code that this can't be hit, so we should
cope with it (the condition can be reached easily by running the server
without waiting for blocked clients or pipe size)
The following commit will attempt to address this.
Acked-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Christophe Fergeau <cfergeau@redhat.com>
Rename and lightly refactor the function that creates new common
channels for RedWorker (essentially Cursor and Display channels).
Signed-off-by: Jonathon Jongsma <jjongsma@redhat.com>
Acked-by: Frediano Ziglio <fziglio@redhat.com>
The first argument should be CursorChannel* rather than RedChannel*
since it's essentially a CursorChannel method.
Signed-off-by: Jonathon Jongsma <jjongsma@redhat.com>
Acked-by: Frediano Ziglio <fziglio@redhat.com>
Note that this requires some adjustments to the encode_frame()
parameters to avoid red_worker-specific types.
Signed-off-by: Francois Gouget <fgouget@codeweavers.com>
red_cursor_marshall_inval(), red_migrate_cursor() and
on_new_cursor_channel() were short functions that were each only called
from a single location, so there's no need for them to be separate
functions.
Signed-off-by: Jonathon Jongsma <jjongsma@redhat.com>
Acked-by: Frediano Ziglio <fziglio@redhat.com>
Instead of passing a CommonChannel* argument, use CursorChannel* since
this function is only valid for CursorChannels.
Signed-off-by: Jonathon Jongsma <jjongsma@redhat.com>
Acked-by: Frediano Ziglio <fziglio@redhat.com>
Rename and re-order the initial arguments to make this function look and
act more like a method of the CommonChannel class.
Signed-off-by: Jonathon Jongsma <jjongsma@redhat.com>
Acked-by: Frediano Ziglio <fziglio@redhat.com>
cursor_channel_new() is only called from one location, and always passes
FALSE as the value for the 'migrate' paramater. In addition, this
parameter is not used within the function. Remove it.
Signed-off-by: Jonathon Jongsma <jjongsma@redhat.com>
Acked-by: Frediano Ziglio <fziglio@redhat.com>
Do not use static allocate space but handle dynamically
Signed-off-by: Marc-André Lureau <marcandre.lureau@gmail.com>
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Timer queue is attached to current thread when created so it must be
created from the proper thread.
After worker initialization is moved in a following patch to main
thread the queue was created in the wrong thread causing program to
fail saying that the queue is NULL.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Uri Lublin <ulublin@redhat.com>
This commit also updates the spice-common submodule
Christophe Fergeau (7):
Add marshaller test case
build-sys: Use ${PKG_CONFIG} rather than pkg-config
build-sys: Rework SPICE_CHECK_* m4 macros
build-sys: Add gio-2.0 to SPICE_CHECK_GLIB2
build-sys: Fix error in SPICE_CHECK_LZ4 description
build-sys: Set automake conditional in SPICE_CHECK_SMARTCARD
build-sys: Rename SUPPORT_GL to HAVE_GL
Javier Celaya (1):
Fix linearization of several marshallers with one item
Lukas Venhoda (3):
ssl-verify: Only check addr length when using IP addr
m4: Require glib version >= 2.22
ssl-verify: Changed IPv4 hostname to IPv6
cinfo.dest is allocated in spice_jpeg_mem_dest but never freed.
Note that jpeg_destroy_compress does not free this field as is
supposed to be a buffer provided by jpeg caller.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Now that worker is created before running, and run() returns success,
there is no point in using MESSAGE_READY.
Acked-by: Frediano Ziglio <fziglio@redhat.com>
Remove that hideous template header that should really be regular code
since it's specialized and instanciated only for pixmap.
Acked-by: Frediano Ziglio <fziglio@redhat.com>
There was not check for data_size field so one could set data to
a small set of data and data_size much bigger than size of data
leading to buffer overflow.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
The guest can attempt to increase the number of segments while
spice-server is reading them.
Make sure we don't copy more then the allocated segments.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Christophe Fergeau <cfergeau@redhat.com>
start pointer points to a QXLPathSeg structure.
Before reading from the structure, make sure the structure is contained
in the memory range checked.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Christophe Fergeau <cfergeau@redhat.com>
Limit number of chunks to a given amount to avoid guest trying to
allocate too much memory. Using circular or nested chunks lists
guest could try to allocate huge amounts of memory.
Considering the list can be infinite and guest can change data this
also prevents strange security attacks from guest.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Free linked list if client tries to do nasty things
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Christophe Fergeau <cfergeau@redhat.com>
Do not read multiple times data from guest as this can be changed by
other guest vcpus. This causes races and security problems if these
data are used for buffer allocation or checks.
Actually, the 'data' member can't change during read as it is just a
pointer to a fixed array contained in qxl. However, this change will
make it clear that there can be no race condition.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
If bpp is int the formula can lead to weird overflows. width and height
are uint16_t so the formula is:
size_t = u16 * (u16 * int + const_int) / const_int;
so it became
size_t = (int) u16 * ((int) u16 * int + const_int) / const_int;
However the (int) u16 * (int) u16 can then became negative to overflow.
Under 64 bit architectures size_t is 64 and int usually 32 so converting
this negative 32 bit number to a unsigned 64 bit lead to a very big
number as the signed is extended and then converted to unsigned.
Using unsigned arithmetic prevent extending the sign.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Christophe Fergeau <cfergeau@redhat.com>
Do not read multiple time an array size that can be changed.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Christophe Fergeau <cfergeau@redhat.com>
Do not read multiple times data from guest as this could be changed
by other vcpu threads.
This causes races and security problems if these data are used for
buffer allocation or checks.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Christophe Fergeau <cfergeau@redhat.com>
Do not read multiple time an array size that can be changed.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Christophe Fergeau <cfergeau@redhat.com>
The overflow may lead to buffer overflow as the row size computed from
width (bitmap->x) can be bigger than the size in bytes (bitmap->stride).
This can make spice-server accept the invalid sizes.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Christophe Fergeau <cfergeau@redhat.com>
Not security risk as just for read.
However, this could be used to attempt integer overflows in the
following lines.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Christophe Fergeau <cfergeau@redhat.com>
Check format is valid.
Check stride is at least the size of required bytes for a row.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Christophe Fergeau <cfergeau@redhat.com>
Prevent integer overflow when computing image sizes.
Image index computations are done using 32 bit so this can cause easily
security issues. MAX_DATA_CHUNK is larger than the virtual
card limit, so this is not going to cause change in behaviours.
Comparing size calculation results with MAX_DATA_CHUNK will allow us to
catch overflows.
Prevent guest from allocating large amount of memory.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
A driver can overwrite surface state creating a surface with the same
id of a previous one.
Also can try to destroy surfaces that are not created.
Both requests cause invalid internal states that could lead to crashes
or memory corruptions.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Do not just give warning and continue to use an invalid index into
an array.
Resolves: CVE-2015-5260
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Christophe Fergeau <cfergeau@redhat.com>
replay.c: In function 'replay_channel_event':
replay.c:226:16: error: zero-length gnu_printf format string
[-Werror=format-zero-length]
g_printerr("");
The patches adding a way for the client to set its preferred compression
method added a new capability so that the server can indicate support
for this feature. However, spice-server was not setting this capability
on its display channel, which means clients are not going to try to send
'preferred-compression' messages even though the user request it.
For security reasons do not assume guest do not change structures it
pass to Qemu.
Guest could change count field while Qemu is copying QXLMonitorsConfig
structure leading to heap corruption.
This patch avoid it reading count only once.
This patch solves CVE-2015-3247.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Christophe Fergeau <cfergeau@redhat.com>
This patch contains a bit of small optimizations.
It avoid boolean operations which could involve branches replacing
with binary operations (equal/all_ident -> some_differences).
The other optimization avoids the use of ABS. First the way the macro
was used (with a large expression) was not easy to optimize by the
compiler.
Then instead of using ABS a much simpler range check is used so instead
of (ABS(n) >= k) a ((n) <= -k || (n) >= k) is used. This looks small
but modern compilers can translate this not in range check in a couple
of machine instructions (and a single compare).
Using operf on same samples (using spice-server-replay) and trying 2 runs
I got
run 1 2
-------------------------
before 104441 106267
after 92387 91083
So the performance increase is about 13%.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Jonathon Jongsma <jjongsma@redhat.com>
Due to how the MIN macro is defined the function was called twice
unless the compiler could demonstrate that was returning the same
value (which actually is impossible as function as clock_gettime
are not deterministic).
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Jonathon Jongsma <jjongsma@redhat.com>
Do not access to timer after we call the associated function.
Some of these callbacks can call spice_timer_remove making the pointer
pointing to freed data.
This happen for instance when the client is disconnecting.
This does not cause memory corruption on current allocator
implementations as all freeing/accessing happen on a single thread quite
closely and allocators use different pools for different thread.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Christophe Fergeau <cfergeau@redhat.com>
Avoid to use typedef twice for the same type as some compiler
complaints about it.
SpiceTimer and SpiceWatch are defined in server/spice-core.h
as an abstract type which should be defined by some code (as
server/tests/basic_event_loop.c does).
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
spice_server_destroy calls reds_exit which is called also at exit time
(is registered with atexit) so avoid to keep dangling pointers.
Currently this does not happen as spice_server_destroy is not called
by Qemu.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
On 32 bit machine timespec->tv_sec (time_t) is 32 bit.
Also 1000 * 1000 * 1000 is 32 bit.
The multiplication of 2 32 bit integers gives a 32 bit integer, however
this can overflow.
Converting the first factor to 64 bit before the multiplication solves
the issue.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
This script was used at make distcheck time to verify consistency of the
version number defined in configure.ac and in spice-server headers.
Since commit ab12cf414c, these 2 version numbers can no longer be out of
sync, so we can drop this script.
Commit 3c6b4e41 removed spice-experimental.h as this header was not
used, nor supposed to be used. However, QEMU had been including it
(without using any of its symbols) until commit v2.3.0-rc0~135^2~1
As this is fairly recent (Nov 2014), building older QEMUs with new
spice-server releases, or even bisecting QEMU will be broken as they
will be looking for a no-longer available header.
This commit readds a spice-experimental.h file, however it only contains
a #warning indicating this file is deprecated. This means older QEMU
will build now, but only if they were configured with --disable-werror.
Actually not causing problems as when used is always followed by another
terminator but better to fix the definition.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Pavel Grunt <pgrunt@redhat.com>
Mutex/conditional require Glib 2.32 which is not available in RHEL6.
Use plain pthread to make this module compatible with RHEL6.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Fabiano Fidencio <ffidenci@redhat.com>
A logical and (&&) was used instead of a bit one (&).
Was working just as is the only flag defined.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Fabiano Fidencio <ffidenci@redhat.com>
usage: spice-server-replay -p <port> -c <client command line> <cmdfile>
will run the commands from cmdfile ignoring timestamps, right after a
connection is established from the client, and will SIGINT the client
on end of cmdfile, and exit itself after waiting for the client.
spicy-stats from spice-gtk is useful for testing, it prints the summary
of the traffic on each channel.
You can also run with no client by doing:
spice-server-replay <cmdfile>
For example, the 300 MB file (compressed to 4 MB with xz -9) available
at [1] produces the following output:
spicy-stats total bytes read:
total bytes read:
inputs: 214
display: 1968983
cursor: 390
main: 256373
You could run it directly like so:
curl http://annarchy.freedesktop.org/~alon/win7_boot_shutdown.cmd.xz | \
xzcat | server/tests/spice-server-replay -p 12345 -c `which spicy-stats` -
Known Problems:
* Implementation is wrong. Should do a single device->host conversion
(i.e. get_virt), and then marshall/demarshall that (i.e. RedDrawable).
* segfault on file read done resulting in the above spicy-stats not
being reproducable (well, up to 1% yes).
[1] http://annarchy.freedesktop.org/~alon/win7_boot_shutdown.cmd.xz
Now based on glib including using an asyncqueue for reading the playback
file, and proper freeing of the allocated commands, with --slow,
--compression and a progress timer, and doesn't use more then nsurfaces.
Signed-off-by: Alon Levy <alon@pobox.com>
Signed-off-by: Marc-André Lureau <marcandre.lureau@gmail.com>
if the environment variable in the title is set and can be
opened for writing a log of all display commands (no cursor
commands yet) and any QXLWorker calls (particularily primary
create and destroy) will be logged to that file, and possible
to replay using the replay utility introduced later.
For an example file (4 MB download, 300 MB after unpack with xz,
these 300 MB are themselves reduced from 1.2GB using zlib compression
for any chunk):
(old file without a header)
http://annarchy.freedesktop.org/~alon/win7_boot_shutdown.cmd.xz
Signed-off-by: Alon Levy <alon@pobox.com>
Signed-off-by: Marc-André Lureau <marcandre.lureau@gmail.com>
Currently hand crafted with some sed scripts and alot of vim macros from
red_parse_qxl after considering the logger in qemu/hw/qxl-logger.c and seeing
it was incomplete. The only problem with logging from the server and
not from qemu is that it requires coordinated shutdown to avoid half a message.
Should be automatically generated from a declarative syntax, i.e. qxl.proto.
Note: zlib compression is introduced in a disabled state, see ZLIB
define
Now with a simple versioned header and generated ids by the server
instead of based on the recorded file, and doesn't use more then 1024
surfaces (configurable).
Signed-off-by: Alon Levy <alon@pobox.com>
Signed-off-by: Marc-André Lureau <marcandre.lureau@gmail.com>
As the input line could be uint8_t*, uint16_t* or uint32_t*, changing
the default from uint8_t* to void* seems the correct choice to deal with
upcasting warnings.
Regarding chunks->data allocation, I quote Frediano explantion:
"Lines came from spice_bitmap_get_line. This function assume that bitmap
data is split among chunks each containing some lines
(always full lines). If chunk->data is allocated using malloc or similar
SHOULD (not 100% sure) be 4 bytes aligned so in our cases
(8, 16, 24 or 32 bit images) should be aligned enough.
All the casts unfortunately came from the fact we compute based on
pixel bytes to make it generic so we use uint8_t*."
and
"Looking at code looks like these chunks came from the virtual machine.
So the question is... why should the virtual machine give use some
not-pixel align data?
I would put a large comment to state that we assume VM send aligned
data, would be stupid for the VM to not align it!"
clang output:
jpeg_encoder.c:109:26: error: cast from 'uint8_t *'
(aka 'unsigned char *') to 'uint16_t *' (aka 'unsigned short *')
increases required alignment from 1 to 2 [-Werror,-Wcast-align]
uint16_t *src_line = (uint16_t *)line;
^~~~~~~~~~~~~~~~
jpeg_encoder.c:144:26: error: cast from 'uint8_t *'
(aka 'unsigned char *') to 'uint32_t *' (aka 'unsigned int *')
increases required alignment from 1 to 4 [-Werror,-Wcast-align]
uint32_t *src_line = (uint32_t *)line;
^~~~~~~~~~~~~~~~
mjpeg_encoder.c:260:23: error: cast from 'uint8_t *'
(aka 'unsigned char *') to 'uint16_t *' (aka 'unsigned short *')
increases required alignment from 1 to 2 [-Werror,-Wcast-align]
uint16_t pixel = *(uint16_t *)src;
^~~~~~~~~~~~~~~
Instead of using uint8_t* which can cause several warnings on casting as
the example below:
./glz_encode_tmpl.c:321:29: error: cast from 'uint8_t *'
(aka 'unsigned char *') to 'rgb16_pixel_t *' (aka 'unsigned short *')
increases required alignment from 1 to 2 [-Werror,-Wcast-align]
ref_limit = (PIXEL *)(seg->lines_end);
^~~~~~~~~~~~~~~~~~~~~~~~~
SpiceBitmap's stride is uint32_t.
from clang:
red_parse_qxl.c:452:41: error: taking the absolute value of unsigned
type 'uint32_t' (aka 'unsigned int') has no effect
bitmap_size = red->u.bitmap.y * abs(red->u.bitmap.stride);
^
There is a red_init() methods, we can group all the red_init_*() calls
in it rather than calling red_init() followed by all these calls in our
main function.
This has been renamed to SpiceImageCompression in order to avoid clashes
with older spice-server in the SPICE_IMAGE_COMPRESS_ namespace. This
commit is a straight rename of SpiceImageCompress to
SpiceImageCompression and SPICE_IMAGE_COMPRESS_ to
SPICE_IMAGE_COMPRESSION_
This prevents a compile error on Debian Jessie, from git, such as this:
/usr/bin/ld: test_playback.o: undefined reference to symbol 'sin@@GLIBC_2.2.5'
//lib/x86_64-linux-gnu/libm.so.6: error adding symbols: DSO missing from command line
This is fairly subtle, and Debian specific. It only happens when you use
autoreconf to generate a new libtool script. Debian patches that script
to require an explicit setting to link with all dependent libraries.
It should be harmless on other distros, and it does save us Debian guys some
hassle.
If a previous Qemu executable is not able to delete the statistic file
on the next creation with same name (statitics file are based on pid
numbers so if pid get reused for another Qemu process you get the same
name) it fails as you can't open a file with 0444 permissions (these
are the permission used to create these files).
This patch assure there are no stale file trying to remove it before the
creation of the new one. As file is based on pid and name used for spice
you are not deleting another file.
Fixes: rhbz#1177326
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
NET_TEST_WARMUP_BYTES is 0 so the warmup ping is the same as the one we
use to measure the latency. Even if it was not, the actual latency would
be the MIN() of both anyway so we might as well use both roundtrip times
to ward off latency jitter a bit.
Signed-off-by: Francois Gouget <fgouget@codeweavers.com>
red_marshall_image() allows to use other than QUIC compression only
when auto_lz or auto_glz image compression is set. Other images don't
have the problem because they are compressed using red_compress_image()
Locking the individual calls that access the pixmap cache in fill_bits is
not adequately thread safe. Often a windows guest with multiple monitors
will be sending the same image via different threads. Both threads can
be in fill_bits at the same time making changes to the cache for the same
image. This can result in images being deleted before all the client
channels are finished with them or with the same image being send multiple
times. Here's what can happen with out the lock in fill_bits
On the server in red_worker.c:fill_bits
Thread 1 calls pixmap_cache_hit for Image A and finds it isn't in cache
Thread 2 calls pixmap_cache_hit for Image A and finds it isn't in cache
Thread 1 adds Image 1 to pixmap_cache (1x)
Thread 2 adds Image 1 to pixmap_cache (2x)
On the client
Channel 1 adds Image A to image_cache (1x)
Channel 2 replaces Image A in image_cache (1x)
On server
Thread 1 sends Image A rendering commands
Thread N removes Image A from pixmap_cache (image remains - 1x)
Thread 2 sends Image A rendering commands
On client
Channe1 renders from Image A
Channel N removes Image a from image_cache (image is completely removed)
Channel2 render command hangs waiting for Image A
spice-server will attempt to limit number of monitors.
Guest machine can send monitor list it accepts. Limiting the number sent
by guest will limit the number of monitors client will try to enable.
The guest usually see client monitors enabled and start using it so
not seeing client monitor won't try to enable more monitor.
In this case the additional monitor guest can support will always be
seen as heads with no attached monitors.
This allows limiting monitors number without changing guest drivers.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
The checks would lead the reader to think these functions can be called
when bit rate control is off when in fact they are only called when it
is active.
Signed-off-by: Francois Gouget <fgouget@codeweavers.com>
With a TCP socket, the backlog doesn't seem to matter much,
perhaps because of latency or underlying protocol behaviour. However,
on UNIX socket, it is fairly easy to reach the backlog limit and the
client will get an EAGAIN error (but not ECONNREFUSED as stated in
listen(7)) that is not easy to deal with: attempting to reconnect in a
loop might busy-loop forever as there are no guarantee the server will
accept new connections, so it will be inherently racy.
Typically, Spice server can easily have up to 15 concurrent incoming
connections that are established during initialization of the session.
To improve the situation, raise the backlog limit to the default maximum
system value, which is 128 on Linux.
Do not just check and give warning before crashing the program
accessing a NULL pointer but use spice_malloc which exits with a
proper message.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
There is already a enumeration in a public header that defines the
different streaming options, so there's no need to duplicate that
enumeration internally. Just use the public enum values.
During migration, a volume jump is observed by the client. This is due
to qemu setting up destination server with default sound state, and the
server sending it after the client is connected. The volume is later
restored after migration is finished so there is no need to send this
default state values on connection.
Tested with both AC97 & HDA devices.
Fixes:
https://bugzilla.redhat.com/show_bug.cgi?id=1012868
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>
This fixes Spice's smart card support and is related to
commit 697f3214fd.
Reported-by: Swapna Krishnan <skrishna@redhat.com>
Recursion is now possible starting with spice_char_device_write_to_device
going through spice_char_device_wakeup (after going through qemu),
calling again to spice_char_device_write_to_device.
The protecting code is the same as the one protecting the read path.
This function call loop makes the program to abort with the following messages:
usb-ccid: chardev: unexpected message of type 3000000
qemu: qemu_mutex_lock: Resource deadlock avoided
Backtrace:
(gdb) bt
* #0 0x00007ffff3fc78c7 in raise () from /lib64/libc.so.6
* #1 0x00007ffff3fc952a in abort () from /lib64/libc.so.6
* #2 0x0000555555969a95 in error_exit (err=35,
* msg=0x5555559f8c90 <__func__.5119> "qemu_mutex_lock")
* at util/qemu-thread-posix.c:48
* #3 0x0000555555969b82 in qemu_mutex_lock (mutex=0x5555562c4d60)
* at util/qemu-thread-posix.c:79
* #4 0x0000555555714771 in qemu_chr_fe_write (s=0x5555562c4d60,
* buf=0x7fffffffd2a0 "", len=12) at qemu-char.c:219
* #5 0x000055555586be49 in ccid_card_vscard_send_msg (s=0x5555565c5f80,
* type=VSC_Error, reader_id=0, payload=0x7fffffffd2e0 "", length=4)
* at hw/usb/ccid-card-passthru.c:75
* #6 0x000055555586bf00 in ccid_card_vscard_send_error (s=0x5555565c5f80,
* reader_id=0, code=VSC_GENERAL_ERROR) at
* hw/usb/ccid-card-passthru.c:91
* #7 0x000055555586c559 in ccid_card_vscard_handle_message (
* card=0x5555565c5f80, scr_msg_header=0x5555565c6008)
* at hw/usb/ccid-card-passthru.c:254
* #8 0x000055555586c72f in ccid_card_vscard_read (opaque=0x5555565c5f80,
* buf=0x5555565034b0 "", size=12) at hw/usb/ccid-card-passthru.c:289
* #9 0x00005555557149db in qemu_chr_be_write (s=0x5555562c4d60,
* buf=0x5555565034b0 "", len=12) at qemu-char.c:305
* #10 0x000055555571cde5 in vmc_write (sin=0x5555562c4e78,
* buf=0x5555565034b0 "", len=12) at spice-qemu-char.c:41
* #11 0x00007ffff4fa86aa in spice_char_device_write_to_device (
* dev=0x55555657f210) at char_device.c:462
* #12 0x00007ffff4fa9b48 in spice_char_device_wakeup (dev=0x55555657f210)
* at char_device.c:862
* #13 0x00007ffff4ff7658 in spice_server_char_device_wakeup
* (sin=0x5555562c4e78) at reds.c:2955
* #14 0x000055555571d1d2 in spice_chr_write (chr=0x5555562c4d60,
* buf=0x7fffffffd560 "", len=12) at spice-qemu-char.c:189
* #15 0x0000555555714789 in qemu_chr_fe_write (s=0x5555562c4d60,
* buf=0x7fffffffd560 "", len=12) at qemu-char.c:220
* #16 0x000055555586be49 in ccid_card_vscard_send_msg (s=0x5555565c5f80,
* type=VSC_Error, reader_id=0, payload=0x7fffffffd5a0 "", length=4)
* at hw/usb/ccid-card-passthru.c:75
* #17 0x000055555586bf00 in ccid_card_vscard_send_error
* (s=0x5555565c5f80,
* reader_id=0, code=VSC_SUCCESS) at hw/usb/ccid-card-passthru.c:91
* #18 0x000055555586c4fc in ccid_card_vscard_handle_message (
* card=0x5555565c5f80, scr_msg_header=0x5555565c6008)
* at hw/usb/ccid-card-passthru.c:242
* #19 0x000055555586c72f in ccid_card_vscard_read (opaque=0x5555565c5f80,
* buf=0x5555565034b0 "", size=12) at hw/usb/ccid-card-passthru.c:289
* #20 0x00005555557149db in qemu_chr_be_write (s=0x5555562c4d60,
* buf=0x5555565034b0 "", len=12) at qemu-char.c:305
* #21 0x000055555571cde5 in vmc_write (sin=0x5555562c4e78,
* buf=0x5555565034b0 "", len=12) at spice-qemu-char.c:41
* #22 0x00007ffff4fa86aa in spice_char_device_write_to_device (
* dev=0x55555657f210) at char_device.c:462
* #23 0x00007ffff4fa8d37 in spice_char_device_write_buffer_add (
* dev=0x55555657f210, write_buf=0x555556501f70) at char_device.c:597
* #24 0x00007ffff501142d in smartcard_channel_write_to_reader (
* write_buf=0x555556501f70) at smartcard.c:669
* #25 0x00007ffff501034c in smartcard_char_device_notify_reader_add (
* st=0x55555657ef00) at smartcard.c:335
* #26 0x00007ffff50112b3 in smartcard_add_reader (scc=0x555556493ee0,
* name=0x5555565023cc "E-Gate 0 0") at smartcard.c:642
* #27 0x00007ffff50118d2 in smartcard_channel_handle_message (
* rcc=0x555556493ee0, type=101, size=22, msg=0x5555565023c0 "\003")
* at smartcard.c:757
* #28 0x00007ffff4fbc168 in red_peer_handle_incoming
* (stream=0x555556588250, handler=0x555556497ff0) at red_channel.c:308
* #29 0x00007ffff4fbc231 in red_channel_client_receive
* (rcc=0x555556493ee0) at red_channel.c:326
* #30 0x00007ffff4fc0019 in red_channel_client_event (fd=59, event=1,
* data=0x555556493ee0) at red_channel.c:1574
* #31 0x00005555558b6076 in watch_read (opaque=0x5555565002f0)
* at ui/spice-core.c:101
* #32 0x00005555558e8d48 in qemu_iohandler_poll (pollfds=0x5555562b7630,
* ret=2) at iohandler.c:143
* #33 0x00005555558e89a4 in main_loop_wait (nonblocking=0) at
* main-loop.c:495
* #34 0x00005555557219b0 in main_loop () at vl.c:1794
* #35 0x0000555555729257 in main (argc=40, argv=0x7fffffffddc8,
* envp=0x7fffffffdf10) at vl.c:4350
Reversing the bottom-up images in the server is not needed since Pixman,
in the client, is able to deal with them. As a result, the previous code
was more complex and wrong. This commit fixes and cleans it.
Currently, the LZ4 encoding only (partially) supports RGB images, so
we must check the image format before using it. In the future, indexed
formats may be implemented too, but their use is usually very small
compared to RGB.
inputs_channel_handle_parsed() is casting its void * argument to
a uint8_t * buf before recasting this 'buf' variable to different
other types. This intermediate 'buf' variable is not needed, especially
as we can then benefit from implicit casts from void * to the type we
need.
When handling a KEY_UP message, the various variables were called
'key_down', and they were called 'key_up' when handling KEY_DOWN
messages. This commit makes the naming consistent.
- Add lz4 encoder to compress an image of type LZ4 (see spice_common).
- Add code in red_worker to use LZ4 when it is enabled, and the client
supports it through its display capability, or fallback to LZ.
- Add enable_lz4 switch in the configure script. Show LZ4 support at the
end.
Fixes the following build error:
In file included from
/home/elmarco/src/spice-new/src/spice/server/tests/test_display_base.h:4:0,
from
/home/elmarco/src/spice-new/src/spice/server/tests/test_display_no_ssl.c:11:
/home/elmarco/src/spice-new/src/spice/server/spice.h:23:27:
fatal error: spice-version.h: No such file or directory
#include "spice-version.h"
^
The multimedia time is defined by the server side monotonic time [1],
but the drawing time-stamp is done in guest side, so it requires
synchronization between host and guest. This is expensive, when no audio
is playing, there is a ~30x/sec wakeup to update the qxl device mmtime,
and it requires marking dirty the rom region.
Instead, the video timestamping can be done more efficiently on server
side, without visible drawbacks.
[1] a better timestamp could be the audio time, since audio players are
usually sync with audio time)
Related to:
https://bugzilla.redhat.com/show_bug.cgi?id=912763
Editing the hexadecimal value of spice-version and keeping it in sync
with actual release is a bit tedious. Let's generate it
automatically (although handling of bumps will need temporarily static
versions, when 0.12 -> 1.0 for example)
In an effort to reduce the wakeups per second, get rid of the
"write_to_dev" timer when the implementation supports
SPICE_CHAR_DEVICE_NOTIFY_WRITABLE.
When this flag is set, the frontend instance is responsible for calling
spice_char_device_wakeup() when the device is ready to perform IO.
Related to:
https://bugzilla.redhat.com/show_bug.cgi?id=912763
If the client advertises the SASL cap, it means it guarantees it will be
able to use SASL if the server supports, and that it does not need a valid
SpiceLinkReply::pub_key field when using SASL.
When the client cap is set, we thus don't need to create a RSA public key
if SASL is enabled server side.
The reason for needing client guarantees about not looking at the pub_key
field is that its presence and size is hardcoded in the protocol, but in
some hardened setups (using fips mode), generating a RSA 1024 bit key as
expected is forbidden and fails. With this new capability, the server
knows the client will be able to handle SASL if needed, and can skip
the generation of the key altogether. This means that on the setups
described above, SASL authentication has to be used.
The server will reset the vdagent char device when the client does not
implement SPICE_MAIN_CAP_AGENT_CONNECTED_TOKENS. This will nullify
dev->sin and the following crash will be reached on restart:
#0 0x00007fb05aa264a1 in spice_char_device_write_to_device (dev=dev@entry=0x7fb066ae5d30) at char_device.c:443
#1 0x00007fb05aa27137 in spice_char_device_write_to_device (dev=0x7fb066ae5d30) at char_device.c:436
#2 spice_char_device_start (dev=0x7fb066ae5d30) at char_device.c:798
#3 0x00007fb05aa6a981 in spice_server_vm_start (s=<optimized out>) at reds.c:3795
#4 0x00007fb0644b7f89 in qdev_reset_one (dev=<optimized out>, opaque=<optimized out>) at hw/core/qdev.c:241
#5 0x00007fb0644b7918 in qbus_walk_children (bus=0x7fb06661e870, pre_devfn=0x0, pre_busfn=0x0,
post_devfn=0x7fb0644b7f80 <qdev_reset_one>, post_busfn=0x7fb0644b6350 <qbus_reset_one>, opaque=0x0)
at hw/core/qdev.c:422
#6 0x00007fb0644b7848 in qdev_walk_children (dev=0x7fb0665f47a0, pre_devfn=0x0, pre_busfn=0x0,
post_devfn=0x7fb0644b7f80 <qdev_reset_one>, post_busfn=0x7fb0644b6350 <qbus_reset_one>, opaque=0x0)
at hw/core/qdev.c:456
#7 0x00007fb0644b7918 in qbus_walk_children (bus=0x7fb06647cde0, pre_devfn=0x0, pre_busfn=0x0,
post_devfn=0x7fb0644b7f80 <qdev_reset_one>, post_busfn=0x7fb0644b6350 <qbus_reset_one>, opaque=0x0)
at hw/core/qdev.c:422
#8 0x00007fb0644399fd in qemu_devices_reset () at vl.c:1830
After restart, qemu will reset the device instance (sin) when virtio
port is opened:
#0 spice_char_device_state_reset_dev_instance (state=0x7fe4873876d0, sin=sin@entry=0x7fe486fb0c68)
at char_device.c:667
#1 0x00007fe47b277516 in attach_to_red_agent (sin=0x7fe486fb0c68) at reds.c:2838
#2 spice_server_char_device_add_interface (sin=0x7fe486fb0c68, s=0x7fe486fb2e60) at reds.c:2962
#3 spice_server_add_interface (s=0x7fe486fb2e60, sin=0x7fe486fb0c68) at reds.c:3104
#4 0x00007fe484c69e57 in vmc_register_interface (scd=0x7fe486fb0c60) at spice-qemu-char.c:123
#5 0x00007fe484ce96b4 in set_guest_connected (port=<optimized out>, guest_connected=1)
at hw/char/virtio-console.c:89
#6 0x00007fe484ba70ed in handle_control_message (len=8, buf=0x7fe486fbdf70, vser=0x7fe48739ae98)
at /usr/src/debug/qemu-2.1.0/hw/char/virtio-serial-bus.c:382
Let's ignore the call to spice_char_device_{write,read}_to_device() when
dev->sin is NULL, similary to other conditions, such as dev->running.
Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1145919
During seamless migration, after switching host, if a client was connected
during the migration, it will have data to send back to the new
qemu/spice-server instance. This is handled through MIGRATE_DATA messages.
SPICE char devices use such MIGRATE_DATA messages to restore their state.
However, the MIGRATE_DATA message can arrive any time after the new qemu
instance has started, this can happen before or after the SPICE char
devices have been created. In order to handle this, if the migrate data
arrives early, it's stored in reds->agent_state.mig_data, and
attach_to_red_agent() will restore the agent state as appropriate.
Unfortunately this does not work as expected, for main
channel (agent messages).
If attach_to_red_agent() is called before the MIGRATE_DATA
message reaches the server, all goes well,
but if MIGRATE_DATA reaches the server before
attach_to_red_agent() gets called, then some assert() gets
triggered in spice_char_device_state_restore():
((null):32507): Spice-ERROR **: char_device.c:937:spice_char_device_state_restore: assertion `dev->num_clients == 1 && dev->wait_for_migrate_data' failed
Thread 3 (Thread 0x7f406b543700 (LWP 32543)):
Thread 2 (Thread 0x7f40697ff700 (LWP 32586)):
Thread 1 (Thread 0x7f4079b45a40 (LWP 32507)):
When restoring state, a client must already be added to the
spice-char-device.
What happens is that a client is not being added to the char-device
when when MIGRATE_DATA arrives first, which leaves both
dev->num_clients and dev->wait_for_migrate_data value at 0.
This commit changes the logic in spice_server_char_device_add_interface(),
such that if there is migrate data pending in reds->agent_state.mig_data
but no client was added to the spice-char-device yet,
then first the client is added to the device by calling
spice_char_device_client_add(), and only then the state is restored.
=== How to Reproduce
To reproduce, add delays to the migration connection between
qmeu-kvm on the source host (SRC) and on the destination (DST).
Specifically I added a man in the middle DLY host between
migration ports from SRC to DST.
+-----+ +-----+ +-----+
| SRC |--> | DLY | --> | DST |
+-----+ +-----+ +-----+
DLY listens on port P1 (e.g. 4444) and DST listens on port
PINCOMING (e.g. 4444, from qemu-kvm '-incoming' command line option)
Precondition: make sure port P1 on DLY is accessible in iptables.
Option 1: use ssh tcp port forwarding
On DLY host run ssh:
ssh DLY:P1:DST:PINCOMING DST
Then use the following migration command (on qemu-kvm monitor):
client_migrate_info spice DST PSPICE
migrate -d tcp:DLY:P1
Option 2: Use a simple proxy program that forwards
packets from SRC to DST while adding some delays.
The program runs on DLY, listens to port D1, upon
accept connects to DST:PINCOMING and forward all
packets from DLY:D1 to DST:PINCOMING.
Then use the same migrate command as in option 1:
client_migrate_info spice DST PSPICE
migrate -d tcp:DLY:P1
=== How to Reproduce Ends
This fixes https://bugzilla.redhat.com/show_bug.cgi?id=1035184
Based-on-a-patch-by: Christophe Fergeau <cfergeau@redhat.com>
It's possible for a buggy guest driver to pass invalid bounding box
dimensions in QXL commands, which would then cause spice-server to
segfault. This patch checks the size of the bounding box of the QXL
command right after it has been parsed.
This fixes rhbz#1135372
Caught by covscan:
spice/server/spice_bitmap_utils.c:54: var_decl: Declaring variable "n_pixel_bits" without initializer.
spice/server/spice_bitmap_utils.c:106: uninit_use: Using uninitialized value "n_pixel_bits".
In reds_send_link_ack(), lookup the channel with the same id as the link
message.
The bug was found during code review a while ago.
A reproducer bug was later reported:
https://bugzilla.redhat.com/show_bug.cgi?id=1058625
When adding Opus support, SPICE_INTERFACE_PLAYBACK_FREQ and
SPICE_INTERFACE_RECORD_FREQ in the public header 'spice.h' were changed
from 44100 to 48000.
However, this was not really useful as these constants are not used in
spice-server, but only by users of spice-server (ie QEMU).
It turns out changing these values is actually harmful. QEMU uses these
constants in 2 situations:
1. when it's a version of QEMU with this commit, but we are compiling
against older spice-server headers (before Opus support was added)
2. when it's a version of QEMU without commit 795ca114d35 which added
what is needed for Opus support
When we are in the second situation, having 48000 in the public header
will actually cause issues as spice-server will know QEMU does not
support Opus, so internally spice-server will be using a 44100 rate for
audio. However, QEMU will be using SPICE_INTERFACE_.*_FREQ and think it
should use a 48000 rate, which will cause distorsions as experienced in
bug https://bugzilla.redhat.com/show_bug.cgi?id=1129961
Reverting these constants back to 44100 will fix audio in the 'new
spice-server/old QEMU' scenario, and won't cause issues either when both
support Opus as in this case these constants are not used.
The beginning of the surface data needs to be computed correctly if the
stride is negative, otherwise, it should point already to the beginning
of the surface data. This bug seems to exists since 4a208b (0.5.2)
https://bugzilla.redhat.com/show_bug.cgi?id=1029646
Some users have been reaching this error:
snd_receive: ASSERT n failed
A misbehaving client could easily hit that condition by sending too big
messages. Instead of assert(), replace with a warning. When a message
too big to fit is received, it will simply disconnect the channel.
https://bugzilla.redhat.com/show_bug.cgi?id=962187
If mjpeg_encoder_reset_quality() is called with the same quality as currently
set, it will not reset last_enc_size but not reset num_recent_enc_frames,
violating some assumptions in _adjust_params_to_bit_rate(). To avoid aborting
the server, simply return early from this function.
Resolves: rhbz#1086820
https://bugs.freedesktop.org/show_bug.cgi?id=79246
As a developer, I maybe want to see the detail compress stat of spice, like this:
Method count orig_size(MB) enc_size(MB) enc_time(s)
QUIC 846 948.02 147.22 7.51
GLZ 2895 594.90 26.60 1.33
ZLIB GLZ 0 0.00 0.00 0.00
LZ 1 3.15 0.01 0.00
JPEG 0 0.00 0.00 0.00
JPEG-RGBA 0 0.00 0.00 0.00
----------------------------------------------------------------------------
Total 3742 1546.07 173.83 8.84
But when I uncommented the COMPRESS_STAT and COMPRESS_DEBUG in red_worker.c and make.
I got some error(in Bugzilla). This error because of some simple syntax errors.
Commit this patch to fix this issue.
Signed-off-by: Wang Qiang <wangqiang.hunan@gmail.com>
gcc's some integer type definitions are different between 32/64bit system.
This causes platform dependency problem with printf function. However,
we can avoid this problem by using PRI macros that supports platform
independent printf.
9feed69 moved the async reader code to RedsStream so that it can be used
for the SASL authentication code. In particular, it introduced a
RedsStream::async_read member which is used by the SASL authentication code
for its async operations.
However, what was not done is to remove the now redundant
RedLinkInfo::async_read field. This causes failures when using SASL
authentication as the async read error callback is getting set
on the RedLinkInfo::async_read structure, but then the SASL code is trying
to use the RedeStream::async_read structure for its async IOs, which do not
have the needed error callback set.
This commit makes use of the newly introduced reds_stream_async_read()
helper in order to make use of RedsStream::async_read.
This replaces async_read_set_error_handler() which was unused. This sets a
callback to be called when an async operation fails.
We could pass the error_handler to each reds_stream_async_read() call, but as
we will be using the same one for all async calls, it's more convenient to set it
once and for all.
AsyncRead is going to be private to reds_stream.c in one of the next
commits, and the error handler will need to be set from reds.c,
hence the move to a public RedsStream method.
There are 2 SASL-related function prototypes which are unused in the
--without-sasl case. They cause a warning, and a build failure
when using -Werror. Wrapping them in #if HAVE_SASL avoids this issue.
This can fail in fips mode for example. If we ignore the failure, we'll get
a crash:
#0 0x00007f38d63728a0 in BN_num_bits () from /lib64/libcrypto.so.10
#1 0x00007f38d639661d in RSA_size () from /lib64/libcrypto.so.10
#2 0x00007f38d7991762 in reds_handle_read_link_done () from /lib64/libspice-server.so.1
#3 0x00007f38d7990c06 in spice_server_add_client () from /lib64/libspice-server.so.1
#4 0x00007f38d7990c6a in reds_accept () from /lib64/libspice-server.so.1
#5 0x00007f38dc0d2946 in qemu_iohandler_poll (pollfds=0x7f38dedce200, ret=755449965, ret@entry=1) at iohandler.c:143
#6 0x00007f38dc0d6ea8 in main_loop_wait (nonblocking=<optimized out>) at main-loop.c:465
#7 0x00007f38dbffd7c0 in main_loop () at vl.c:1988
#8 main (argc=<optimized out>, argv=<optimized out>, envp=<optimized out>) at vl.c:4357
This commit will cause the client connection to fail but qemu won't
segfault.
static void _spice_timer_set(SpiceTimer *timer, uint32_t ms, uint32_t now)
The _spice_timer_set() function takes a 32-bit integer for the "now" value.
The now value passed in however, can exceed 2^32 (it's in ms and derived
from CLOCK_MONOTONIC, which will wrap around a 32-bit integer in around 46
days).
If the now value passed in exceeds 2^32, this will mean timers are inserted
into the active list with expiry values before the current time, they will
immediately trigger, and (if they don't make themselves inactive) be
reinserted still before the current time.
This leads to an infinite loop in spice_timer_queue_cb().
https://bugzilla.redhat.com/show_bug.cgi?id=1072700
For example, with qemu, a webdav channel can be created this way:
-chardev spiceport,name=org.spice-space.webdav.0,...
And redirected to a virtio port:
-device virtserialport,...,name=org.spice-space.webdav.0
When trying to start mjpeg compression mode, mjpeg_encoder_start_frame()
tests the image format as its only able to compress 24/32bpp images. On
images with lower bit depths, we return MJPEG_ENCODER_FRAME_UNSUPPORTED to
indicate this is not a format we can compress. However, this return goes
with a spice_warning("unsupported format"). As the rest of the code can
cope with this unsupported format by not doing mjpeg compression, it's
nicer to downgrade this spice_warning() to spice_debug().
This fixes https://bugzilla.redhat.com/show_bug.cgi?id=1070028
The private data is allocated at the same time as RedsStream and
goes immediatly after the main RedsStream data.
This private member will allow to hide internal RedsStream
implementation details from the rest of spice-server.
SASL authentication mostly use members from RedsStream to do its work, so
it makes sense to have its code in reds_stream.c. This should allow to make
RedsStream::sasl private in the future.
The AsyncRead structure in reds.h wraps an async read + callback to
be done on a stream. Moving it to reds_stream.h is needed in order
to move SASL authentication there.
Now that stream creation and SSL enabling are done by helpers
in reds_stream.c, we can move the initialization of the vfunc
read/write pointers there too.
Initializing a new stream means initializing quite a few fields.
This commit factors this initialization in a dedicated reds_stream_new
helper. This also helps moving more code from reds.c to reds_stream.c
test-display-streaming is calling malloc() without checking its return
value. Coverity warns about this. This commit switches to g_malloc() to
sidestep this warning (g_malloc() never returns NULL but aborts instead).
When creating a TLS socket, both spice-server and spice-gtk currently
call SSL_CTX_new(TLSv1_method()). The TLSv1_method() function set the
protocol version to TLS 1.0 exclusively. The correct way to support
multiple protocol versions is to call SSLv23_method() in spite of its
scary name. This method will enable all SSL/TLS protocol versions. The
protocol suite may be further narrowed down by setting respective
SSL_OP_NO_<version_code> options of SSL context. This possibility is
used in this patch in order to block use of SSLv3 that is enabled by
default in openssl for client sockets as of now but spice has never used
it.
This file was added in bc50ff076 a few months ago, but is not listed
in Makefile.am, and thus not part of tarballs. However, it's being included
from other C files, so not having it causes compilation breakage.
reds_handle_ticket uses a fixed size 'password' buffer for the decrypted
password whose size is SPICE_MAX_PASSWORD_LENGTH. However,
RSA_private_decrypt which we call for the decryption expects the
destination buffer to be at least RSA_size(link->tiTicketing.rsa)
bytes long. On my spice-server build, SPICE_MAX_PASSWORD_LENGTH
is 60 while RSA_size() is 128, so we end up overflowing 'password'
when using long passwords (this was reproduced using the string:
'fullscreen=1proxy=#enter proxy here; e.g spice_proxy = http://[proxy]:[port]'
as a password).
When the overflow occurs, QEMU dies with:
*** stack smashing detected ***: qemu-system-x86_64 terminated
This commit ensures we use a corectly sized 'password' buffer,
and that it's correctly nul-terminated so that we can use strcmp
instead of strncmp. To keep using strncmp, we'd need to figure out
which one of 'password' and 'taTicket.password' is the smaller buffer,
and use that size.
This fixes rhbz#999839
It's depending on an unmaintained package (slirp), and I don't
think anyone uses that code. It's not tested upstream nor in fedora,
so let's remove it.
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.
This commit reuse several macros from libvirt to test for
support for "-Wl,-z -Wl,relro", "-Wl,-z -Wl,now" and
"-Wl,--no-copy-dt-needed-entries", and use them if available.
Releasing modifiers keys unconditionally on disconnect leads to
unexpected guest wakeups. To improve the situation, the server can
release only the pressed keys, which will prevent the wakeup in most
cases.
Furthermore, it's not sufficient to release only the modifiers keys.
Any key should be released on client disconnect to avoid sticky key
press across connections.
https://bugzilla.redhat.com/show_bug.cgi?id=871240
rhbz#1004443
The methods that trigger waitings on the client pipe require that
the waiting will succeed in order to continue, or otherwise, that
all the living pipe items will be released (e.g., when
we must destroy a surface, we need that all its related pipe items will
be released). Shutdown of the socket will eventually trigger
red_channel_client_disconnect (*), which will empty the pipe. However,
if the blocking method failed, we need to empty the pipe synchronously.
It is not safe(**) to call red_channel_client_disconnect from ChannelCbs
, but all the blocking calls in red_worker are done from callbacks that
are triggered from the device.
To summarize, calling red_channel_client_disconnect instead of calling
red_channel_client_shutdown will immediately release all the pipe items that are
held by the channel client (by calling red_channel_client_pipe_clear).
If red_clear_surface_drawables_from_pipe timeouts,
red_channel_client_disconnect will make sure that the surface we wish to
release is not referenced by any pipe-item.
(*) After a shutdown of a socket, we expect that later, when
red_peer_handle_incoming is called, it will encounter a socket
error and will call the channel's on_error callback which calls
red_channel_client_disconnect.
(**) I believe it was not safe before commit 2d2121a170 (before adding ref
count to ChannelClient). However, I think it might still be unsafe, because
red_channel_client_disconnect sets rcc->stream to NULL, and rcc->stream
may be referred later inside a red_channel_client method unsafely. So instead
of checking if (stream != NULL) after calling callbacks, we try to avoid
calling red_channel_client_disconnect from callbacks.
(1) merge 'force' and 'wait_for_outgoing_item' to one parameter.
'wait_for_outgoing_item' is a derivative of 'force'.
(2) move the call to red_wait_outgoing_item to red_clear_surface_drawables_from_pipe
client/Makefile.am:199: warning: 'INCLUDES' is the old name for 'AM_CPPFLAGS' (or '*_CPPFLAGS')
server/tests/Makefile.am:3: warning: 'INCLUDES' is the old name for 'AM_CPPFLAGS' (or '*_CPPFLAGS')
After eb09c25c, red_parse_qxl.c still has some spice_error() which
will kill the server even though the code is trying to return an error
when the spice_error() is hit.
This commit replaces these occurrences with a spice_warning() which
will not kill spice-server.
bitmap_consistent should return true or false.
Currently it aborts instead of returning false, due to spice_error.
Replacing spice_error with spice_warning, provides information and returns
false, as expected.
This fixes Fedora bz#997932
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.
For channels that don't run as part of the main loop, we use
spice_timer_queue, while for the other channels we use
qemu timers support. The callbacks for setting timers are supplied to
red_channel via SpiceCoreInterface, and their behavior should be
consistent. qemu timers are called only once per each call to
timer_start. This patch assigns the same behaviour to spice_timer_queue.
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
setting DRAW_ALL define doesn't produce correct rendering. Using
update_area instead of red_draw_qxl_drawable will work but it shouldn't
be required. This is not work I intend to do right now, so marking it
for anyone looking at this in the future.
150 seconds is way too long period for holding the guest driver and
waiting for a response for the client. This timeout was 15 seconds, but
when off-screen surfaces ware introduced it was arbitrarily multiplied by
10.
Other existing related bugs emphasize why it is important to decrease
the timeout:
(1) 994211 - the qxl driver waits for an async-io reponse for 60 seconds
and after that, it switches to sync-io mode. Not only that the
driver might use invalid data (since it didn't wait for the query to
complete), falling back to sync-io mode introduces other errors.
(2) 994175 - spice server sometimes doesn't recognize that the client
has disconnected.
(3) There might be cache inconsistency between the client and the server,
and then the display channel waits indefinitely for a cache item (e.g., bug
977998)
This patch changes the timeout to 30 seconds. I tested it under wifi +emulating 2.5Mbps network,
together with playing video on the guest and changing resolutions in a loop. The timeout didn't expired
during my tests.
This bug is related to rhbz#964136 (but from rhbz#964136 info it is still not
clear why the client wasn't responsive).
The snd channels has one reference as long as their socket is active.
The playback channel has an additional reference for each frame that is
currently filled by the sound device.
Once the channel is disconnected (the socket has been freed and the
first reference is released) snd_disconnect_channel shouldn't release
a reference again.
When the sequence of calls bellow occurs, the PlaybackChannel
is not released (snd_channel_put is not called for the
samples that refer to the channel).
spice_server_playback_get_buffer
snd_channel_disconnect
spice_server_playback_put_samples
When we want to disconnect the main channel from a callback, it is
safer to use red_channel_client_shutdown, instead of directly
destroying the client. It is also more consistent with how other
channels treat errors.
red_channel_client_shutdown will trigger socket error in the main channel.
Then, main_channel_client_on_disconnect will be called,
and eventually, main_dispatcher_client_disconnect.
I didn't replace calls to reds_disconnect/reds_client_disconnect in
places where those calls were safe && that might need immediate client
disconnection.
Fixes rhbz#918169
Some channels make direct calls to reds/main_channel routines. If
these routines try to read/write to the socket, and they get socket
error, main_channel_client_on_disconnect is called, and triggers
red_client_destroy. In order to prevent accessing expired references
to RedClient, RedChannelClient, or other objects (inside the original call, after
red_client_destroy has been called) I made the call to
red_client_destroy asynchronous with respect to main_channel_client_on_disconnect.
I added MAIN_DISPATCHER_CLIENT_DISCONNECT to main_dispatcher.
main_channel_client_on_disconnect pushes this msg to the dispatcher,
instead of calling directly to reds_client_disconnect.
The patch uses RedClient ref-count in order to handle a case where
reds_client_disconnect is called directly (e.g., when a new client connects while
another one is connected), while there is already CLIENT_DISCONNECT msg
pending in the main_dispatcher.
Examples:
(1) snd_worker.c
snd_disconnect_channel()
channel->cleanup() //snd_playback_cleanup
reds_enable_mm_timer()
.
.
main_channel_push_multi_media_time()...socket_error
.
.
red_client_destory()
.
.
snd_disconnect_channel()
channel->cleanup()
celt051_encoder_destroy()
celt051_encoder_destory() // double release
Note that this bug could have been solved by changing the order of
calls: e.g., channel->stream = NULL before calling cleanup, and
some other changes + reference counting. However, I found other
places in the code with similar problems, and I looked for a general
solution, at least till we redesign red_channel to handle reference
counting more consistently.
(2) inputs_channel.c
inputs_connect()
main_channel_client_push_notify()...socket_error
.
.
red_client_destory()
.
.
red_channel_client_create() // refers to client which is already destroyed
(3) reds.c
reds_handle_main_link()
main_channel_push_init() ...socket error
.
.
red_client_destory()
.
.
main_channel_client_start_net_test(mcc) // refers to mcc which is already destroyed
This can explain the assert in rhbz#964136, comment #1 (but not the hang that occurred before).
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)".
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
In this case, make syntax-check is wrong, and we actually do
need the cast.
A cast is needed when types are uint64_t <--> pointer
Using a local "ptr" variable makes both gcc and syntax-check happy.
Earlier in this function, test->target_surface is set to 1, which
is the only allowed non-primary surface currently.
If surface parameters are given (and specifically data is checked)
they are being used, otherwise a default surface is used.
Earlier in this function, "command" is set to a non-NULL value.
Thus, the else part was unreachable code, which is fixed now.
When surface_id == 0, primary is used.
Otherwise (currently 1), secondary is used.
Also, remove unused test_width and test_height.
Since commit caea769943,
test->width and test->height are used.
This was originally intended to fix the problem fixed by
commit 53488f0275.
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).
Specifically, the loop in red_pipes_add_draw can cause spice to abort.
In red_worker.c (WORKER_FOREACH_DCC):
red_pipes_add_drawable
red_pipe_add_drawable
red_handle_drawable_surfaces_client_synced
red_push_surface_image
red_channel_client_push
red_channel_client_send
red_peer_handle_outgoing
reds_stream_writev (if fails -- EPIPE)
handler->cb->on_error = red_channel_client_disconnect()
red_channel_remove_client()
ring_remove() -- of rcc from channel.clients ring.
RCC_FOREACH may be dangerous
The following patches replace FOREACH loops with a SAFE version.
Using unsafe loops may cause spice-server to abort (assert fails).
Specifically a read/write fail in those loops, may cause the client
to disconnect, removing the node currently iterated, which cause spice
to abort in ring_next():
-- assertion `pos->next != NULL && pos->prev != NULL' failed
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>
The image descriptor flags shouldn't be copied as is from the flags that
were set by the driver. Specifically, the CACHE_ME flag shouldn't be copied,
since it is possible that (a) the image won't be cached (b) the image
is already cached, but in its lossy version, and we may want to set the bit for
CACHE_REPLACE_ME, in order to cache it in its lossless version.
In case (b), the client first looks for the CACHE_ME flag, and only if
it is not set it looks for CACHE_REPLACE_ME (see canvas_base.c). Since both flags where set,
the client ignored REPLACE_ME, and didn't turned off the lossy flag of the
cach item. Then, when a request from this lossles item reached the
client (FROM_CACHE_LOSSLESS), the client display channel waited
endlessly for the lossless version of the image.
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
If client_migrate_info was called once with cert-host-subject and
then again without cert-host-subject, on a third call to
client_migrate info, the cert-host-subject from the first call would
have been freed for the second time.
It's not always obvious what address spice-server will bind to,
in particular when the 'addr' parameter is omitted on QEMU
commandline. The decision of what address to bind to is made
in reds_init_socket with a call to getaddrinfo. Surprisingly,
that function had a call to getnameinfo() already, but it does
not seem to be using the result of that call in any way.
This commit moves this call after the socket is successfully bound
and add a log message to indicate which address it's bound to.
When setting an initial video stream bit rate, if the bit rate
wasn't calculated by main_channel_client, and we don't have
estimation from previos streams, use some default values.
The patch also removes updating dcc->streams_max_bit_rate when
the bit_rate held by the main_channel is larger than it. It is not necessary
since we compare those 2 values each time we set the initial bit rate
for a stream.
spice_channel_client_error prints warning and shutdowns the
channel_client that hit the error.
This macro is useful for errors that are specific for one session
and that are unrecoverable only with respect to this session.
Prefer disconnecting a client over aborting when possible.
rhbz#956345
After a spice session has been migrated, we don't retest the network
(user experience considerations). Instead, we obtain the is_low_bandwidth flag
from the src-server, via the migration data.
Before this patch, if we migrated from server s1 to s2 and then to s3,
and if the connection to s1 was a low bandwidth one, we erroneously
passed is_low_bandwidth=FALSE from s2 to s3.
Cc: Marc-André Lureau <marcandre.lureau@redhat.com>
Replace the mixed calls to display_channel_client_is_low_bandwidth
and to main_channel_client_is_low_bandwidth, with one flag in
CommonChannelClient that is set upon channel creation.
red_create_stream is called even without any client but there is no
encoding since the mjpeg encoder is now associated with StreamAgent
which is only created when we have a client.
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).
This bug results in the client dropping all the video frames after
migration in case that (1) the hosts involved in migration have different
mm-time; and that (2) there is no audio playback.
This is relvant only for the client that was connected during the
migration.
rhbz#958276
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.
With a SPICE_DISPLAY_CAP_MONITORS_CONFIG capable client, the client needs to
know what part of the primary to use for each monitor. If the guest driver
does not support this, the server sends messages to the client for a
single monitor spanning the entire primary.
As soon as the guest calls spice_qxl_monitors_config_async once, we set
the red_worker driver_has_monitors_config flag and stop doing this.
This is a problem when the driver gets unloaded, for example after a reboot
or when switching to a text vc with usermode mode-setting under Linux.
To reproduce this start a multi-mon capable Linux guest which uses
usermode mode-setting and then once X has started switch to a text vc. Note
how the client window does not only not resize, if you try to resize it
manually you always keep blackborders since the aspect is wrong.
This patch is the spice-server side of fixing this, it adds a new
spice_qxl_driver_unload method which clears the driver_has_monitors_config
flag.
The other patch needed to fix this is in qemu, and will calls this new method
from qxl_enter_vga_mode.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
mjpeg_encoder modify the initial bit we supply it, according to the
client feedback. If it reaches a bit rate which is higher than the
initial one, we use the higher bit rate as the new bit rate estimation.
When there is no audio playback, we set the mm_time in the client to be older
than the one in the server by at least the requested latency (the delta is
actually bigger, due to the network latency).
When there is an audio playback, we adjust the mm_time in the client by
adjusting the playback buffer using SPICE_MSG_PLAYBACK_LATENCY.
A frame can be dropped if a new frame was added during the same
call to red_process_command (we didn't attempt to send the older
frame). Such drops are ignored.
This patch only employs setting the stream parameters based on
the initial given bit-rate, the latency, and the encoding size.
Later patches will also employ mjpeg_encoder response to client reports,
and its control over frame drops.
The patch also removes old stream bit rate calculations that weren't
used.
The stream starts after lossless frames were sent to the client,
and without rate control (except for pipe congestion). Thus, on the beginning
of the stream, we might observe frame drops on the client and server side which
are not necessarily related to mis-estimation of the bit rate, and we would
like to wait till the stream stabilizes.
The actual frames distribution does not necessarily fit the
condition "at least one frame every (1000/rate_contorl->fps)
milliseconds".
For keeping the average frame rate close to the defined fps, we
periodically measure the current average fps, and modify
rate_control->adjusted_fps accordingly. Then, we use
(1000/rate_control->adjusted_fps) as the interval between the
frames.
The required client playback latency is assessed based on the current
estimation of the bit rate, the network latency, and the encoding size
of the frames. When the playback delay that is reported by the client
seems too small, or when the stream parameters change, we send the
client an updated playback latency estimation.
mjpeg_encoder can receive periodic reports about the playback status on
the client side. Then, mjpeg_encoder analyses the report and can
increase or decrease the stream bit rate, depending on the report.
When the bit rate is changed, the quality and frame rate of the stream
are re-evaluated.
Previously, the mjpeg quality was always 70. The frame rate was
tuned according to the frames' congestion in the pipe.
This patch sets the quality and frame rate according to
a given bit rate and the size of the first encoded frames.
The following patches will introduce an adaptive video streaming, in which
the bit rate, the quality, and the frame rate, change in response to
different parameters.
Patches that make red_worker adopt this feature will also follow.
The mjpeg_encoder should be client specific, and not shared between
different clients**, for the following reasons:
(1) Since we use abbreviated jpeg datastream for mjpeg, employing the same
mjpeg_encoder for different clients might cause errors when the
clients decode the jpeg data.
(2) The next patch introduces bit rate control to the mjpeg_encoder.
This feature depends on the bandwidth available, which is client
specific.
** at least till we change multi-clients not to re-encode the same
streams.
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>
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.
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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.
resolves: rhbz#891326
Starting from commit 81fe00b08a, 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).
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"
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.
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.
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_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
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 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
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.
rhbz#876685
The current lz implementation does not support such bitmaps.
The following patch will actually prevent allocating stride > bpp*width
for internal images.
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_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.
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.
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.
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.
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)
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.
This solves a problem with new spice-server and old qemu-kvm, where spice thinks
qif->client_monitors_config exists, while it does not exist in qemu-kvm.
Also "major > required_major" was added to the condition.
Also only the specific RedDispatcher is checked (and not all dispatchers).
The client will send 0x000000## codes for regular keys, and 0x0000##e0 codes
for extended keys. The current code which simply walks the uint32_t code in
memory order relies on the memory order being little endian, which will
clearly fail on big endian machines, this fixes this.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
snd_channel_put freed "channel", and then channel->worker was accessed.
It caused segmentation faults during connections and disconnections of the client.
This caused a jenkins build failure:
snd_worker.c:148: error: redefinition of typedef 'PlaybackChannel'
snd_worker.c:126: note: previous declaration of 'PlaybackChannel' was here
The client of _get_buffer() holds a ref to the SndChannel, and we
should access that SndChannel when _put_samples() is called, not the one
that happens to currently be attached to the Interface.
When we release the SndChannel reference during
snd_disconnect_channel(), we need to set the pointer to NULL so it
doesn't get released again on client reconnect during
snd_set_playback_peer(). This can happen when a reference is held from
_playback_get_buffer().
This used to abort with spice_error. The caller currently does
not check spice_server_char_device_add_interface return value, but
it's still cleaner to report an error in this case.
Errors occurring in reds_init_ssl used to be fatal through the use
of spice_error, but this was downgraded to non-fatal spice_warning
calls recently. This means we no longer error out when invalid SSL
(certificates, ...) parameters are passed by the user.
This commit changes reds_init_ssl return value from void to int so
that errors can be reported to the caller.
We used to be aborting in such situations, but this was changed
during the big spice_error/printerr cleanup. We are currently
outputting a warning but not reporting the error with the caller
when reds_init_net fails to register listening watches with the
mainloop. As it's unlikely that things will work as expected in
such cases, better to error out of the function instead of pretending
everything is all right.
BN_new returns NULL on allocation failures. Given that we abort
on malloc allocation failures, we should also abort here. The
current code will segfault when BN_new fails as it immediatly tries
to use the NULL pointer.
If the guest supports client monitors config we pass it the
VDAgentMonitorsConfig message via the
QXLInterface::client_monitors_config api instead of via the vdagent.
Adds two functions:
- red_dispatcher_use_client_monitors_config:
check that QXLInterface supports client_monitors_config and that it's
functional.
- red_dispatcher_client_monitors_config:
send the client monitors configuration to the guest.
Used to implement guest monitor configuration change similarly to real
hardware in conjunction with the new qemu interrupt
QXL_INTERRUPT_CLIENT_MONITORS_CONFIG. client_monitors_config is also
used to probe the support by the interface. If it is not supported we
send the message to the guest agent.
This makes a linux qxl driver similar to existing kms drivers.
The logic is:
For every received VDAgentMonitorsConfig:
if client_monitors_config(NULL):
write client configuration to pci rom BAR.
send interrupt to guest
guest kernel reads configuration from rom BAR.
guest kernel issues event to user space
user space reads (libdrm) and reconfigures (libXRandr)
else: (current implementation)
write message to guest agent
guest agent issues reconfiguration via XRandr / windows Escape ioctl to kernel
No new symbols are added, but there is an addition to QXLInterface:
void (*set_client_capabilities)(QXLInstance *qin,
uint8_t client_present,
uint8_t caps[58]);
When a new client connects, there may be commands in the ring that it
can't understand, so we need to process these before forwarding new
commands to the client. By doing this after changing the capability
bits we ensure that the new client will never see a command that it
doesn't understand (under the assumption that the guest will read and
obey the capability bits).
Acked-by: Alon Levy <alonl@redhat.com>
A new interface
set_client_capabilities (QXLInstance *qin,
uint8_t client_present,
uint8_t caps[58]);
is added to QXLInstance, and spice server is changed to call it
whenever a client connects or disconnects. The QXL device in response
is expected to update the client capability bits in the ROM of the
device and raise the QXL_INTERRUPT_CLIENT interrupt.
There is a potential race condition in the case where a client
disconnects and a new client with fewer capabilities connects. There
may be commands in the ring that the new client can't handle. This
case is handled by first changing the capability bits, then processing
all commands in the ring, and then start forwarding commands to the
new client. As long as the guest obeys the capability bits, the new
client will never see anything it doesn't understand.
Just checks stride vs width times bpp.
This fixes a potential abort on guest generated bad images in
glz_encoder.
Other files touched to move some consts to red_common, they are
static so no problem to be defined in both red_worker.c and
red_parse_qxl.c .
replace add_ref with add for stack allocated SpiceMigrateDataDisplay.
This fixes wrong MIGRATE_DATA message in display channel (symptom is
glz_encoder_max being way too big, and malloc failure at target) seen on
F18 with gcc-4.7.1-5.fc18.x86_64 and glibc-2.16-8.fc18.x86_64 (didn't
appear on RHEL 6).
Storing the motion count in uint16_t and not in uint32_t since
the exact count is not important, just its division in
SPICE_INPUT_MOTION_ACK_BUNCH (see the next 2 patches).
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.
The playback and record channel send SPICE_MSG_MIGRATE to the client.
Both playback and record channel does not have a state to restore:
while in the legacy migration implementation the record channel
used to restore the mode and start time, it looks unnecessary since
the client receives from the src MSG_RECORD_STOP before the migration
completion notification (when the vm is stopped). Afterwards, when the vm
starts on the dest side, the client receives MSG_RECORD_START.
Due to the fix in the previous patch, snd_disconnect_channel can be
called both when there is write/read error in the channel, or from
red_client_destroy (which calls client_cbs.disconnect).
Multiple calls to snd_disconnect_channel resulted in calling
channel->cleanup(channel) more than once (double release).
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
A channel pipe item type must start from PIPE_ITEM_TYPE_CHANNEL_BASE.
SPICE_MSG_MIGRATE value eq. PIPE_ITEM_TYPE_SET_ACK. Setting a pipe item
type to SPICE_MSG_MIGRATE, leads to red_channel handling PIPE_ITEM_TYPE_SET_ACK.
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.
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.
A channel pipe item type must start from PIPE_ITEM_TYPE_CHANNEL_BASE.
SPICE_MSG_MIGRATE value eq. PIPE_ITEM_TYPE_SET_ACK. Setting a pipe item
type to SPICE_MSG_MIGRATE, leads to red_channel handling PIPE_ITEM_TYPE_SET_ACK.
Also removed sending SPICE_MSG_MIGRATE. It will be handled in the next
patch.
Attach/detach a client to a SpiceCharDeviceState upon its
connection/disconnection, instead of upon reader_add/remove messages.
When the client is removed from a SpiceCharDeviceState, all the
messages from this client are removed from the device write queue.
This shouldn't happen when we only receive reader_remove and the
client is still connected.
When restoring migration data, we also restore data that is addressed to
the device, and that might have been originated from more than 1
message. When the write buffer that is assoicated with this data is
released, we need to free all the relevant tokens.
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.
In semi-seamless, SPICE_MSG_MAIN_MIGRATE_END is sent.
In seamless, each channel migrates separately.
The src waits till all the clients are disconnected (or a timeout), and
then it notifies qemu that spice migration has completed.
The patch doesn't include the per-channel logic for seamless migration
(sending MSG_MIGRATE, MIGRATE_DATA, etc.).
- handle SPICE_MSGC_MAIN_MIGRATE_DST_DO_SEAMLESS
- reply with SPICE_MSG_MAIN_MIGRATE_DST_SEAMLESS_ACK/NACK
- prepare the channels for migration according to the migration
type (semi/seamless)
see spice-protocol for more details:
commit 3838ad140a046c4ddf42fef58c9727ecfdc09f9f
sending SPICE_MSG_MAIN_MIGRATE_BEGIN_SEAMLESS and handling
SPICE_MSGC_MAIN_MIGRATE_CONNECTED_SEAMLESS
The src side signals the client to establish a connection
to the destination.
In seamless migration, the client is also used to perform
a sort of handshake with the destination, for verifying
if seamless migration can be supported.
see spice-protocol for more details:
commit 3838ad140a046c4ddf42fef58c9727ecfdc09f9f
The file will hold the declarations of the different migration
data messages (depending on the channel), that will be passed
from the src server to the dst server, via the client, using
SPICE_MSG_MIGRATE_DATA.
This new call is used in order to identify whether qemu, or
the management (e.g. libvirt), support seamless migration.
If it is supported, qemu spice cmd-line configuration should have
seamless-migration=on.
In addition, we disable seamless migration support if multiple clients
are allowed. Currently, only one client is supported.
Till now, red_worker was notfied about vm status changes via QXLWorker->start/stop
(or spice_qxl_start/stop).
Newer qemu, that supports calling spice_server_vm_start/stop, will call only
these routines, and won't call QXLWorker->start/stop.
When vm state changes (started/stopped), we notify all the
attached SpiceCharDeviceStates about the change. This is mainly required
for avoiding writing/reading to/from the device during the non-live
stage of migration.
spice version will be bumped in one of the following patches.
The list of attached char_devices will be used in the next patch
for notifying each instance of SpiceCharDeviceState when the vm
is started or stopped.
Graduality is irrelevant for A8 images, so instead of using RGB-ness
as a short-cut, add a new macro BITMAP_FMT_HAS_GRADUALITY() that
returns true for the existing RGB images, but false for A8.
After marshalling MSG_STREAM_CREATE, there is no need to ref and
unref stream->current before and after completing the sending of the
message (correspondingly). The referencing is unnecessary because all
the data that is required from the drawable (the clipping), is copied
during marshalling, and no field in the drawable is referenced (see
spice_marshall_msg_display_stream_create).
Moreover, the referencing was bugous:
While display_channel_hold_pipe_item and
display_channel_client_release_item_after_push referenced and
dereferenced, correspondingly, stream->current, stream->current might
have changed in between these calls, and then we ended up with one drawable
leaking, and one drawable released before its time has come (which
of course led to critical errors).
a SpiceMsgDisplayMonitorsConfig is sent on two occasions:
* as a result of a spice_qxl_monitors_config_async
* whenever a client connects and there is a previously set monitors
config
Sending the new message is protected by a new cap,
SPICE_DISPLAY_CAP_MONITORS_CONFIG
More elaborately:
spice_qxl_monitors_config_async receives a QXLPHYSICAL address of a
QXLMonitorsConfig struct and reads it, caching it in the RedWorker, and
sending it to all clients. Whenever a new client connects it receives
a SpiceMsgDisplayMonitorsConfig message as well.
prevents division by zero later (SIGFPE, Arithmetic exception) in
spice-common code, at spice-common/common/canvas_base.c:646
for both client and server (server only upon rendering).
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).
Specifically all those that the previous patch converted to spice_debug.
spice_debug contains very verbose stuff like update_area that drowns out
those relatively rare (client connect / disconnect generated) messages.
With SpiceCharDeviceState, the smartcard code 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.
The lifetime of the channel is not necessarily correlated to the life
time of the device. In the next patch, we need to keep a reference
to SpiceCharDeviceWriteBuffer, which might be in use even if the
SpiceCharDeviceState is destroyed, but the channel is still connected.
The next patch keeps this reference inside SmartCardChannelClient.
This patch also removes the routine smartcard_readers_detach_all(rcc), which
is unnecessary since we don't support multiple readers; even when
we do support them, each channel client should be associated with only
one reader (i.e., we will have different channels for different
readers).
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).
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).
