Re: [PATCH v4] tools: create libxensaverestore

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 15/04/2021 14:11, Olaf Hering wrote:
> Move all save/restore related code from libxenguest.so into a separate
> library libxensaverestore.so. The only consumer is libxl-save-helper.

"in tree consumer".

It's not the only consumer, but XenServer's equivalent of
libxl-save-helper is in a position to consume this library.

That said, if you've dropped the plans for the static version, I don't
see what the point is.  You're literally saving 15 pages of memory (so
nothing in the grand scheme of a userspace process), at the cost of
added effort for the dynamic loader.

In this form, there's a reasonable chance that it adds to the perf
problems you're trying to address.

> There is no need to have the moved code mapped all the time in binaries
> where libxenguest.so is used.
>
> According to size(1) the change is:
>    text          data     bss     dec     hex filename
>  187183          4304      48  191535   2ec2f guest/libxenguest.so.4.15.0
>
>  124106          3376      48  127530   1f22a guest/libxenguest.so.4.15.0
>   67841          1872       8   69721   11059 
> saverestore/libxensaverestore.so.4.15.0
>
> While touching the files anyway, take the opportunity to drop the
> reduntant xg_sr_ filename prefix.
>
> Signed-off-by: Olaf Hering <olaf@xxxxxxxxx>
> ---
> diff --git a/tools/libs/saverestore/Makefile b/tools/libs/saverestore/Makefile
> new file mode 100644
> index 0000000000..48728b3be2
> --- /dev/null
> +++ b/tools/libs/saverestore/Makefile
> @@ -0,0 +1,38 @@
> +XEN_ROOT = $(CURDIR)/../../..
> +include $(XEN_ROOT)/tools/Rules.mk
> +
> +ifeq ($(CONFIG_MIGRATE),y)
> +SRCS-y += common.c
> +SRCS-$(CONFIG_X86) += common_x86.c
> +SRCS-$(CONFIG_X86) += common_x86_pv.c
> +SRCS-$(CONFIG_X86) += restore_x86_pv.c
> +SRCS-$(CONFIG_X86) += restore_x86_hvm.c
> +SRCS-$(CONFIG_X86) += save_x86_pv.c
> +SRCS-$(CONFIG_X86) += save_x86_hvm.c
> +SRCS-y += restore.c
> +SRCS-y += save.c
> +else
> +SRCS-y += nomigrate.c
> +endif

Depending on the answers to the general question above...

I don't think pulling nomigrate into this new library is sensible.  A
dedicate migration library, stubbed to errors based on some exterior
setting, is very rude.

Given the proposed new structure, the way this ought to be expressed is
libxl-save-restore-helper being conditional on CONFIG_MIGRATE in the
first place.

Also, xensaverestore is a mouthful.  If we are changing things, how
about xenmigrate instead?

~Andrew