| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
| |
It was introduced in 7e8e13593ee681cf04c349bca57dd225d7802494
but never used.
Signed-off-by: Pavel Grunt <pgrunt@redhat.com>
Acked-by: Fabiano Fidêncio <fidencio@redhat.com>
|
|
|
|
|
|
|
| |
It is not needed since 8e7b22b7861d2859167767822f29749bfe3ecc16
Signed-off-by: Pavel Grunt <pgrunt@redhat.com>
Acked-by: Fabiano Fidêncio <fidencio@redhat.com>
|
|
|
|
|
| |
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Pavel Grunt <pgrunt@redhat.com>
|
|
|
|
| |
Acked-by: Fabiano Fidêncio <fidencio@redhat.com>
|
|
|
|
| |
Acked-by: Frediano Ziglio <fziglio@redhat.com>
|
|
|
|
| |
Acked-by: Frediano Ziglio <fziglio@redhat.com>
|
|
|
|
|
| |
Acked-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Jonathon Jongsma <jjongsma@redhat.com>
|
|
|
|
| |
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
|
| |
|
| |
|
|
|
|
| |
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
|
|
|
|
| |
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
|
|
|
|
|
| |
This is a modified version of a patch initially from
Erlon R. Cruz <erlon.cruz@br.flextronics.com>
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
| |
By default, stream latency is 0 and bandwidth is infinite. On UNIX
socket do not perform unnecessary testing and keep those values.
|
|
|
|
| |
We don't modify the capabilities content, so it can be marked as const.
|
|
|
|
|
| |
The debug level is not visible by default, since it is an unsolicited
server behaviour, make it a warning.
|
|
|
|
| |
It was spelt 'capabilty'
|
|
|
|
|
| |
Gather common RedsStream code there rather than having it
in reds.c
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
| |
(1) receive timeout as a parameter.
(2) add a return value and pass the handling
of failures to the calling routine.
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
| |
The callback will be used in the next patch.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
has diconnected
Fixes: leaks of pipe items & "red_client_destroy: assertion `rcc->send_data.size == 0'"
red_channel_disconnect clears the pipe. It is called only once. After,
it was called, not items should be added to the pipe.
An example of when this assert can occur:
on_new_cursor_channel (red_worker.c), pushes 2 pipe items.
When it pushes the first pipe item, if the client has disconnected,
it can hit a socket error, and then, red_channel_client_disconnect is called.
The second call to adding a pipe item, will add the item to
the pipe. red_channel_client_pipe_add_type also calls
red_channel_client_push, which will update the send_data.size.
Then, the push will also hit a socket error, but red_channel_client_disconnect
won't clear the pending pipe item again, since it was already called.
When red_client_destory is called, we hit assertion `rcc->send_data.size
== 0'.
Note that if a pipe item is added to the pipe after
red_channel_client_disconnect was called, but without pushing it,
we should hit "spice_assert(rcc->pipe_size == 0)".
|
|
|
|
| |
unused variable 'so_unsent_size' [-Werror=unused-variable]
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
| |
This was originally intended to fix the problem fixed by
commit 53488f0275d6c8a121af49f7ac817d09ce68090d.
What is left are FOREACH loops that are at less risk and maybe safe (no
read/write or disconnect/destroy are called from within them).
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
| |
Those messages are too frequent and don't contribute much
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
handle_migrate_data fails
|
|
|
|
|
|
|
|
|
|
| |
client's migration has completed
The connection to the target server is established before migration
starts. However, the client reads and replies to messages from the server only after
migration completes. Thus, we better not send ping msgs from the target
before migration completes (because the observed roundtrip duration will
be bigger than the real one).
|
|
|
|
|
| |
We mustn't send any msg to the client, besides MSG_MIGRATE_DATA, after
we send MSG_MIGRATE.
|
|
|
|
|
|
|
| |
When a client disconnects, red_channel_client_pipe_clear is called.
Releasing pipe items of type == MIGRATE||EMPTY_MSG||PING
wasn't handled, and was passed to channel_cbs.release_item.
There, an error occured since the pipe items were not recognized.
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
red_channel_client_set_message_serial
red_channel_client_set_message_serial is called for setting
the serial of the display channel messages after migration (on the
destination side). The serial is retrieved from the migration data.
|
|
|
|
| |
The relevant flags reside in RedChannelClient and RedClient
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
| |
The pipe item is used for sending messages that don't have body.
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
| |
The relevant code is common to all channels.
The patch also contains a fix to the return value for
handle_migrate_data callback: s/uint64_t/int
|
| |
|
|
|
|
| |
for checking if all the channel clients connected support the cap
|
| |
|