try to push either on signal (write available) or when blocked
and read signaled. From red_worker, copied for compatibility when
switching later to RedChannel in red_worker. Doesn't make a lot of
sense (but works), see comment in patch.
MAX_SEND_VEC was 100 for DisplayChannel's RedChannel implementation which is being replaced
with RedChannel in red_channel. So changing from 50 to 100 in red_channel
(make this configurble?) - effectively increased memory usage by:
(100-50)*sizeof(iovec)*(num_of_channels-2) ==(arch 64bit) 50*16*6 ~ 5k
Not terrible.
hold_item called on init_send_data, matching release.
This is not the behavior of red_worker - we ref++ (==hold_item) when
sending the item, and --refs when releasing it, instead of only holding
if the send is blocked.
Note 1: Naming: hold_pipe_item is the proc name, the variable is called
hold_item, this is similar to release_item/release_pipe_item naming.
Note 2: All channels have empty implementation, we later use this when
red_worker get's RedChannelized.
While we are at it: There is no reason for chardev
support to stay in the experimental area, so move it out.
qemu should not need the "spice-experimental.h" file.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Implement server-side support for switch-host client migration. Client
side support is present already in the tree.
Setting the migration information is done using the existing
spice_server_migrate_info() function. A new
spice_server_migrate_switch() function has been added which triggers
sending out the switch-host message.
Seamless migration functions are left there for now.
spice_server_migrate_start() has been chamnged to just fail
unconditionally though as seamless migration is broken anyway.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
drawable_count was becoming negative. It tracks the number of
items in the worker->current_list ring. It was decremented correctly,
but incremented only in several cases. The cases it wasn't incremented
where:
red_current_add_equal found an equivalent drawable
by moving the increment to where the item is added to current_list, in
__current_add_drawable, the accounting remains correct.
This has no affect other then correct accounting, as drawable_count isn't
used for anything.
We should pass up errors instead of aborting. Do that at least
for bind() failures which actually happen in real live due to the
tcp port being busy.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
We erronously ignored data from guest on the serial channel if no client is
connected. This leads to an assert when the guest writes a second time, since
there is still data unconsumed by us (the host).
Fix by reading data anyway, and discarding it after parsing (and reading) whole
messages from the guest.
Net affect is that any messages the agent sends while no client is connected
get discarded, but only full messages are discarded.
This fixes an abort if booting a winxp guest with vdagent without a connected
client.
updates taken from spice vga mode updates, i.e. non cacheable, glz compressed
(depends on whatever settings you apply to the server) opaque draw operations.
+ completed the SpiceCoreInterface implementation (timers)
v1->v2:
removed test_util.c (Hans)
replaced mallocz with calloc (Hans)
We are keeping track of tokens for sending agent data to the client, but
the client send an initial value of ~0, and never gives us new send tokens
so this is all rather useless -> remove it.
Note that it is kept in the migration data struct for compatibility reasons.
read_from_vdi_port(), called from vdagent_char_device_wakeup() may
fail to consume all data because no buffers are available in the
read_bufs ring. When this happens we would fail to ever read more data
from the agent on the guest as the port is throttled and stays throttled
until we've consumed all data from the current buffer.
This patch re-enables the call to read_from_vdi_port() from
vdi_read_buf_release(), so that we will try the read again when space
becomes available in the read_bufs ring.
Together with another nasty hack in the linux guest virtio_console
driver, where it waits for a write to be acked by the host before
continuing with the next one, this can lead to a linux guest
getting stuck / hang (until the write is read by the spice-server
which never happens becaus of the above issues).
Note that even with this patch, the guest will still gets stuck due to
a bug in watch_update_mask in spice-core in qemu, which causes writing
to the client to never resume once it blocked. A patch for this has been
submitted to qemu.
read_from_vdi_port() MUST always be called in a while loop until it returns 0.
This is needed because it can cause new data available events and its
recursion protection causes those to get lost. Calling it until it returns 0
ensures that all data has been consumed.
Example scenario where we can fail to read the available data otherwise:
- server/reds.c: vdagent_char_device_wakeup get called
by hw/spice-vmc.c because data has arrived from the guest,
- hw/spice-vmc.c: vmc_read get calls
- If the vmc_read call depletes the current buffer it calls
virtio_serial_throttle_port(&svc->port, false)
- This causes vmc_have_data to get called, which if in the
mean time another buffer has arrived causes
vdagent_char_device_wakeup to gets called again
(so recursively)
- vdagent_char_device_wakeup is protected against recursive
calling and ignores the second call (a nasty hack)
- if no other data arrives, the arrived data will not get read
This patch adds a channel event callback to the spice core interface.
This new callback will be called for three events:
(1) A new connection has been established.
(2) The channel is ready (i.e. authentication is done,
link message verification passed all tests, channel
is ready to use).
(3) Channel was disconnected.
Qemu will use this to send notifications to the management app.
When drawing a drawable with a NULL src bitmap that means we should
be using the previously generated self_bitmap. Not doing this causes
a segfault due to accessing the NULL.
The self_bitmap is the size of self_bitmap_area, not the bbox.
This is especially important since we later copy the self_bitmap_area
into the new bitmap, and if that is larger than bbox then we will
overwrite random memory.
We really need to flush the ring to ensure that we push something on the
release ring. If we don't do this and the ring is not pushed for other
reasons we will timeout in the guest driver waiting for the ring.
We've changed how resources are released so they are now being
freed continuosly, rather than on OOM, since we want to free as early
possible to avoid fragmentation. So, OOM situations should be a bit
less common now and signify a real memory shortage, so we should try
to free up more resources.
When upgrading a cluster of machines you typically do this by
upgrading a set of machines at a time, making the new machines run
the new software version, but in a fashion compatible with the old
versions (in terms of e.g. migration). Then when all machines are
upgrades, any new features in the new version can be enabled.
This API allows qemu to limit the set of features that spice uses to
those compatible with an older version, in order to do an upgrade like
this. Right now it doesn't really do much, since we don't keep compat
with 0.4.0 atm (although that may be added later).
There is no guarantee that any future version of spice support
being compatible with any previous version. However, we will always
support compatibility with the previous major version so that clusters
can be upgraded step by step.
This will prevent: 1) rendering problems (commands sent to the client in the wrong order)
2) sending commands for surfaces that haven't been created yet on the client side.
This used to be a callback for the vdi_port "data ready" interrupt,
which did indicate either data ready to read or data ready to write, but
this is no longer the case now that virtio-serial is used.
This seemingly simple fix prevents a race that needs to be fixed with
another patch, see freedesktop bz #29903
The vdi_port_write_timer_started flag was not being reset, which prevented
another vdi_port_write_timer_start from actually starting the timer. Fix
is to change order of lines. This happens in the callback of the timer, so
no chance of double timer set.
A side effect of the previous red_current_flush, which flushed all the surfaces, and was called on a new display channel connection, was
that red_handle_drawable_surfaces_client_synced sent the most updated surfaces images when needed. However, now, it should
explicitly call red_current_flush.
Moreover, since red_current_flush was called on a new display channel connection only if there was a primary surface,
if the connection of the display channel occurred at the moment of no primary surface, red_handle_drawable_surfaces_client_synced was buggy.
Update #define in server/spice.h in preparation for the 0.6.0 release.
We also got some new functions, thus we have to increate the shared
lib minor number for spice-server.
The actual bitmap data was added to the main marshaller rather than
the submarshaller that pointed to the SpiceImage part. This made us
send too short messages failing demarshalling in the client.
When the we reset qxl, we destroy all srufaces. Since surfaces and glz
drawables are no longer dependent, we need to call red_display_clear_glz_drawables explicitly
in order to clear all our drawables references in the server.
Remove all uses of @end in the marshaller, instead just using
the C struct array-at-end-of-struct. To make this work we also remove
all use of @end for switches (making them C unions).
We drop the zero member of the notify message so that we can avoid this
use of @end for a primitive in the marshaller (plus its useless to send
over the wire).
We change the offsets and stuff in the migration messages to real pointers.
