Re: [PATCH v1 1/6] tools/migration: introduce PAGE_DATA_LZ4 stream record type

On 20/07/2026 4:48 pm, Marcus Granado wrote:
> diff --git a/docs/specs/libxc-migration-stream.pandoc b/docs/specs/libxc-migration-stream.pandoc
> index 1319ce1f1e..7469c95139 100644
> --- a/docs/specs/libxc-migration-stream.pandoc
> +++ b/docs/specs/libxc-migration-stream.pandoc
> @@ -359,6 +360,68 @@ tail.
>  
>  \clearpage
>  
> +PAGE_DATA_LZ4
> +-------------
> +
> +A PAGE_DATA_LZ4 record carries exactly the same information as a
> +PAGE_DATA record, but with the page contents LZ4-compressed.  The saver
> +may emit it in place of a PAGE_DATA record when LZ4 compression has been
> +requested.
> +
> +     0     1     2     3     4     5     6     7 octet
> +    +-----------------------+-------------------------+
> +    | count (C)             | (reserved)              |
> +    +-----------------------+-------------------------+

This reserved field in the original PAGE_DATA was earmarked for
compression information, but that was on the expectation that we'd be
compressing the whole record in one go.  We're going to need to figure
out that part first.

A complication with compressing in a single block is that we end up with
disjoint ranges for any PV pagetable, and for holes in HVM guests,
although Frediano's foreign-copy work could be adjusted to arrange for
the pagedata to be contiguous.


Another question was about the choice of algorithm.  Yes we could use
any algorithm, but CPU time in dom0 is at a premium and we want to
favour speed over compression ratio.  LZ4 does this.  ZSTD might be
acceptable too.  The others are unlikely to be a win.

While this is going off topic, it's worth at least mentioning.  Another
optimisation I had in mind was to remember the last version of a page
that we sent, and on subsequent iterations, XOR the current contents
with the old contents.  I posit that plenty of dirty pages will only
have a small amount dirty compared to the previous send, meaning the XOR
of the two will be mostly zeroes, and run-length encode very well.  The
downside is extra memory overhead on the source side, so it's not an
automatic win.

~Andrew