Re: [Spice-devel] [PATCH] Server: Changed uint64_t printing format from %ld to %lld
On 07/03/2011 04:27 PM, Rami Vaknin wrote:
From: rootroot@fed15.localdomain
Compiling with gcc-c++-4.6.0-9.fc15.i686 on Fedora 15
---
server/main_channel.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/server/main_channel.c b/server/main_channel.c
index 1a6a89c..c7a70d7 100644
--- a/server/main_channel.c
+++ b/server/main_channel.c
@@ -733,12 +733,12 @@ static int main_channel_handle_parsed(RedChannel
*channel, uint32_t size, uint16
if (roundtrip= latency) {
// probably high load on client or server result with
incorrect values
latency = 0;
-red_printf(net test: invalid values, latency %lu
roundtrip %lu. assuming high
+red_printf(net test: invalid values, latency %llu
roundtrip %llu. assuming high
The spice server is compiled for 64 bit machines (at least currently).
Try compiling with gcc-c++-*.fc15.x86_64
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel
[Spice-devel] [PATCH 1/2] server: removing local cursor, this solves RHBZ #714801
When the worker was stoped, the cursor was copied from guest ram to the host
ram,
and its corresponding qxl command was released.
This is unecessary, since the qxl ram still exists (we keep references
to the surfaces in the same manner).
It also led to BSOD on guest upon migration: the device tracks cursor set
commands and it stores
a reference to the last one. Then, it replays it to the destination server when
migrating to it.
However, the command the qxl replayed has already been released from the pci by
the original
worker, upon STOP.
---
server/red_worker.c | 128 ++-
1 files changed, 14 insertions(+), 114 deletions(-)
diff --git a/server/red_worker.c b/server/red_worker.c
index bee86b9..1726b53 100644
--- a/server/red_worker.c
+++ b/server/red_worker.c
@@ -239,7 +239,6 @@ enum {
PIPE_ITEM_TYPE_INVAL_ONE,
PIPE_ITEM_TYPE_CURSOR,
PIPE_ITEM_TYPE_MIGRATE,
-PIPE_ITEM_TYPE_LOCAL_CURSOR,
PIPE_ITEM_TYPE_CURSOR_INIT,
PIPE_ITEM_TYPE_IMAGE,
PIPE_ITEM_TYPE_STREAM_CREATE,
@@ -300,17 +299,10 @@ typedef struct SurfaceDestroyItem {
PipeItem pipe_item;
} SurfaceDestroyItem;
-enum {
-CURSOR_TYPE_INVALID,
-CURSOR_TYPE_DEV,
-CURSOR_TYPE_LOCAL,
-};
-
typedef struct CursorItem {
PipeItem pipe_data;
uint32_t group_id;
int refs;
-int type;
RedCursorCmd *red_cursor;
} CursorItem;
@@ -4065,11 +4057,6 @@ static void red_release_cursor(RedWorker *worker,
CursorItem *cursor)
QXLReleaseInfoExt release_info_ext;
RedCursorCmd *cursor_cmd;
-if (cursor-type == CURSOR_TYPE_LOCAL) {
-free(cursor);
-return;
-}
-
cursor_cmd = cursor-red_cursor;
release_info_ext.group_id = cursor-group_id;
release_info_ext.info = cursor_cmd-release_info;
@@ -4125,7 +4112,6 @@ static CursorItem *get_cursor_item(RedWorker *worker,
RedCursorCmd *cmd, uint32_
cursor_item-refs = 1;
red_channel_pipe_item_init(worker-cursor_channel-common.base,
cursor_item-pipe_data, PIPE_ITEM_TYPE_CURSOR);
-cursor_item-type = CURSOR_TYPE_INVALID;
cursor_item-group_id = group_id;
cursor_item-red_cursor = cmd;
@@ -4140,7 +4126,6 @@ static void qxl_process_cursor(RedWorker *worker,
RedCursorCmd *cursor_cmd, uint
switch (cursor_cmd-type) {
case QXL_CURSOR_SET:
worker-cursor_visible = cursor_cmd-u.set.visible;
-item-type = CURSOR_TYPE_DEV;
red_set_cursor(worker, item);
break;
case QXL_CURSOR_MOVE:
@@ -5883,6 +5868,7 @@ static void fill_attr(DisplayChannel *display_channel,
SpiceMarshaller *m, Spice
static void fill_cursor(CursorChannel *cursor_channel, SpiceCursor
*red_cursor, CursorItem *cursor, AddBufInfo *addbuf)
{
+RedCursorCmd *cursor_cmd;
addbuf-data = NULL;
if (!cursor) {
@@ -5890,35 +5876,23 @@ static void fill_cursor(CursorChannel *cursor_channel,
SpiceCursor *red_cursor,
return;
}
-if (cursor-type == CURSOR_TYPE_DEV) {
-RedCursorCmd *cursor_cmd;
-
-cursor_cmd = cursor-red_cursor;
-*red_cursor = cursor_cmd-u.set.shape;
+cursor_cmd = cursor-red_cursor;
+*red_cursor = cursor_cmd-u.set.shape;
-if (red_cursor-header.unique) {
-if (red_cursor_cache_find(cursor_channel,
red_cursor-header.unique)) {
-red_cursor-flags |= SPICE_CURSOR_FLAGS_FROM_CACHE;
-return;
-}
-if (red_cursor_cache_add(cursor_channel,
red_cursor-header.unique, 1)) {
-red_cursor-flags |= SPICE_CURSOR_FLAGS_CACHE_ME;
-}
+if (red_cursor-header.unique) {
+if (red_cursor_cache_find(cursor_channel, red_cursor-header.unique)) {
+red_cursor-flags |= SPICE_CURSOR_FLAGS_FROM_CACHE;
+return;
}
-
-if (red_cursor-data_size) {
-addbuf-type = BUF_TYPE_RAW;
-addbuf-data = red_cursor-data;
-addbuf-size = red_cursor-data_size;
+if (red_cursor_cache_add(cursor_channel, red_cursor-header.unique,
1)) {
+red_cursor-flags |= SPICE_CURSOR_FLAGS_CACHE_ME;
}
-} else {
-LocalCursor *local_cursor;
-ASSERT(cursor-type == CURSOR_TYPE_LOCAL);
-local_cursor = (LocalCursor *)cursor;
-*red_cursor = local_cursor-red_cursor;
+}
+
+if (red_cursor-data_size) {
addbuf-type = BUF_TYPE_RAW;
-addbuf-data = local_cursor-red_cursor.data;
-addbuf-size = local_cursor-data_size;
+addbuf-data = red_cursor-data;
+addbuf-size = red_cursor-data_size;
}
}
@@ -7926,27 +7900,6 @@ static void red_marshall_cursor_init(CursorChannel
*channel, SpiceMarshaller *ba
add_buf_from_info(base_marshaller, info);
}
-static void red_marshall_local_cursor(CursorChannel *cursor_channel,
- SpiceMarshaller *base_marshaller, LocalCursor *cursor)
-{
-
[Spice-devel] [PATCH 2/2] server: replace redundant code with red_cursor_reset
In addition (1) make handle_dev_destroy_surfaces call red_release_cursor
(2) call red_wait_outgoing_item(cursor_channel) only after adding msgs to pipe
---
server/red_worker.c | 71 +-
1 files changed, 24 insertions(+), 47 deletions(-)
diff --git a/server/red_worker.c b/server/red_worker.c
index 1726b53..89fdac3 100644
--- a/server/red_worker.c
+++ b/server/red_worker.c
@@ -9441,6 +9441,27 @@ static inline void
handle_dev_destroy_surface_wait(RedWorker *worker)
write_message(worker-channel, message);
}
+static inline void red_cursor_reset(RedWorker *worker)
+{
+if (worker-cursor) {
+red_release_cursor(worker, worker-cursor);
+worker-cursor = NULL;
+}
+
+worker-cursor_visible = TRUE;
+worker-cursor_position.x = worker-cursor_position.y = 0;
+worker-cursor_trail_length = worker-cursor_trail_frequency = 0;
+
+if (worker-cursor_channel) {
+red_channel_pipe_add_type(worker-cursor_channel-common.base,
PIPE_ITEM_TYPE_INVAL_CURSOR_CACHE);
+if (!worker-cursor_channel-common.base.migrate) {
+red_pipe_add_verb(worker-cursor_channel-common.base,
SPICE_MSG_CURSOR_RESET);
+}
+red_wait_outgoing_item((RedChannel *)worker-cursor_channel);
+
ASSERT(red_channel_no_item_being_sent(worker-cursor_channel-common.base));
+}
+}
+
/* called upon device reset */
static inline void handle_dev_destroy_surfaces(RedWorker *worker)
{
@@ -9460,15 +9481,6 @@ static inline void handle_dev_destroy_surfaces(RedWorker
*worker)
}
ASSERT(ring_is_empty(worker-streams));
-red_wait_outgoing_item((RedChannel *)worker-cursor_channel);
-if (worker-cursor_channel) {
-red_channel_pipe_add_type(worker-cursor_channel-common.base,
PIPE_ITEM_TYPE_INVAL_CURSOR_CACHE);
-if (!worker-cursor_channel-common.base.migrate) {
-red_pipe_add_verb(worker-cursor_channel-common.base,
SPICE_MSG_CURSOR_RESET);
-}
-
ASSERT(red_channel_no_item_being_sent(worker-cursor_channel-common.base));
-}
-
if (worker-display_channel) {
red_channel_pipe_add_type(worker-display_channel-common.base,
PIPE_ITEM_TYPE_INVAL_PALLET_CACHE);
red_pipe_add_verb(worker-display_channel-common.base,
SPICE_MSG_DISPLAY_STREAM_DESTROY_ALL);
@@ -9476,9 +9488,7 @@ static inline void handle_dev_destroy_surfaces(RedWorker
*worker)
red_display_clear_glz_drawables(worker-display_channel);
-worker-cursor_visible = TRUE;
-worker-cursor_position.x = worker-cursor_position.y = 0;
-worker-cursor_trail_length = worker-cursor_trail_frequency = 0;
+red_cursor_reset(worker);
message = RED_WORKER_MESSAGE_READY;
write_message(worker-channel, message);
@@ -9531,20 +9541,6 @@ static inline void
handle_dev_destroy_primary_surface(RedWorker *worker)
PANIC_ON(surface_id != 0);
PANIC_ON(!worker-surfaces[surface_id].context.canvas);
-if (worker-cursor) {
-red_release_cursor(worker, worker-cursor);
-worker-cursor = NULL;
-}
-
-red_wait_outgoing_item((RedChannel *)worker-cursor_channel);
-if (worker-cursor_channel) {
-red_channel_pipe_add_type(worker-cursor_channel-common.base,
PIPE_ITEM_TYPE_INVAL_CURSOR_CACHE);
-if (!worker-cursor_channel-common.base.migrate) {
-red_pipe_add_verb(worker-cursor_channel-common.base,
SPICE_MSG_CURSOR_RESET);
-}
-
ASSERT(red_channel_no_item_being_sent(worker-cursor_channel-common.base));
-}
-
flush_all_qxl_commands(worker);
destroy_surface_wait(worker, 0);
red_destroy_surface(worker, 0);
@@ -9552,9 +9548,7 @@ static inline void
handle_dev_destroy_primary_surface(RedWorker *worker)
ASSERT(!worker-surfaces[surface_id].context.canvas);
-worker-cursor_visible = TRUE;
-worker-cursor_position.x = worker-cursor_position.y = 0;
-worker-cursor_trail_length = worker-cursor_trail_frequency = 0;
+red_cursor_reset(worker);
message = RED_WORKER_MESSAGE_READY;
write_message(worker-channel, message);
@@ -9593,24 +9587,7 @@ static void handle_dev_input(EventListener *listener,
uint32_t events)
clear_bit(RED_WORKER_PENDING_OOM, worker-pending);
break;
case RED_WORKER_MESSAGE_RESET_CURSOR:
-if (worker-cursor) {
-red_release_cursor(worker, worker-cursor);
-worker-cursor = NULL;
-}
-
-red_wait_outgoing_item((RedChannel *)worker-cursor_channel);
-if (worker-cursor_channel) {
-red_channel_pipe_add_type(cursor_red_channel,
PIPE_ITEM_TYPE_INVAL_CURSOR_CACHE);
-if (!cursor_red_channel-migrate) {
-red_pipe_add_verb(cursor_red_channel, SPICE_MSG_CURSOR_RESET);
-}
-ASSERT(red_channel_no_item_being_sent(cursor_red_channel));
-
-worker-cursor_visible = TRUE;
-worker-cursor_position.x = worker-cursor_position.y = 0;
-
Re: [Spice-devel] [PATCH 2/3] spice-channel: add property total-bytes-read
On Sat, Jul 02, 2011 at 05:06:39AM +0200, Alon Levy wrote:
--- a/gtk/spice-channel-priv.h
+++ b/gtk/spice-channel-priv.h
@@ -123,6 +123,8 @@ struct spice_channel {
GArray *common_caps;
GArray *remote_caps;
GArray *remote_common_caps;
+
+gsize total_read_bytes;
sizeof(gsize) is 8 on 64 bit machines...
@@ -288,6 +292,15 @@ static void spice_channel_class_init(SpiceChannelClass
*klass)
G_PARAM_STATIC_NICK |
G_PARAM_STATIC_BLURB));
+g_object_class_install_property
+(gobject_class, PROP_TOTAL_READ_BYTES,
+ g_param_spec_uint(total-read-bytes,
...so this should be an uint64 property
Christophe
pgp3AN1BZABYF.pgp
Description: PGP signature
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel
[Spice-devel] bad primary surface and server crash after migration
Hi Gerd, I encountered several problems after migration, maybe you can help: 1) on qxl_pre_load, sometimes the command ring is not empty and when handle_dev_destroy_surface (on hard reset), flush_all_qxl_commands is called. When attempting to process a command we receive id 0, group 0, virt start 0, virt end , generation 0, delta 0 validate_virt: panic: virtual address out of range virt=0x175f99c+0xbf slot_id=1 group_id=1 slot=0x0-0x0 delta=0x0 Is it valid that the command ring is not empty? Maybe we shouldn't process commands as long as worker-running is not set? 2) immediately after migration, before processing any commands, it looks like the primary surface on the destination is not the most updated one (or alternatively was badly rendered). When I connect to the source server (the stopped one), the primary surface looks o.k (this made me think it is not a rendering problem). Maybe there is a problem with setting all the ram dirty? I also checked that the stopped server doesn't preform any processing commands after it has been stopped, and that the destination doesn't preform any commands before loadvm (when it doesn't crash on the previos problem I described). 3) sometimes the destination server crashes on validate virt after it survived pre_load and loadvm. still haven't fully investigated this, but maybe it is related to the first 2 problems. Thanks, Yonit. ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] [PATCH] Server: Changed uint64_t printing format from %ld to %lld
On Mon, Jul 04, 2011 at 09:37:53AM +0300, Uri Lublin wrote: On 07/03/2011 04:27 PM, Rami Vaknin wrote: From: rootroot@fed15.localdomain Compiling with gcc-c++-4.6.0-9.fc15.i686 on Fedora 15 The spice server is compiled for 64 bit machines (at least currently). Try compiling with gcc-c++-*.fc15.x86_64 I was about to mention that these warnings are probably one of the smallest issue you'll encounter on a 32 bit spice-server build. However, the patch doesn't hurt, it's actually a first step in the right direction, and I assume spice/server/ is compiled anyway when all we want is spicec? Christophe ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel pgpcHFSqu51G0.pgp Description: PGP signature ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] [PATCH] Server: Changed uint64_t printing format from %ld to %lld
On Sun, Jul 03, 2011 at 05:57:08PM +0200, Alon Levy wrote: On Sun, Jul 03, 2011 at 04:27:57PM +0300, Rami Vaknin wrote: From: root root@fed15.localdomain ACK. I'll push this. This adds warnings on 64 bit builds: main_channel.c: In function 'main_channel_handle_parsed': main_channel.c:736:21: error: format '%llu' expects argument of type 'long long unsigned int', but argument 3 has type 'uint64_t' [-Werror=format] glib has a magic #define for that, G_GUINT64_FORMAT which expands to different things depending on if we are using a 32 or 64 bit glib build (it expands to lu on 64 bit). Christophe pgp4YtuJVmJOa.pgp Description: PGP signature ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] bad primary surface and server crash after migration
On 07/04/2011 11:54 AM, Yonit Halperin wrote: Hi Gerd, I encountered several problems after migration, maybe you can help: 1) on qxl_pre_load, sometimes the command ring is not empty and when handle_dev_destroy_surface (on hard reset), flush_all_qxl_commands is called. When attempting to process a command we receive id 0, group 0, virt start 0, virt end , generation 0, delta 0 validate_virt: panic: virtual address out of range virt=0x175f99c+0xbf slot_id=1 group_id=1 slot=0x0-0x0 delta=0x0 Is it valid that the command ring is not empty? Maybe we shouldn't process commands as long as worker-running is not set? 2) immediately after migration, before processing any commands, it looks like the primary surface on the destination is not the most updated one (or alternatively was badly rendered). When I connect to the source server (the stopped one), the primary surface looks o.k (this made me think it is not a rendering problem). Maybe there is a problem with setting all the ram dirty? I also checked that the stopped server doesn't preform any processing commands after it has been stopped, and that the destination doesn't preform any commands before loadvm (when it doesn't crash on the previos problem I described). 3) sometimes the destination server crashes on validate virt after it survived pre_load and loadvm. still haven't fully investigated this, but maybe it is related to the first 2 problems. Ignore this one - working on Windows 7 with a driver that doesn't support yet S3...so when Windows 7 goes automatically to sleep:) Thanks, Yonit. ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] bad primary surface and server crash after migration
On 07/04/11 10:51, Yonit Halperin wrote: Hi Gerd, I encountered several problems after migration, maybe you can help: 1) on qxl_pre_load, sometimes the command ring is not empty and when handle_dev_destroy_surface (on hard reset), flush_all_qxl_commands is called. When attempting to process a command we receive id 0, group 0, virt start 0, virt end , generation 0, delta 0 validate_virt: panic: virtual address out of range virt=0x175f99c+0xbf slot_id=1 group_id=1 slot=0x0-0x0 delta=0x0 Is it valid that the command ring is not empty? Maybe we shouldn't process commands as long as worker-running is not set? Yes, that should fix it, otherwise you'll try to process commands before qxl fully restored the state (especially memory slots and surfaces) which will not work. 2) immediately after migration, before processing any commands, it looks like the primary surface on the destination is not the most updated one (or alternatively was badly rendered). When I connect to the source server (the stopped one), the primary surface looks o.k (this made me think it is not a rendering problem). Maybe there is a problem with setting all the ram dirty? I also checked that the stopped server doesn't preform any processing commands after it has been stopped, and that the destination doesn't preform any commands before loadvm (when it doesn't crash on the previos problem I described). Could be. qxl_vm_change_state_handler() takes care to tag all vram dirty, the primary lives in devram though ... cheers, Gerd ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] bad primary surface and server crash after migration
On 07/04/2011 12:23 PM, Gerd Hoffmann wrote: On 07/04/11 10:51, Yonit Halperin wrote: Hi Gerd, I encountered several problems after migration, maybe you can help: 1) on qxl_pre_load, sometimes the command ring is not empty and when handle_dev_destroy_surface (on hard reset), flush_all_qxl_commands is called. When attempting to process a command we receive id 0, group 0, virt start 0, virt end , generation 0, delta 0 validate_virt: panic: virtual address out of range virt=0x175f99c+0xbf slot_id=1 group_id=1 slot=0x0-0x0 delta=0x0 Is it valid that the command ring is not empty? Maybe we shouldn't process commands as long as worker-running is not set? Yes, that should fix it, otherwise you'll try to process commands before qxl fully restored the state (especially memory slots and surfaces) which will not work. 2) immediately after migration, before processing any commands, it looks like the primary surface on the destination is not the most updated one (or alternatively was badly rendered). When I connect to the source server (the stopped one), the primary surface looks o.k (this made me think it is not a rendering problem). Maybe there is a problem with setting all the ram dirty? I also checked that the stopped server doesn't preform any processing commands after it has been stopped, and that the destination doesn't preform any commands before loadvm (when it doesn't crash on the previos problem I described). Could be. qxl_vm_change_state_handler() takes care to tag all vram dirty, the primary lives in devram though ... o.k. missed it because it is called vram as well (vga.vram). I will set it dirty as well. cheers, Gerd ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] [PATCH 2/3] spice-channel: add property total-bytes-read
Hi
- Original Message -
On Sat, Jul 02, 2011 at 05:06:39AM +0200, Alon Levy wrote:
--- a/gtk/spice-channel-priv.h
+++ b/gtk/spice-channel-priv.h
@@ -123,6 +123,8 @@ struct spice_channel {
GArray *common_caps;
GArray *remote_caps;
GArray *remote_common_caps;
+
+ gsize total_read_bytes;
sizeof(gsize) is 8 on 64 bit machines...
unsigned long gsize;
(this is partly my fault..)
@@ -288,6 +292,15 @@ static void
spice_channel_class_init(SpiceChannelClass *klass)
G_PARAM_STATIC_NICK |
G_PARAM_STATIC_BLURB));
+ g_object_class_install_property
+ (gobject_class, PROP_TOTAL_READ_BYTES,
+ g_param_spec_uint(total-read-bytes,
...so this should be an uint64 property
or a ulong property.
fixed upstream.
--
Marc-André Lureau
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] [PATCH] Server: Changed uint64_t printing format from %ld to %lld
On Mon, Jul 04, 2011 at 10:53:33AM +0200, Christophe Fergeau wrote: On Mon, Jul 04, 2011 at 09:37:53AM +0300, Uri Lublin wrote: On 07/03/2011 04:27 PM, Rami Vaknin wrote: From: rootroot@fed15.localdomain Compiling with gcc-c++-4.6.0-9.fc15.i686 on Fedora 15 The spice server is compiled for 64 bit machines (at least currently). Try compiling with gcc-c++-*.fc15.x86_64 I was about to mention that these warnings are probably one of the smallest issue you'll encounter on a 32 bit spice-server build. However, the patch doesn't hurt, it's actually a first step in the right direction, and I assume spice/server/ is compiled anyway when all we want is spicec? No, you can do cd client; make and get just the client. Christophe ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
[Spice-devel] [PATCH] qxl: make sure primary surface is saved on migration
---
hw/qxl.c |9 ++---
1 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/hw/qxl.c b/hw/qxl.c
index 2bb36c6..9fdeffb 100644
--- a/hw/qxl.c
+++ b/hw/qxl.c
@@ -1165,11 +1165,14 @@ static void qxl_vm_change_state_handler(void *opaque,
int running, int reason)
qemu_spice_vm_change_state_handler(qxl-ssd, running, reason);
if (!running qxl-mode == QXL_MODE_NATIVE) {
-/* dirty all vram (which holds surfaces) to make sure it is saved */
+/* dirty all vram (which holds surfaces) and devram (primary surface)
+ * to make sure they are saved */
/* FIXME #1: should go out during live stage */
/* FIXME #2: we only need to save the areas which are actually used */
-ram_addr_t addr = qxl-vram_offset;
-qxl_set_dirty(addr, addr + qxl-vram_size);
+ram_addr_t vram_addr = qxl-vram_offset;
+ram_addr_t devram_addr = qxl-vga.vram_offset;
+qxl_set_dirty(vram_addr, vram_addr + qxl-vram_size);
+qxl_set_dirty(devram_addr, devram_addr + qxl-vga.vram_size);
}
}
--
1.7.4.4
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] [PATCH] qxl: make sure primary surface is saved on migration
Hi, +qxl_set_dirty(devram_addr, devram_addr + qxl-vga.vram_size); It is enougth to dirty the surface0 area. Otherwise the patch looks fine. cheers, Gerd ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] [PATCH] Server: Changed uint64_t printing format from %ld to %lld
On Mon, Jul 04, 2011 at 12:01:02PM +0200, Alon Levy wrote: I was about to mention that these warnings are probably one of the smallest issue you'll encounter on a 32 bit spice-server build. However, the patch doesn't hurt, it's actually a first step in the right direction, and I assume spice/server/ is compiled anyway when all we want is spicec? No, you can do cd client; make and get just the client. Ah ok, and that's indeed what the spec file does on x86. Christophe pgpqBqko37dPW.pgp Description: PGP signature ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] Purpose of interface version checks in server/reds.c
On 07/01/11 15:58, Christophe Fergeau wrote:
Hi,
While looking at a crash in qemu when SPICE_INTERFACE_PLAYBACK_MINOR was
increased, I came across the version checking code in spice_server_add_interface
in server/reds.c which does stuff like
if (strcmp(interface-type, SPICE_INTERFACE_RECORD) == 0) {
red_printf(SPICE_INTERFACE_RECORD);
if (interface-major_version != SPICE_INTERFACE_RECORD_MAJOR ||
interface-minor_version SPICE_INTERFACE_RECORD_MINOR) {
red_printf(unsupported record interface);
return -1;
}
snd_attach_record(SPICE_CONTAINEROF(sin, SpiceRecordInstance, base));
}
That looks bogous.
interface-major_version/interface-minor_version are filled in
qemu/audio/spiceaudio.c using compile time constants from spice-server.
It seems to be useful to detect when qemu was compiled against an older
spice-server than the one that is currently installed.
Indeed.
I'm a bit surprised by this mechanism, if we break these interfaces in such
a way that qemu needs to be recompiled, shouldn't we use different library
sonames to make sure things are recompiled?
No. The purpose of the versions is exactly to avoid the need for a new
soname. The rules are basically:
(1) You add stuff to the interface, strictly append-only to not break
binary compatibility.
(2) You bump the minor version of the interface.
(3) You check the minor version at runtime to figure whenever the
added fields contain valid stuff or not.
An example is here (core interface, minor goes from 2 to 3, new
channel_event callback):
http://cgit.freedesktop.org/spice/spice/commit/?id=97f33fa86aa6edd25111b173dc0d9599ac29f879
cheers,
Gerd
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel
[Spice-devel] [PATCHv2] qxl: make sure primary surface is saved on migration
---
hw/qxl.c |9 ++---
1 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/hw/qxl.c b/hw/qxl.c
index 2bb36c6..cff95a4 100644
--- a/hw/qxl.c
+++ b/hw/qxl.c
@@ -1165,11 +1165,14 @@ static void qxl_vm_change_state_handler(void *opaque,
int running, int reason)
qemu_spice_vm_change_state_handler(qxl-ssd, running, reason);
if (!running qxl-mode == QXL_MODE_NATIVE) {
-/* dirty all vram (which holds surfaces) to make sure it is saved */
+/* dirty all vram (which holds surfaces) and devram (primary surface)
+ * to make sure they are saved */
/* FIXME #1: should go out during live stage */
/* FIXME #2: we only need to save the areas which are actually used */
-ram_addr_t addr = qxl-vram_offset;
-qxl_set_dirty(addr, addr + qxl-vram_size);
+ram_addr_t vram_addr = qxl-vram_offset;
+ram_addr_t devram_addr = qxl-vga.vram_offset;
+qxl_set_dirty(vram_addr, vram_addr + qxl-vram_size);
+qxl_set_dirty(devram_addr, devram_addr + qxl-rom-surface0_area_size);
}
}
--
1.7.4.4
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] Out of surface in Xorg.0.log
On 07/03/11 15:12, Frédéric Grelot wrote: [ 664.762] Out of surfaces [ 664.802] Out of surfaces I suspected that this was somewhat related to the resolution I did set in X : 1920x1080. I then set the VRAM size to 128Mb instead of 64Mb : unfortunately, the host was overloaded with the following message in libvirt log : MSI-X: only dword read is allowed! I tried 96Mb instead of 128, but I got the same problem. The only solution is to use 64Mb, but it runs out of surfaces then... Any help will be greatly appreciated. How does /proc/iomem look like with 128Mb? Using the bios from http://spice-space.org/download/seabios/ might help. cheers, Gerd ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] [PATCHv2] qxl: make sure primary surface is saved on migration
Hi, +qxl_set_dirty(devram_addr, devram_addr + qxl-rom-surface0_area_size); s/rom/shadow_rom/, then it is perfect. rom points directly to guest memory, better don't trust that. cheers, Gerd ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
[Spice-devel] [PATCHv3] qxl: make sure primary surface is saved on migration
---
hw/qxl.c |9 ++---
1 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/hw/qxl.c b/hw/qxl.c
index 2bb36c6..b3a3507 100644
--- a/hw/qxl.c
+++ b/hw/qxl.c
@@ -1165,11 +1165,14 @@ static void qxl_vm_change_state_handler(void *opaque,
int running, int reason)
qemu_spice_vm_change_state_handler(qxl-ssd, running, reason);
if (!running qxl-mode == QXL_MODE_NATIVE) {
-/* dirty all vram (which holds surfaces) to make sure it is saved */
+/* dirty all vram (which holds surfaces) and devram (primary surface)
+ * to make sure they are saved */
/* FIXME #1: should go out during live stage */
/* FIXME #2: we only need to save the areas which are actually used */
-ram_addr_t addr = qxl-vram_offset;
-qxl_set_dirty(addr, addr + qxl-vram_size);
+ram_addr_t vram_addr = qxl-vram_offset;
+ram_addr_t surface0_addr = qxl-vga.vram_offset +
qxl-shadow_rom.draw_area_offset;
+qxl_set_dirty(vram_addr, vram_addr + qxl-vram_size);
+qxl_set_dirty(surface0_addr, surface0_addr +
qxl-shadow_rom.surface0_area_size);
}
}
--
1.7.4.4
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] [RfC fix] async thread fix - handle EAGAIN/EINTR, remove fprintf
On 06/24/2011 02:52 PM, Alon Levy wrote:
ret = read(d-aio_pipe[0],io, sizeof(io));
+if (ret 0 (errno == EAGAIN || errno == EINTR)) {
+continue;
+}
This means you'd be busy waiting if you get EAGAIN. If you really need
EAGAIN, perhaps there is another bug somewhere?
Paolo
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel
[Spice-devel] [PATCH] server: not reading command rings before RED_WORKER_MESSAGE_START, RHBZ #718713
On migration, destroy_surfaces is called from qxl (qxl_hard_reset), before the
device was loaded (on destination).
handle_dev_destroy_surfaces led to red_process_commands, which read the qxl
command ring
(which appeared to be not empty), and then when processing the command
it accessed unmapped memory.
---
server/red_worker.c | 12 +++-
1 files changed, 11 insertions(+), 1 deletions(-)
diff --git a/server/red_worker.c b/server/red_worker.c
index 89fdac3..c0a9760 100644
--- a/server/red_worker.c
+++ b/server/red_worker.c
@@ -4166,6 +4166,11 @@ static int red_process_cursor(RedWorker *worker,
uint32_t max_pipe_size, int *ri
QXLCommandExt ext_cmd;
int n = 0;
+if (!worker-running) {
+*ring_is_empty = TRUE;
+return n;
+}
+
*ring_is_empty = FALSE;
while (!worker-cursor_channel ||
worker-cursor_channel-common.base.pipe_size = max_pipe_size) {
if (!worker-qxl-st-qif-get_cursor_command(worker-qxl, ext_cmd)) {
@@ -4205,7 +4210,12 @@ static int red_process_commands(RedWorker *worker,
uint32_t max_pipe_size, int *
QXLCommandExt ext_cmd;
int n = 0;
uint64_t start = red_now();
-
+
+if (!worker-running) {
+*ring_is_empty = TRUE;
+return n;
+}
+
*ring_is_empty = FALSE;
while (!worker-display_channel ||
worker-display_channel-common.base.pipe_size = max_pipe_size) {
if (!worker-qxl-st-qif-get_command(worker-qxl, ext_cmd)) {
--
1.7.4.4
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] Purpose of interface version checks in server/reds.c
Hi,
On Mon, Jul 04, 2011 at 01:27:16PM +0200, Gerd Hoffmann wrote:
On 07/01/11 15:58, Christophe Fergeau wrote:
if (strcmp(interface-type, SPICE_INTERFACE_RECORD) == 0) {
red_printf(SPICE_INTERFACE_RECORD);
if (interface-major_version != SPICE_INTERFACE_RECORD_MAJOR ||
interface-minor_version SPICE_INTERFACE_RECORD_MINOR) {
red_printf(unsupported record interface);
return -1;
}
snd_attach_record(SPICE_CONTAINEROF(sin, SpiceRecordInstance, base));
}
That looks bogous.
Given your explanation below, I agree with you. I'm wondering if what was
originally intended was the opposite check, ie fail to create the channel
if QEMU supports a *newer* version of the interface than the installed
spice-server. Otherwise I'll make a patch to
- fail the channel creation if interface-major_version !=
SPICE_INTERFACE_RECORD_MAJOR
- only log a message if interface-minor_version
SPICE_INTERFACE_RECORD_MINOR) (but create the channel anyway)
I'm a bit surprised by this mechanism, if we break these interfaces in such
a way that qemu needs to be recompiled, shouldn't we use different library
sonames to make sure things are recompiled?
No. The purpose of the versions is exactly to avoid the need for a
new soname. The rules are basically:
(1) You add stuff to the interface, strictly append-only to not break
binary compatibility.
(2) You bump the minor version of the interface.
(3) You check the minor version at runtime to figure whenever the
added fields contain valid stuff or not.
Ah ok, if things are done this way, this sounds good and useful to me.
An example is here (core interface, minor goes from 2 to 3, new
channel_event callback):
http://cgit.freedesktop.org/spice/spice/commit/?id=97f33fa86aa6edd25111b173dc0d9599ac29f879
I see, thanks. In this case, the change adds new messages and new methods
for the Playback and Record channels, so nothing should change unless these
new methods are explicitly called from qemu, which means raising the minor
version number was probably not strictly needed (but not harmful either).
Thanks for the clarifications,
Christophe
pgpcNAdFUHNXl.pgp
Description: PGP signature
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] Purpose of interface version checks in server/reds.c
Hi, I see, thanks. In this case, the change adds new messages and new methods for the Playback and Record channels, so nothing should change unless these new methods are explicitly called from qemu, which means raising the minor version number was probably not strictly needed (but not harmful either). It is still useful so you can ifdef code using the new methods like this ... #if SPICE_INTERFACE_CORE_MINOR = 3 .channel_event = channel_event, #endif in qemu. cheers, Gerd ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] [PATCHv3] qxl: make sure primary surface is saved on migration
On 07/04/11 14:08, Yonit Halperin wrote: --- hw/qxl.c |9 ++--- 1 files changed, 6 insertions(+), 3 deletions(-) Added to spice patch queue. thanks, Gerd ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] Unfair comparisons with RDP
On Mon, 2011-07-04 at 17:48 +0300, Yonit Halperin wrote: On 07/04/2011 05:21 PM, John A. Sullivan III wrote: Very helpful and interesting. I'll respond in-line - John On Sun, 2011-07-03 at 10:38 +0300, Yaniv Kaul wrote: On 06/30/2011 10:10 AM, Yaniv Kaul wrote: On 06/30/2011 05:33 AM, John A. Sullivan III wrote: On Wed, 2011-06-29 at 20:22 -0400, Andrew Cathrow wrote: - Original Message - snip Hello, all. I've been using both RDP via TSPlus and SPICE for over a week now and the practical world results at least in my mode of operation are becoming clear. SPICE does handle major screen refreshes better, e.g., monstrous graphics or continuously pasting a full line of text in a full screen notepad. Of course, SPICE is a clear winner when it comes to video though still not practically usable on low bandwidth links. However, RDP is trouncing SPICE in the more common day to day tasks involving small screen updates. For example, every time I open or switch my screen to LibreOffice, the tool bar icons seems to pain one at a time in SPICE where as they appear all at once in TSPlus. Document scrolling is more immediate and smoother. Surprisingly, when I open the PuTTY dialog in SPICE, it paints in sections whereas TSPlus appears all at once. You'll really need to post some real details here - from versions of qemu+spice server that you're using along with the qemu command line syntax, host OS, hardware details through to what's running in the guest, driver versions, etc. I've never seen RDP trounce spice, but if it does, then we need some scientific information on the environment so we can diagnose and assist. snip Very happy to do so as we really do want SPICE to become our protocol of choice. I believe I've posted up our details before but will do so again. Would you be so kind as to capture the Spice traffic (using tcpdump/wireshark) and send it over? Specifically: 1. Please capture from start - before the Spice client connects to the server. 2. Ensure you catch full sized packets (-s - could be 1500 most likely, when using tcpdump) 3. Save into file (-w /tmp/file.pcap when using tcpdump) 4. Please compress and send / let me know where I can pick it up from. I suggest you have only the scenario of connecting to the VM and opening putty, which you complain is slow. Hopefully it'll give us some clue. TIA, Y. disclaimer my Wireshark dissector may be buggy, and I'm basing my analysis on it/disclaimer Initial thoughts, from looking at the packet capture: 1. Initial image (packet 689) is not compressed using ZLIB (but LZ_RGB). Known issue, filed a bug about it somewhere (upstream or Fedora). 2. The same image is actually quite big - 1440x900 - made up of 172 packets, which took 0.42seconds from the first to the last packets. Perhaps splitting it to multiple smaller images would have improved the user experience. That makes sense. I was in full screen mode and my screen is 1440x900. 3. Next image (packet 967) was also using LZ_RGB, and was quite big 1440x793 - made up of 157 packets, and took 0.41 seconds from the first to last packet. Also makes sense - that was probably the toggle into full screen 4. Next image (packet 1023) is nicely compressed using ZLIB_GLZ_RGB. For some reason it does not have the CACHE_ME flag set. The next image (packet 1056) does have it. 5. Looks like you were not using the guest agent and that effects were not turned off? (example, packets 1085, 1580, 1960 which has multiple DRAW_FILL commands) - RDP, at least in previous versions, used to disable them by default. Can you verify the same settings are used with Spice? That's very interesting. We are but we frequently notice it stops and fixing it is one of our higher priorities. I'll recompile and see if I get any better performance and stability. I'll check the effects settings. 6. From packet 1580 and on we see nice use of images from the cache, so caching does appear to be working. It is a bit annoying that a 'use image from cache' for a 16x16 image takes 75 bytes, but it's the protocol. This is a little distressing. I'm guessing those 16x16 images are the LibreOffice tool bar icons. That part is one of the most dramatically slower comparisons for SPICE versus RDP. In RDP, they appear all at once. In SPICE, they paint slowly, one at a time, and perhaps do so a couple of times over - not sure about that last part but the overall experience is that it takes not just a little but many, many, many times longer to paint my LibreOffice screen in SPICE than it does with RDP. 7. Nowhere in the stream do I see JPEG compressed images. Not sure why. Was it enabled (can be seen in server side logs) ? I'll have to have a look. I assume one does not have to actively do something to enable this but rather that it is the default. Is that
Re: [Spice-devel] Out of surface in Xorg.0.log
How does /proc/iomem look like with 128Mb? I couldn't log in to the guest, since the host was overloaded with the MSI-X message. I should try with logging deactivated. Anyway, the problem occured again (still with 64Mb), and here is iomem : - : reserved 0001-0009f3ff : System RAM 0009f400-0009 : reserved 000f-000f : reserved 0010-dfffcfff : System RAM 0100-0147e0ed : Kernel code 0147e0ee-01b4137f : Kernel data 01c34000-01da : Kernel bss dfffd000-dfff : reserved f000-f3ff : :00:02.0 f400-f7ff : :00:02.0 f800-f8001fff : :00:02.0 f801-f801 : :00:02.0 f802-f8020fff : :00:03.0 f802-f8020fff : virtio-pci f803-f803 : :00:03.0 f804-f8043fff : :00:04.0 f804-f8043fff : ICH HD audio f8044000-f8044fff : :00:05.0 f8044000-f8044fff : virtio-pci f8045000-f8045fff : :00:06.0 f8045000-f8045fff : virtio-pci fec0-fec003ff : IOAPIC 0 fed0-fed003ff : HPET 0 fee0-fee00fff : Local APIC fffbc000- : reserved 1-11fff : System RAM At the same time, libvirt log had about 10 handle_dev_input: oom current X pipe 0 message per second. Using the bios from http://spice-space.org/download/seabios/ might help. I just downloaded it, and actually it helps : the vm starts without problem with 128Mb. It seems to be working fine after few minutes, including when I'm watching a video in youtube (this is my usual test...). By the way, I noticed that upscaling seems to work in windows guests, but not linuxes : is it expected? (actually, the video seen in linux is very slow in fullscreen and very smooth in normal mode, while it is always smooth with windows guests). Thanks for your help, Frederic. cheers, Gerd ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
[Spice-devel] spicec or spice-gtk
Which client should one use? I'm a little confused reading the documentation version looking at the download page. http://spice-space.org/page/DeveloperStartPage says, client - this is the old spice client. It is still supported but is being phased out in favor of a new widgetized gtk/glib based implementation called spice-gtk (currently in a separate repository) However, spicec looks like it is in 0.8.1 whereas the download page says gtk is experimental and provides a link with the latest versio being 0.6 from April. Thanks - John ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] spicec or spice-gtk
On Mon, Jul 04, 2011 at 01:25:01PM -0400, John A. Sullivan III wrote: Which client should one use? I'm a little confused reading the documentation version looking at the download page. http://spice-space.org/page/DeveloperStartPage says, client - this is the old spice client. It is still supported but is being phased out in favor of a new widgetized gtk/glib based implementation called spice-gtk (currently in a separate repository) However, spicec looks like it is in 0.8.1 whereas the download page says gtk is experimental and provides a link with the latest versio being 0.6 from April. Thanks - John Tricky question. We support both clients. spicec is being shipped as part of RHEV-M and is more mature. spice-gtk is being shipped with Fedora right now, but will get to RHEL and RHEV-M too probably. spice-gtk is actively developed, spicec less actively developed (not sure that makes sense). ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] spicec or spice-gtk
On Jul 4, 2011 6:25 PM, John A. Sullivan III jsulli...@opensourcedevel.com wrote: However, spicec looks like it is in 0.8.1 whereas the download page says gtk is experimental and provides a link with the latest versio being 0.6 from April. Thanks - John Hi, I believe that spice-gtk follows it's own release cycle so the 0.6 does not mean it is older than the spicec client. ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] Unfair comparisons with RDP
On 07/04/2011 07:33 PM, John A. Sullivan III wrote: On Mon, 2011-07-04 at 17:48 +0300, Yonit Halperin wrote: On 07/04/2011 05:21 PM, John A. Sullivan III wrote: Very helpful and interesting. I'll respond in-line - John On Sun, 2011-07-03 at 10:38 +0300, Yaniv Kaul wrote: On 06/30/2011 10:10 AM, Yaniv Kaul wrote: On 06/30/2011 05:33 AM, John A. Sullivan III wrote: On Wed, 2011-06-29 at 20:22 -0400, Andrew Cathrow wrote: - Original Message - snip Hello, all. I've been using both RDP via TSPlus and SPICE for over a week now and the practical world results at least in my mode of operation are becoming clear. SPICE does handle major screen refreshes better, e.g., monstrous graphics or continuously pasting a full line of text in a full screen notepad. Of course, SPICE is a clear winner when it comes to video though still not practically usable on low bandwidth links. However, RDP is trouncing SPICE in the more common day to day tasks involving small screen updates. For example, every time I open or switch my screen to LibreOffice, the tool bar icons seems to pain one at a time in SPICE where as they appear all at once in TSPlus. Document scrolling is more immediate and smoother. Surprisingly, when I open the PuTTY dialog in SPICE, it paints in sections whereas TSPlus appears all at once. You'll really need to post some real details here - from versions of qemu+spice server that you're using along with the qemu command line syntax, host OS, hardware details through to what's running in the guest, driver versions, etc. I've never seen RDP trounce spice, but if it does, then we need some scientific information on the environment so we can diagnose and assist. snip Very happy to do so as we really do want SPICE to become our protocol of choice. I believe I've posted up our details before but will do so again. Would you be so kind as to capture the Spice traffic (using tcpdump/wireshark) and send it over? Specifically: 1. Please capture from start - before the Spice client connects to the server. 2. Ensure you catch full sized packets (-s - could be 1500 most likely, when using tcpdump) 3. Save into file (-w /tmp/file.pcap when using tcpdump) 4. Please compress and send / let me know where I can pick it up from. I suggest you have only the scenario of connecting to the VM and opening putty, which you complain is slow. Hopefully it'll give us some clue. TIA, Y. disclaimer my Wireshark dissector may be buggy, and I'm basing my analysis on it/disclaimer Initial thoughts, from looking at the packet capture: 1. Initial image (packet 689) is not compressed using ZLIB (but LZ_RGB). Known issue, filed a bug about it somewhere (upstream or Fedora). 2. The same image is actually quite big - 1440x900 - made up of 172 packets, which took 0.42seconds from the first to the last packets. Perhaps splitting it to multiple smaller images would have improved the user experience. That makes sense. I was in full screen mode and my screen is 1440x900. 3. Next image (packet 967) was also using LZ_RGB, and was quite big 1440x793 - made up of 157 packets, and took 0.41 seconds from the first to last packet. Also makes sense - that was probably the toggle into full screen 4. Next image (packet 1023) is nicely compressed using ZLIB_GLZ_RGB. For some reason it does not have the CACHE_ME flag set. The next image (packet 1056) does have it. 5. Looks like you were not using the guest agent and that effects were not turned off? (example, packets 1085, 1580, 1960 which has multiple DRAW_FILL commands) - RDP, at least in previous versions, used to disable them by default. Can you verify the same settings are used with Spice? That's very interesting. We are but we frequently notice it stops and fixing it is one of our higher priorities. I'll recompile and see if I get any better performance and stability. I'll check the effects settings. 6. From packet 1580 and on we see nice use of images from the cache, so caching does appear to be working. It is a bit annoying that a 'use image from cache' for a 16x16 image takes 75 bytes, but it's the protocol. This is a little distressing. I'm guessing those 16x16 images are the LibreOffice tool bar icons. That part is one of the most dramatically slower comparisons for SPICE versus RDP. In RDP, they appear all at once. In SPICE, they paint slowly, one at a time, and perhaps do so a couple of times over - not sure about that last part but the overall experience is that it takes not just a little but many, many, many times longer to paint my LibreOffice screen in SPICE than it does with RDP. 7. Nowhere in the stream do I see JPEG compressed images. Not sure why. Was it enabled (can be seen in server side logs) ? I'll have to have a look. I assume one does not have to actively do something to enable this but rather that it is the default. Is that true? Thanks - John JPEG and ZLIB are only recommended when the connection to the client is limited. They are
[Spice-devel] Problems compiling SPICE Windows client SDK 7.1
Hello, all. Being a Windows ignoramus, I am having a nightmare of a time compiling the Windows client on our Windows 7 build system. I'll recount them for other ignorami and to ask for help for the things I could not figure out. I installed the Windows SDK 7.1 and it installed without compilers because we had .net 3.5 installed. I installed 4.0 and reinstalled the SDK and I know had compilers. The build instructions under Windows say, The prerequisites are available as binaries in one package on the download page. However, I did not see such a binary on the download page. I downloaded spice-0.8.1, spice-protocol-0.8.0, and wspice-x64_20110308. I then did: setenv /Release /x64 /win7 set REDC_BUILD_DIR=D:\Binaries\x64\Win7 set SPICE_PROTOCOL_DIR=C:\Users\Administrator\Downloads\spice \spice-protocol-0.8.0 set SPICE_LIBS=C:\Users\Administrator\Downloads\wspice-x64_08032011 C: cd \Users\Administrator\Downloads\spice\spice-0.8.1\client\windows redc.sln It had no idea of what to do with the file - no association. Some Internet research, reading the SDK Release Notes, and a little while later and I did: msbuild -p:platform=X64 redc.sln It complained that it could not find vcbuild.exe. Some more research and I found that the 7.1 SDK uses msbuild and that it takes a different syntax than vcbuild. It provides vcupgrade to convert the .vcproj files into .vcxproj files but does not convert /sln files. devenv does but that is not in the SDK and must be included with the full Visual Basic I am guessing. So, the instructions said to manually edit the .sln files to use 2010 instead of 2008 and reference .vcxproj files instead of .vcproj files. So, I ran vcupgrade on redc.vcproj, edited redc.sln and tried again. Same failure message about vcbuild.exe. I then looked more closely at the .sln file and it looked like it was merely specifying the build environment options which are no longer necessary with msbuild using the -p:platform= parameter (or so I read) so I tried to simply do msbuild -p:platform=X64 redc.vcxproj. That complained about not finding python. So it looks like python is called in generate.bat. I installed python and it failed again - python was not in the path. So I added it to the path, opened an new SDK shell and tried again. Now I get: C:\Users\Administrator\Downloads\spice\spice-0.8.1\client\windowsmsbuild -p:platform=X64 redc.vcxproj Microsoft (R) Build Engine Version 4.0.30319.1 [Microsoft .NET Framework, Version 4.0.30319.1] Copyright (C) Microsoft Corporation 2007. All rights reserved. Build started 7/4/2011 8:07:48 PM. Project C:\Users\Administrator\Downloads\spice\spice-0.8.1\client\windows\redc.vcxproj on node 1 (default targets). InitializeBuildStatus: Touching D:\Binaries\x64\Win7\X64\Release\redc.unsuccessfulbuild. CustomBuild: Generating demarshaller File ..\..\spice_codegen.py, line 200 print No changes to %s % dest_file ^ SyntaxError: invalid syntax File ..\..\spice_codegen.py, line 200 print No changes to %s % dest_file ^ SyntaxError: invalid syntax C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\Microsoft.CppCommon.targets(1 51,5): error MSB6006: cmd.exe exited with code 1. [C:\Users\Administrator\Dow nloads\spice\spice-0.8.1\client\windows\redc.vcxproj] Done Building Project C:\Users\Administrator\Downloads\spice\spice-0.8.1\clien t\windows\redc.vcxproj (default targets) -- FAILED. Build FAILED. C:\Users\Administrator\Downloads\spice\spice-0.8.1\client\windows\redc.vcxproj (default target) (1) - (CustomBuild target) - C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\Microsoft.CppCommon.targets (151,5): error MSB6006: cmd.exe exited with code 1. [C:\Users\Administrator\D ownloads\spice\spice-0.8.1\client\windows\redc.vcxproj] 0 Warning(s) 1 Error(s) Time Elapsed 00:00:00.65 I'm assuming the code is correct and I have done something wrong. How do I compile the Windows client in my environment? Thanks - John ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
[Spice-devel] Possible Windows vdagent problems
Hello, all. I'm spinning this off of the Unfair Comparisons with RDP thread as that one is getting a bit long. However, in it, Yaniv identified that we were not using vdagent in our Windows guest based upon the packet traces we submitted. That sounded plausible as we have noticed the agent being quite unstable. We are often unable to connect or the session seems to die. We then connect as administrator via RDP and restart the RHEV Spice Agent and all is well again. I was going to recompile it and reinstall however, after fighting all day long to compile the Windows client as I thought that would be an easier test of my Windows compilation prowess as I did not see explicit instructions for compiling vdagent, I realized that http://www.spice-space.org/download/binaries/vdagent-win32_20110428.zip did not contain source but only pre-compiled binaries! So then I thought our qemu configuration must be off or the needed options were not support in our version (0.8.8). However, that does not appear to be the case: controller type='virtio-serial' index='0' address type='pci' domain='0x' bus='0x00' slot='0x09' function='0x0'/ /controller [ports='16' seems to be missing - I tried adding it but it was ignored and subsequently removed] channel type='spicevmc' target type='virtio' name='com.redhat.spice.0'/ address type='virtio-serial' controller='0' bus='0' port='1'/ /channel When I dump the XML to native, I get: -device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x9 -chardev spicevmc,id=charchannel0,name=vdagent -device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=com.redhat.spice.0 So what is wrong that we appear to not be using vdagent and why do we need to keep restarting it? Thanks - John ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
