single-malloc-dfltcc-20240521

Adapt DFLTCC code to the new memory management

dfltcc-inflate-small-window-20221123: IBM zSystems DFLTCC: Support inflate with small window

There is no hardware control for DFLTCC window size, and because of
that supporting small windows for deflate is not trivial: one has to
make sure that DFLTCC does not emit large distances, which most likely
entails somehow trimming the window and/or input in order to make sure
that whave + avail_in <= wsize.

But inflate is much easier: one only has to allocate enough space. Do
that in dfltcc_alloc_window(), and also introduce ZCOPY_WINDOW() in
order to copy everything, not just what the software implementation
cares about.

After this change, software and hardware window formats no longer
match: the software will use wbits and wsize, and the hardware will use
HB_BITS and HB_SIZE. Unlike deflate, inflate does not switch between
software and hardware implementations mid-stream, which leaves only
inflateSetDictionary() and inflateGetDictionary() interesting.

dfltcc-inflate-small-window-20221020: IBM zSystems DFLTCC: Support inflate with small window

There is no hardware control for DFLTCC window size, and because of
that supporting small windows for deflate is not trivial: one has to
make sure that DFLTCC does not emit large distances, which most likely
entails somehow trimming the window and/or input in order to make sure
that whave + avail_in <= wsize.

But inflate is much easier: one only has to allocate enough space. Do
that in dfltcc_alloc_window(), and also introduce ZCOPY_WINDOW() in
order to copy everything, not just what the software implementation
cares about.

After this change, software and hardware window formats no longer
match: the software will use wbits and wsize, and the hardware will use
HB_BITS and HB_SIZE. Unlike deflate, inflate does not switch between
software and hardware implementations mid-stream, which leaves only
inflateSetDictionary() and inflateGetDictionary() interesting.

inline-v1: IBM Z DFLTCC: Buffer deflate() input data

When testing QEMU live migration on an IBM z15 machine, a problem with
DFLTCC was discovered: modifying dfltcc_cmpr() input data concurrently
with dfltcc_cmpr() leads to data corruption  [1] [2].

Based on zlib manual, one might argue both ways whether it is safe to
perform such concurrent modifications. At the end of the day, it's
simply undefined, and now we know that there are applications out there
that rely on this being allowed.

So tolerate this in the DFLTCC implementation by introducing a
buffering layer.

[1] https://lists.gnu.org/archive/html/qemu-devel/2022-03/msg06841.html
[2] https://lists.gnu.org/archive/html/qemu-devel/2022-04/msg00329.html

crc32-vx: IBM Z: Add vectorized CRC32 implementation

While DFLTCC takes care of accelerating compression on level 1, other
levels can be sped up too by computing CRC32 using various vector
instructions.

Take the Linux kernel assembly code that does that - its original
author (Hendrik Brueckner) works for IBM at the time of writing and has
allowed reusing the code under the zlib license. Rewrite it in C for
better maintainability, but keep the original structure, variable names
and comments.

Update the documentation.

Add CI configurations.