* Peter Maydell (peter.mayd...@linaro.org) wrote: > On Mon, 4 Jul 2022 at 17:43, Ilya Leoshkevich <i...@linux.ibm.com> wrote: > > > > zlib_send_prepare() compresses pages of a running VM. zlib does not > > make any thread-safety guarantees with respect to changing deflate() > > input concurrently with deflate() [1]. > > > > One can observe problems due to this with the IBM zEnterprise Data > > Compression accelerator capable zlib [2]. When the hardware > > acceleration is enabled, migration/multifd/tcp/plain/zlib test fails > > intermittently [3] due to sliding window corruption. The accelerator's > > architecture explicitly discourages concurrent accesses [4]: > > > > Page 26-57, "Other Conditions": > > > > As observed by this CPU, other CPUs, and channel > > programs, references to the parameter block, first, > > second, and third operands may be multiple-access > > references, accesses to these storage locations are > > not necessarily block-concurrent, and the sequence > > of these accesses or references is undefined. > > > > Mark Adler pointed out that vanilla zlib performs double fetches under > > certain circumstances as well [5], therefore we need to copy data > > before passing it to deflate(). > > > > [1] https://zlib.net/manual.html > > [2] https://github.com/madler/zlib/pull/410 > > [3] https://lists.nongnu.org/archive/html/qemu-devel/2022-03/msg03988.html > > [4] http://publibfp.dhe.ibm.com/epubs/pdf/a227832c.pdf > > [5] https://gitlab.com/qemu-project/qemu/-/issues/1099 > > Is this [5] the wrong link? It's to our issue tracker, not zlib's > or a zlib mailing list thread, and it doesn't contain any messages > from Mark Adler.
Looking at Mark's message, I'm not seeing that it was cc'd to the lists. I did however ask him to update zlib's docs to describe the requirement. Dave > thanks > -- PMM > -- Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
