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>
Besides the code factorization, this will allow smartcard support to be
automatically enabled if libcacard is present and --disable-smartcard is
not used.
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 fixes a few issues with older python-six versions:
Christophe Fergeau (2):
configure.ac: Check for needed python modules for git builds
codegen: Use six.PY3 rather than six.PY2
configure.ac currently errors out when trying to build on
non-x86/non-ARM CPUs. Since the previous commits improved
big endian support a lot, this commit replaces the error
with a warning at configure time to make testing on big
endian platforms easier.
Alexander Wauck (1):
Make spice_codegen.py work on both Python 2 and 3
Christophe Fergeau (17):
Remove unused header file
build-sys: Remove unused X check
build-sys: Remove unused win32 check
build-sys: Remove unused WITH_SMARTCARD conditional
build-sys: Small cleanup of AM_CPPFLAGS
build-sys: Add fallback for AS_VAR_APPEND
build-sys: Move posix checks to a separate m4 macro
build-sys: Move smartcard check to m4 macro
build-sys: Move celt check to m4 macro
build-sys: Move opus check to m4 macro
build-sys: Move opengl check to m4 macro
build-sys: Move pixman check to m4 macro
Remove unused 'invers' arg from canvas_get_*
Remove redundant #if defined(SW_CANVAS_CACHE) ||
defined(SW_CANVAS_IMAGE_CACHE)
Remove another redundant (SW_CANVAS_CACHE) ||
(SW_CANVAS_IMAGE_CACHE) #ifdef
Get rid of SW_CANVAS_IMAGE_CACHE
ssl_verify: Move wincrypt.h related #ifdef closer to the include
Erlon Cruz (2):
ppc: Fix lz magic endianness
ppc: build-sys: Add big-endian support
Fabiano Fidêncio (1):
Fix typo in pixman_image_get_stride() function
Javier Celaya (6):
LZ4: Fix output buffer size
LZ4: Adjust reading the top_down flag
LZ4: Decode the image format from the stream
LZ4: Fix the row alignment when it is not on a 32bit boundary
LZ4: Add support for 24bit pixman surfaces
LZ4: Do not include arpa/inet.h in Windows builds
Victor Toso (1):
common: fix build with mingw
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>
My RHEL-6 gcc (4.4.7) complains a lot about it:
cc1: warning: command line option "-Wenum-compare" is
valid for C++/ObjC++ but not for C
For older gcc version (e.g. 4.4.7), man gcc says
-Wenum-compare is "C++ and Objective-C++ only".
For newer gcc (e.g. 4.9.2), man gcc says
"In C this warning is enabled by -Wall."
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.
SPICE_REQUIRES is only used to generate the Requires.private line of
spice-server.pc. The server code is not using xinerama, so we don't need
to list xinerama in Requires.private.
Xinerama support is only used for the X11 client, but is currently
being checked even for server only builds. This commit ensures Xinerama
is not checked for/added to spice-server.pc when not building the
client.
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"
^
