From 09f7d696dae5ddd334935287b8d306255e6b22a5 Mon Sep 17 00:00:00 2001 From: Christophe Fergeau Date: Tue, 6 Oct 2015 18:15:53 +0200 Subject: [PATCH] Update to new 0.12.6 upstream release --- .gitignore | 1 + ...e-48kHz-for-playback-recording-rates.patch | 53 ------ ...assert-if-MIGRATE_DATA-comes-before-.patch | 165 ------------------ sources | 2 +- spice.spec | 11 +- 5 files changed, 7 insertions(+), 225 deletions(-) delete mode 100644 0001-spice.h-Don-t-use-48kHz-for-playback-recording-rates.patch delete mode 100644 0002-migration-Don-t-assert-if-MIGRATE_DATA-comes-before-.patch diff --git a/.gitignore b/.gitignore index 5b72b89..c5f81b2 100644 --- a/.gitignore +++ b/.gitignore @@ -18,3 +18,4 @@ spice-0.5.3.tar.bz2 /spice-0.12.3.tar.bz2 /spice-0.12.4.tar.bz2 /spice-0.12.5.tar.bz2 +/spice-0.12.6.tar.bz2 diff --git a/0001-spice.h-Don-t-use-48kHz-for-playback-recording-rates.patch b/0001-spice.h-Don-t-use-48kHz-for-playback-recording-rates.patch deleted file mode 100644 index 5b8ec73..0000000 --- a/0001-spice.h-Don-t-use-48kHz-for-playback-recording-rates.patch +++ /dev/null @@ -1,53 +0,0 @@ -From a6e29ce42fff526ab59096634d721254d6bcfc16 Mon Sep 17 00:00:00 2001 -From: Christophe Fergeau -Date: Tue, 19 Aug 2014 11:09:05 +0200 -Subject: [PATCH] spice.h: Don't use 48kHz for playback/recording rates - -When adding Opus support, SPICE_INTERFACE_PLAYBACK_FREQ and -SPICE_INTERFACE_RECORD_FREQ in the public header 'spice.h' were changed -from 44100 to 48000. -However, this was not really useful as these constants are not used in -spice-server, but only by users of spice-server (ie QEMU). -It turns out changing these values is actually harmful. QEMU uses these -constants in 2 situations: -1. when it's a version of QEMU with this commit, but we are compiling - against older spice-server headers (before Opus support was added) -2. when it's a version of QEMU without commit 795ca114d35 which added - what is needed for Opus support - -When we are in the second situation, having 48000 in the public header -will actually cause issues as spice-server will know QEMU does not -support Opus, so internally spice-server will be using a 44100 rate for -audio. However, QEMU will be using SPICE_INTERFACE_.*_FREQ and think it -should use a 48000 rate, which will cause distorsions as experienced in -bug https://bugzilla.redhat.com/show_bug.cgi?id=1129961 - -Reverting these constants back to 44100 will fix audio in the 'new -spice-server/old QEMU' scenario, and won't cause issues either when both -support Opus as in this case these constants are not used. ---- - server/spice.h | 4 ++-- - 1 file changed, 2 insertions(+), 2 deletions(-) - -diff --git a/server/spice.h b/server/spice.h -index c648a1d..58700d1 100644 ---- a/server/spice.h -+++ b/server/spice.h -@@ -342,7 +342,7 @@ enum { - SPICE_INTERFACE_AUDIO_FMT_S16 = 1, - }; - --#define SPICE_INTERFACE_PLAYBACK_FREQ 48000 -+#define SPICE_INTERFACE_PLAYBACK_FREQ 44100 - #define SPICE_INTERFACE_PLAYBACK_CHAN 2 - #define SPICE_INTERFACE_PLAYBACK_FMT SPICE_INTERFACE_AUDIO_FMT_S16 - -@@ -372,7 +372,7 @@ typedef struct SpiceRecordInterface SpiceRecordInterface; - typedef struct SpiceRecordInstance SpiceRecordInstance; - typedef struct SpiceRecordState SpiceRecordState; - --#define SPICE_INTERFACE_RECORD_FREQ 48000 -+#define SPICE_INTERFACE_RECORD_FREQ 44100 - #define SPICE_INTERFACE_RECORD_CHAN 2 - #define SPICE_INTERFACE_RECORD_FMT SPICE_INTERFACE_AUDIO_FMT_S16 - diff --git a/0002-migration-Don-t-assert-if-MIGRATE_DATA-comes-before-.patch b/0002-migration-Don-t-assert-if-MIGRATE_DATA-comes-before-.patch deleted file mode 100644 index c854f0e..0000000 --- a/0002-migration-Don-t-assert-if-MIGRATE_DATA-comes-before-.patch +++ /dev/null @@ -1,165 +0,0 @@ -From d6381c21c7076d9adbaa10ee0ddf119691a864a1 Mon Sep 17 00:00:00 2001 -From: Uri Lublin -Date: Wed, 16 Jul 2014 17:02:04 +0300 -Subject: [PATCH] migration: Don't assert() if MIGRATE_DATA comes before - attaching the agent - -During seamless migration, after switching host, if a client was connected -during the migration, it will have data to send back to the new -qemu/spice-server instance. This is handled through MIGRATE_DATA messages. -SPICE char devices use such MIGRATE_DATA messages to restore their state. - -However, the MIGRATE_DATA message can arrive any time after the new qemu -instance has started, this can happen before or after the SPICE char -devices have been created. In order to handle this, if the migrate data -arrives early, it's stored in reds->agent_state.mig_data, and -attach_to_red_agent() will restore the agent state as appropriate. - -Unfortunately this does not work as expected, for main -channel (agent messages). -If attach_to_red_agent() is called before the MIGRATE_DATA -message reaches the server, all goes well, -but if MIGRATE_DATA reaches the server before -attach_to_red_agent() gets called, then some assert() gets -triggered in spice_char_device_state_restore(): - -((null):32507): Spice-ERROR **: char_device.c:937:spice_char_device_state_restore: assertion `dev->num_clients == 1 && dev->wait_for_migrate_data' failed -Thread 3 (Thread 0x7f406b543700 (LWP 32543)): -Thread 2 (Thread 0x7f40697ff700 (LWP 32586)): -Thread 1 (Thread 0x7f4079b45a40 (LWP 32507)): - -When restoring state, a client must already be added to the -spice-char-device. -What happens is that a client is not being added to the char-device -when when MIGRATE_DATA arrives first, which leaves both -dev->num_clients and dev->wait_for_migrate_data value at 0. - -This commit changes the logic in spice_server_char_device_add_interface(), -such that if there is migrate data pending in reds->agent_state.mig_data -but no client was added to the spice-char-device yet, -then first the client is added to the device by calling -spice_char_device_client_add(), and only then the state is restored. - -=== How to Reproduce -To reproduce, add delays to the migration connection between -qmeu-kvm on the source host (SRC) and on the destination (DST). - -Specifically I added a man in the middle DLY host between -migration ports from SRC to DST. - -+-----+ +-----+ +-----+ -| SRC |--> | DLY | --> | DST | -+-----+ +-----+ +-----+ - -DLY listens on port P1 (e.g. 4444) and DST listens on port -PINCOMING (e.g. 4444, from qemu-kvm '-incoming' command line option) - -Precondition: make sure port P1 on DLY is accessible in iptables. -Option 1: use ssh tcp port forwarding -On DLY host run ssh: - ssh DLY:P1:DST:PINCOMING DST -Then use the following migration command (on qemu-kvm monitor): - client_migrate_info spice DST PSPICE - migrate -d tcp:DLY:P1 - -Option 2: Use a simple proxy program that forwards -packets from SRC to DST while adding some delays. -The program runs on DLY, listens to port D1, upon -accept connects to DST:PINCOMING and forward all -packets from DLY:D1 to DST:PINCOMING. -Then use the same migrate command as in option 1: - client_migrate_info spice DST PSPICE - migrate -d tcp:DLY:P1 - -=== How to Reproduce Ends - -This fixes https://bugzilla.redhat.com/show_bug.cgi?id=1035184 - -Based-on-a-patch-by: Christophe Fergeau ---- - server/reds.c | 39 ++++++++++++++++++++++++++++----------- - 1 file changed, 28 insertions(+), 11 deletions(-) - -diff --git a/server/reds.c b/server/reds.c -index 2c437ac..ed142ec 100644 ---- a/server/reds.c -+++ b/server/reds.c -@@ -1274,6 +1274,7 @@ int reds_handle_migrate_data(MainChannelClient *mcc, SpiceMigrateDataMain *mig_d - { - VDIPortState *agent_state = &reds->agent_state; - -+ spice_debug("main-channel: got migrate data"); - /* - * Now that the client has switched to the target server, if main_channel - * controls the mm-time, we update the client's mm-time. -@@ -1295,15 +1296,18 @@ int reds_handle_migrate_data(MainChannelClient *mcc, SpiceMigrateDataMain *mig_d - main_channel_push_agent_disconnected(reds->main_channel); - main_channel_push_agent_connected(reds->main_channel); - } else { -+ spice_debug("restoring state from mig_data"); - return reds_agent_state_restore(mig_data); - } - } - } else { - /* restore agent starte when the agent gets attached */ -+ spice_debug("saving mig_data"); - spice_assert(agent_state->plug_generation == 0); - agent_state->mig_data = spice_memdup(mig_data, size); - } - } else { -+ spice_debug("agent was not attached on the source host"); - if (vdagent) { - /* spice_char_device_client_remove disables waiting for migration data */ - spice_char_device_client_remove(agent_state->base, -@@ -2857,17 +2861,15 @@ static SpiceCharDeviceState *attach_to_red_agent(SpiceCharDeviceInstance *sin) - state->read_filter.discard_all = FALSE; - reds->agent_state.plug_generation++; - -- if (reds->agent_state.mig_data) { -- spice_assert(reds->agent_state.plug_generation == 1); -- reds_agent_state_restore(reds->agent_state.mig_data); -- free(reds->agent_state.mig_data); -- reds->agent_state.mig_data = NULL; -- } else if (!red_channel_waits_for_migrate_data(&reds->main_channel->base)) { -- /* we will assoicate the client with the char device, upon reds_on_main_agent_start, -- * in response to MSGC_AGENT_START */ -- main_channel_push_agent_connected(reds->main_channel); -- } else { -- spice_debug("waiting for migration data"); -+ if (reds->agent_state.mig_data || -+ red_channel_waits_for_migrate_data(&reds->main_channel->base)) { -+ /* Migration in progress (code is running on the destination host): -+ * 1. Add the client to spice char device, if it was not already added. -+ * 2.a If this (qemu-kvm state load side of migration) happens first -+ * then wait for spice migration data to arrive. Otherwise -+ * 2.b If this happens second ==> we already have spice migrate data -+ * then restore state -+ */ - if (!spice_char_device_client_exists(reds->agent_state.base, reds_get_client())) { - int client_added; - -@@ -2883,9 +2885,24 @@ static SpiceCharDeviceState *attach_to_red_agent(SpiceCharDeviceInstance *sin) - spice_warning("failed to add client to agent"); - reds_disconnect(); - } -+ } - -+ if (reds->agent_state.mig_data) { -+ spice_debug("restoring state from stored migration data"); -+ spice_assert(reds->agent_state.plug_generation == 1); -+ reds_agent_state_restore(reds->agent_state.mig_data); -+ free(reds->agent_state.mig_data); -+ reds->agent_state.mig_data = NULL; - } -+ else { -+ spice_debug("waiting for migration data"); -+ } -+ } else { -+ /* we will associate the client with the char device, upon reds_on_main_agent_start, -+ * in response to MSGC_AGENT_START */ -+ main_channel_push_agent_connected(reds->main_channel); - } -+ - return state->base; - } - diff --git a/sources b/sources index 2e576dc..2a8a783 100644 --- a/sources +++ b/sources @@ -1 +1 @@ -1256286214fe402703c0a01bd3a85319 spice-0.12.5.tar.bz2 +605a8c8ea80bc95076c4b3539c6dd026 spice-0.12.6.tar.bz2 diff --git a/spice.spec b/spice.spec index 06fa05f..732ae92 100644 --- a/spice.spec +++ b/spice.spec @@ -1,13 +1,11 @@ Name: spice -Version: 0.12.5 -Release: 9%{?dist} +Version: 0.12.6 +Release: 1%{?dist} Summary: Implements the SPICE protocol Group: User Interface/Desktops License: LGPLv2+ URL: http://www.spice-space.org/ Source0: http://www.spice-space.org/download/releases/%{name}-%{version}.tar.bz2 -Patch0: 0001-spice.h-Don-t-use-48kHz-for-playback-recording-rates.patch -Patch1: 0002-migration-Don-t-assert-if-MIGRATE_DATA-comes-before-.patch # https://bugzilla.redhat.com/show_bug.cgi?id=613529 %if 0%{?rhel} @@ -63,8 +61,6 @@ using spice-server, you will need to install spice-server-devel. %prep %setup -q -%patch0 -p1 -%patch1 -p1 %build @@ -95,6 +91,9 @@ mkdir -p %{buildroot}%{_libexecdir} %changelog +* Tue Oct 06 2015 Christophe Fergeau 0.12.6-1 +- Update to new 0.12.6 upstream release + * Wed Jul 29 2015 Christophe Fergeau 0.12.5-9 - Drop patch added in previous build which is no longer needed with spice-protocol 0.12.9 (and actually is actually breaking QEMU compilation