These constants are meant to be used in format string for size_t
types. Use them for portability.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Snir Sheriber <ssheribe@redhat.com>
It was probably meant to be used as a "user_data" argument for the
various callbacks, but turns out not to be used.
Signed-off-by: Christophe Fergeau <cfergeau@redhat.com>
Acked-by: Frediano Ziglio <fziglio@redhat.com>
Client callbacks in sound channels do not use registered
data so don't pass a valid pointer making clear from
source that the parameter is not used.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Christophe Fergeau <cfergeau@redhat.com>
Without an explicit call to SSL_CTX_set_ecdh_auto(reds->ctx, 1), OpenSSL
1.0 (still used by el7) would not use ECDH ciphers (this is now
automatic with OpenSSL 1.1.0). This commit adds this missing call. It's
based on a suggestion from David Jasa
Signed-off-by: Christophe Fergeau <cfergeau@redhat.com>
Acked-by: Frediano Ziglio <fziglio@redhat.com>
https://bugzilla.redhat.com/show_bug.cgi?id=1566597
Most of pipe items use this name for the base field.
This also allows to use SPICE_UPCAST macros instead of a long
SPICE_CONTAINEROF.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Christophe Fergeau <cfergeau@redhat.com>
Although capabilities inside link message are handled as arrays
of 4 bytes unsigned integers we don't need capabilities to be
aligned to 4 bytes just to call g_memdup so use a pointer to
uint8_t instead.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Christophe Fergeau <cfergeau@redhat.com>
This array is just used locally in red_channel_client_handle_outgoing
so declare it there.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Christophe Fergeau <cfergeau@redhat.com>
Removes debug messages that are logged on every draw, spamming the log
excessively when debugging.
Signed-off-by: Lukáš Hrázký <lhrazky@redhat.com>
Acked-by: Christophe Fergeau <cfergeau@redhat.com>
From Gitlab CI:
=17955== 16 bytes in 1 blocks are possibly lost in loss record 725 of 2,079
==17955== at 0x4C2DBAB: malloc (vg_replace_malloc.c:299)
==17955== by 0x4011D17: tls_get_addr_tail.isra.0 (in /usr/lib64/ld-2.27.so)
==17955== by 0x4017997: __tls_get_addr (in /usr/lib64/ld-2.27.so)
==17955== by 0xEE4534B: gnutls_rnd (in /usr/lib64/libgnutls.so.30.20.2)
==17955== by 0xEE1F254: ??? (in /usr/lib64/libgnutls.so.30.20.2)
==17955== by 0xEE1F947: ??? (in /usr/lib64/libgnutls.so.30.20.2)
==17955== by 0xEE231B5: ??? (in /usr/lib64/libgnutls.so.30.20.2)
==17955== by 0xEE24D67: gnutls_handshake (in /usr/lib64/libgnutls.so.30.20.2)
==17955== by 0xEBD4FEA: ??? (in /usr/lib64/gio/modules/libgiognutls.so)
==17955== by 0x7463936: g_task_thread_pool_thread (gtask.c:1331)
==17955== by 0x7A3E932: g_thread_pool_thread_proxy (gthreadpool.c:307)
==17955== by 0x7A3DF29: g_thread_proxy (gthread.c:784)
==17955== by 0x8284563: start_thread (in /usr/lib64/libpthread-2.27.so)
==17955== by 0x859631E: clone (in /usr/lib64/libc-2.27.so)
==17955==
==17955== 32 bytes in 1 blocks are possibly lost in loss record 1,234 of 2,079
==17955== at 0x4C2DBAB: malloc (vg_replace_malloc.c:299)
==17955== by 0x4011D17: tls_get_addr_tail.isra.0 (in /usr/lib64/ld-2.27.so)
==17955== by 0x4017997: __tls_get_addr (in /usr/lib64/ld-2.27.so)
==17955== by 0xCAA5173: __cxa_get_globals (in /usr/lib64/libstdc++.so.6.0.25)
==17955== by 0xCAA6186: __cxa_throw (in /usr/lib64/libstdc++.so.6.0.25)
==17955== by 0xC601457: ??? (in /usr/lib64/libproxy.so.1.0.0)
==17955== by 0xC5F6BB6: ??? (in /usr/lib64/libproxy.so.1.0.0)
==17955== by 0xC5F7089: ??? (in /usr/lib64/libproxy.so.1.0.0)
==17955== by 0xC5F7470: px_proxy_factory_get_proxies (in /usr/lib64/libproxy.so.1.0.0)
==17955== by 0xC3E64E3: ??? (in /usr/lib64/gio/modules/libgiolibproxy.so)
==17955== by 0x7463936: g_task_thread_pool_thread (gtask.c:1331)
==17955== by 0x7A3E932: g_thread_pool_thread_proxy (gthreadpool.c:307)
==17955== by 0x7A3DF29: g_thread_proxy (gthread.c:784)
==17955== by 0x8284563: start_thread (in /usr/lib64/libpthread-2.27.so)
==17955== by 0x859631E: clone (in /usr/lib64/libc-2.27.so)
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Christophe Fergeau <cfergeau@redhat.com>
encode_32 already deals with endian, don't swap twice.
Tested with a ppc64 server machine and a x64 client.
This looks the reverse of a previous patch (59c6c82) supposed to fix big
endian machine. encode_32 has been always:
static inline void encode_32(Encoder *encoder, unsigned int word)
{
encode(encoder, (uint8_t)(word >> 24));
encode(encoder, (uint8_t)(word >> 16) & 0x0000ff);
encode(encoder, (uint8_t)(word >> 8) & 0x0000ff);
encode(encoder, (uint8_t)(word & 0x0000ff));
}
while encode basically is similar to a putc on a FILE stream so is writing
numbers from host endian to big endian order.
The "main" endian (the one more tested since ever) is host/guest being
little endian. So if you call encode_32 with a 0x01020304 you get 4 bytes
in the order 1, 2, 3, 4.
Before and after 59c6c82 LZ_MAGIC was defined as:
#define LZ_MAGIC (*(uint32_t *)"LZ ")
so on little endian this was 0x4c, 0x5a, 0x20, 0x20 that is 0x20205a4c
which written through encode_32 become 0x20, 0x20, 0x5a, 0x4c so we can say
that at the end on the network we must have 0x20, 0x20, 0x5a, 0x4c.
On big endian however LZ_MAGIC got the value 0x4c5a2020 which written
through encode_32 get 0x4c, 0x5a, 0x20, 0x20 which is the opposite
expected. So patch 59c6c82 reverted the order having again 0x20, 0x20,
0x5a, 0x4c on the network.
However commit 5a7e587 (spice-common), in an attempt to avoid double
swapping on LZ, changed LZ_MAGIC to
#define LZ_MAGIC 0x20205a4c
breaking endianness again for GLZ code.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Christophe Fergeau <cfergeau@redhat.com>
It's only called once, and when it's called, we will have dereferenced
worker->display_channel a few lines before in
display_channel_set_monitors_config_to_primary(), so this cannot be
NULL. The 'if (worker->display_channel)' check can thus be removed, so
display_is_connected() becomes just red_channel_is_connected().
Signed-off-by: Christophe Fergeau <cfergeau@redhat.com>
Acked-by: Frediano Ziglio <fziglio@redhat.com>
There's already a 'display' variable equal to worker->display_channel
which is not consistently used. This commit also adds a new 'channel'
local variable to limit the number of upcasts to RedChannel.
Signed-off-by: Christophe Fergeau <cfergeau@redhat.com>
Acked-by: Frediano Ziglio <fziglio@redhat.com>
This is reported by GCC 8.0.1 (Fedora 28).
Instead of doing a possible invalid cast destroy and create the
queue again.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Jonathon Jongsma <jjongsma@redhat.com>
Avoid casting function pointer with different argument providing
a proper utility instead.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Jonathon Jongsma <jjongsma@redhat.com>
With GCC 8.0.1 (Fedora 28), cast to different function pointer
can lead to warnings, like:
event-loop.c: In function ‘watch_update_mask’:
event-loop.c:146:42: error: cast between incompatible function types from ‘gboolean (*)(GIOChannel *, GIOCondition, void *)’ {aka ‘int (*)(struct _GIOChannel *, enum <anonymous>, void *)’} to ‘gboolean (*)(void *)’ {aka ‘int (*)(void *)’} [-Werror=cast-function-type]
g_source_set_callback(watch->source, (GSourceFunc)watch_func, watch, NULL);
^
cc1: all warnings being treated as errors
As g_source_set_callback expect a function pointer which type
changes based on the type of source (so is expected) silent
the possible warning.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Jonathon Jongsma <jjongsma@redhat.com>
When GLZ code attempts to send a 64 bit integer the 8 top bit of
the lower (32 bits) part of the number are stripped due to a bug.
This was discovered by Zhongqiang Huang <useprxf@gmail.com>
Reported-by: Zhongqiang Huang <useprxf@gmail.com>
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Jonathon Jongsma <jjongsma@redhat.com>
Although not necessary for a single monitor DisplayChannel implementation
this make the DisplayChannels more coherent from the client
point of view.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Jonathon Jongsma <jjongsma@redhat.com>
SpiceWhiteness/SpiceBlackness/SpiceInvers are 3 typedef for the same
type, no need to have 3 identical red_put_xxx/red_get_xxx methods.
Signed-off-by: Christophe Fergeau <cfergeau@redhat.com>
Acked-by: Frediano Ziglio <fziglio@redhat.com>
SpiceBlend is a typedef to SpiceCopy, and red_put_blend() and
red_put_copy() are identical, so we can add a #define red_put_blend
red_put_copy similar to the one we already have for red_get_blend.
Signed-off-by: Christophe Fergeau <cfergeau@redhat.com>
Acked-by: Frediano Ziglio <fziglio@redhat.com>
In order to use the new TCP_CORK feature, disable auto flush.
Depending on channel implementation and purpose of the channel enabling
blindly for all channels could cause performance issues, specifically if
flush is not done at the right time.
CommonGraphicsChannel channels were tested to make sure is not that case.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Christophe Fergeau <cfergeau@redhat.com>
Cork is a system interface implemented by Linux and some *BSD systems to
tell the system that other data are expected to be written to a socket.
This allows the system to reduce network fragmentation waiting for network
packets to be complete.
Using some replay capture and some instrumentation resulted in a
bandwith reduction of 11% and a packet reduction of 56%.
The tests was done using replay utility so results could be a bit different
from real cases as:
- replay goes as fast as it can, for instance packets could
be merged by the kernel decreasing packet numbers and a bit
byte spent (this actually make the following improves worse);
- there are fewer channels (no much cursor, sound, etc).
The following tests shows count packet and total bytes from server to
client using a real network. I used a direct cable connection using 1gb
connection and 2 laptops.
cork: 537 1582240
cork: 681 1823754
cork: 524 1583287
cork: 538 1582350
no cork: 1329 1834630
no cork: 1290 1829094
no cork: 1289 1830164
no cork: 1317 1833589
no cork: 1320 1835705
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Christophe Fergeau <cfergeau@redhat.com>
The writing to network was always immediate.
Every write in the stream causes a write to the OS.
This can have some penalty if you don't write large data as network
packets can be more fragmented or you encrypt data in smaller chunks
(when data are encrypted some padding is added then data is split in
multiple of encryption block which is usually the size of encryption
key and this is done for every write).
Define an interface to allow higher levels code to tell low level when
data should be sent to remote or when can wait more data.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Christophe Fergeau <cfergeau@redhat.com>
The name is more consistent with red_marshall_cursor_init.
Signed-off-by: Christophe Fergeau <cfergeau@redhat.com>
Acked-by: Frediano Ziglio <fziglio@redhat.com>
There's an implicit API/ABI contract between QEMU and SPICE that SPICE
will keep the guest QXL resources alive as long as QEMU can hold a
pointer to them. This implicit contract was broken in 1c6e7cf7 "Release
cursor as soon as possible", causing crashes at migration time.
While the proper fix would be in QEMU so that spice-server does not need
to have that kind of knowledge regarding QEMU internal implementation,
this commit reverts to the pre-1c6e7cf7 behaviour to avoid a regression
while QEMU is being fixed.
This version of the fix is based on a suggestion from Frediano Ziglio.
https://bugzilla.redhat.com/show_bug.cgi?id=1540919
Signed-off-by: Christophe Fergeau <cfergeau@redhat.com>
Acked-by: Frediano Ziglio <fziglio@redhat.com>
Code can have problems reading empty messages, check we can
handle it.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Christophe de Dinechin <dinechin@redhat.com>
Handle capabilities from guest device.
Send capability to the guest when device is opened.
Currently there's no capabilities set on the message sent.
On the tests we need to discard the capability message before
reading the error.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Christophe de Dinechin <dinechin@redhat.com>
This function will be reused to initialise different message
headers.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Christophe de Dinechin <dinechin@redhat.com>
Currently, red-parse-qxl.c uses g_malloc+memcpy to duplicate the cursor
data when it could use g_memdup() instead. red-stream-device.c does the
same thing but uses spice_memdup(). This commit makes use of g_memdup()
in both cases so that this memory is consistently allocated through
glib.
Signed-off-by: Christophe Fergeau <cfergeau@redhat.com>
The name 'com.redhat.stream.0' is too generic and in no way denotes it
belongs to SPICE. It is preferred to have the project's domain in the
name and Red Hat doesn't own the project. Rename it to
org.spice-space.stream.0.
Signed-off-by: Lukáš Hrázký <lhrazky@redhat.com>
Acked-by: Frediano Ziglio <fziglio@redhat.com>
Reuse option from common code.
Also reuse spice_extra_checks constant instead of using the preprocessor
macro directly.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Eduardo Lima (Etrunko) <etrunko@redhat.com>
The timeout is too short when the test run under Valgrind
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Christophe Fergeau <cfergeau@redhat.com>
In order to avoid confusion with file named stream-device.h, from
spice-protocol.
Signed-off-by: Eduardo Lima (Etrunko) <etrunko@redhat.com>
Acked-by: Frediano Ziglio <fziglio@redhat.com>
These factor a bit of common code, and more importantly, help with
freeing all event loop related data at the end of each test.
Signed-off-by: Christophe Fergeau <cfergeau@redhat.com>
This test case will be testing the external spice-server API to
configure the address/port it's listening on. For now it sets up a
listening server, spawns a thread which is going to connect to that
port, and check it gets the REDQ magic upon connection. It will be
extended to test for Unix sockets, TLS sockets, ...
Signed-off-by: Christophe Fergeau <cfergeau@redhat.com>
There is currently a debug printf which is always shown when a mainloop
event is triggered. This is unlikely to be useful unless one is
debugging the event loop code.
Signed-off-by: Christophe Fergeau <cfergeau@redhat.com>
