Am Thu, 22 Apr 2021 12:49:14 +0100
schrieb Andrew Cooper <andrew.cooper3@citrix.com>:

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

I did not benchmark this code movement.
Now I wonder what the runtime cost of the move really is.

The other pending series eliminates repeated malloc/free, which will
most likely be independent from place where the callers are located.

> 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.

I think being more serious about the CONFIG_MIGRATE conditional is way
outside the scope of this change. Given that this conditional exists
since 15 years, libxl should have been the first user of it by disabling
alot of code that handles save/restore/migrate.

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

Since the code does just save and restore, "saverestore" looks appropriate
to me. "migrate" just builds on top of the save/restore concept by running
it on two different hosts at the same time.

Olaf