From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:44823) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T6FLd-00034R-RV for qemu-devel@nongnu.org; Tue, 28 Aug 2012 02:32:26 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1T6FLc-0001O2-RR for qemu-devel@nongnu.org; Tue, 28 Aug 2012 02:32:25 -0400 Received: from mx1.redhat.com ([209.132.183.28]:42523) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T6FLc-0001Nt-IB for qemu-devel@nongnu.org; Tue, 28 Aug 2012 02:32:24 -0400 Message-ID: <503C65F1.5040704@redhat.com> Date: Tue, 28 Aug 2012 08:32:17 +0200 From: Gerd Hoffmann MIME-Version: 1.0 References: <1346084480-7994-1-git-send-email-sandmann@cs.au.dk> In-Reply-To: <1346084480-7994-1-git-send-email-sandmann@cs.au.dk> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH 1/2] spice: Change NUM_SURFACES to 4096 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: =?UTF-8?B?U8O4cmVuIFNhbmRtYW5u?= Cc: Juan Quintela , qemu-devel@nongnu.org, =?UTF-8?B?U8O4cmVuIFNhbmRtYW5uIFBlZGVyc2Vu?= On 08/27/12 18:21, S=C3=B8ren Sandmann wrote: > From: S=C3=B8ren Sandmann Pedersen >=20 > It's not uncommon for an X workload to have more than 1024 pixmaps > live at the same time. Ideally, there wouldn't be any fixed limit like > this, but since we have one, increase it to 4096. > --- > ui/spice-display.h | 2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) >=20 > diff --git a/ui/spice-display.h b/ui/spice-display.h > index 12e50b6..e8d01a5 100644 > --- a/ui/spice-display.h > +++ b/ui/spice-display.h > @@ -32,7 +32,7 @@ > #define MEMSLOT_GROUP_GUEST 1 > #define NUM_MEMSLOTS_GROUPS 2 > =20 > -#define NUM_SURFACES 1024 > +#define NUM_SURFACES 4096 Breaks live migration. First, we must make this runtime-configurable. rev3 qxl devices should continue to operate with 1024 surfaces for compatibility with older qemu versions. Second the vmstate must be adapted to handle this. The number of surfaces is in the migration data stream, so this should be doable without too much trouble. Right now it looks like this: [ ... ] VMSTATE_INT32_EQUAL(num_surfaces, PCIQXLDevice), VMSTATE_ARRAY(guest_surfaces.cmds, PCIQXLDevice, NUM_SURFACES, 0, vmstate_info_uint64, uint64_t), [ ... ] Juan? Suggestions how to handle this? There seems to be no direct way to make the array size depend on num_surfaces. I think we could have two VMSTATE_ARRAY_TEST() entries, one for 1024 and one for 4096. Better ideas? cheers, Gerd