On 08/27/12 18:21, Søren Sandmann wrote:
> From: Søren Sandmann Pedersen <s...@redhat.com>
>
> 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(-)
>
> 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
>
> -#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
