Switch to using the system liblz4.

This brings libxenguest's lz4 decompression in line all the others, rather
than using the unsafe decompressor from Xen (itself a port of Linux's unsafe
decompressor).

Andrew Cooper (2):
  tools/configure: Detect the presence of liblz4
  tools/libs/guest: Use the system liblz4 in the bzimage loader

 automation/build/debian/13-arm64v8.dockerfile |   1 +
 automation/build/debian/13-x86_64.dockerfile  |   1 +
 tools/configure                               |  79 ++++++++++
 tools/configure.ac                            |   4 +
 tools/libs/guest/Makefile.common              |   2 +-
 tools/libs/guest/xg_dom_bzimageloader.c       | 128 +++++++++++++++-
 tools/libs/guest/xg_dom_decompress.h          |   6 -
 tools/libs/guest/xg_dom_decompress_lz4.c      | 143 ------------------
 tools/libs/guest/xg_dom_decompress_unsafe.h   |   2 +
 .../libs/guest/xg_dom_decompress_unsafe_lz4.c |  39 +++++
 10 files changed, 254 insertions(+), 151 deletions(-)
 delete mode 100644 tools/libs/guest/xg_dom_decompress.h
 delete mode 100644 tools/libs/guest/xg_dom_decompress_lz4.c
 create mode 100644 tools/libs/guest/xg_dom_decompress_unsafe_lz4.c


base-commit: c069c014f21fd1f5925d8c30c18adb4f26381475
-- 
2.39.5

On 03.06.2026 10:53, Andrew Cooper wrote:
> Switch to using the system liblz4.
> 
> This brings libxenguest's lz4 decompression in line all the others, rather
> than using the unsafe decompressor from Xen (itself a port of Linux's unsafe
> decompressor).

As stated in 84f04d8f0dbf ("libxc: add LZ4 decompression support"), there was
no shared library available at the time (and on the SLES versions I worked
with). Later a shared library appeared, but the -devel package still wasn't
there. On my main dev system (intentionally a relatively old SLES version) I
therefore wouldn't be able to build/test LZ4 anymore if we went this route.
(FTAOD this isn't an outright objection, as the goal of the series is
certainly good. It is mainly a data point to consider.)

Jan

> Andrew Cooper (2):
>   tools/configure: Detect the presence of liblz4
>   tools/libs/guest: Use the system liblz4 in the bzimage loader
> 
>  automation/build/debian/13-arm64v8.dockerfile |   1 +
>  automation/build/debian/13-x86_64.dockerfile  |   1 +
>  tools/configure                               |  79 ++++++++++
>  tools/configure.ac                            |   4 +
>  tools/libs/guest/Makefile.common              |   2 +-
>  tools/libs/guest/xg_dom_bzimageloader.c       | 128 +++++++++++++++-
>  tools/libs/guest/xg_dom_decompress.h          |   6 -
>  tools/libs/guest/xg_dom_decompress_lz4.c      | 143 ------------------
>  tools/libs/guest/xg_dom_decompress_unsafe.h   |   2 +
>  .../libs/guest/xg_dom_decompress_unsafe_lz4.c |  39 +++++
>  10 files changed, 254 insertions(+), 151 deletions(-)
>  delete mode 100644 tools/libs/guest/xg_dom_decompress.h
>  delete mode 100644 tools/libs/guest/xg_dom_decompress_lz4.c
>  create mode 100644 tools/libs/guest/xg_dom_decompress_unsafe_lz4.c
> 
> 
> base-commit: c069c014f21fd1f5925d8c30c18adb4f26381475

On 6/3/26 11:16 AM, Jan Beulich wrote:
> On 03.06.2026 10:53, Andrew Cooper wrote:
>> Switch to using the system liblz4.
>>
>> This brings libxenguest's lz4 decompression in line all the others, rather
>> than using the unsafe decompressor from Xen (itself a port of Linux's unsafe
>> decompressor).

Generally, the patch series looks straightforward and low risk, so I am 
comfortable taking it for this release. Considering that...

> 
> As stated in 84f04d8f0dbf ("libxc: add LZ4 decompression support"), there was
> no shared library available at the time (and on the SLES versions I worked
> with). Later a shared library appeared, but the -devel package still wasn't
> there. On my main dev system (intentionally a relatively old SLES version) I
> therefore wouldn't be able to build/test LZ4 anymore if we went this route.
> (FTAOD this isn't an outright objection, as the goal of the series is
> certainly good. It is mainly a data point to consider.)

...does not consider this an outright objection. While this may become 
an issue sooner or later on older dev systems, if the change is accepted 
into staging, we could switch to the shared library approach in 4.22.

We should also consider adding a note to CHANGELOG.md.

Thanks.

~ Oleksii

On 6/3/26 3:01 PM, Oleksii Kurochko wrote:
> 
> 
> On 6/3/26 11:16 AM, Jan Beulich wrote:
>> On 03.06.2026 10:53, Andrew Cooper wrote:
>>> Switch to using the system liblz4.
>>>
>>> This brings libxenguest's lz4 decompression in line all the others, 
>>> rather
>>> than using the unsafe decompressor from Xen (itself a port of Linux's 
>>> unsafe
>>> decompressor).
> 
> Generally, the patch series looks straightforward and low risk, so I am 
> comfortable taking it for this release. Considering that...
> 
>>
>> As stated in 84f04d8f0dbf ("libxc: add LZ4 decompression support"), 
>> there was
>> no shared library available at the time (and on the SLES versions I 
>> worked
>> with). Later a shared library appeared, but the -devel package still 
>> wasn't
>> there. On my main dev system (intentionally a relatively old SLES 
>> version) I
>> therefore wouldn't be able to build/test LZ4 anymore if we went this 
>> route.
>> (FTAOD this isn't an outright objection, as the goal of the series is
>> certainly good. It is mainly a data point to consider.)
> 
> ...does not consider this an outright objection. While this may become 
> an issue sooner or later on older dev systems, if the change is accepted 
> into staging, we could switch to the shared library approach in 4.22.

Release-Acked-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>

~ Oleksii

On 08/06/2026 11:51 am, Oleksii Kurochko wrote:
>
>
> On 6/3/26 3:01 PM, Oleksii Kurochko wrote:
>>
>>
>> On 6/3/26 11:16 AM, Jan Beulich wrote:
>>> On 03.06.2026 10:53, Andrew Cooper wrote:
>>>> Switch to using the system liblz4.
>>>>
>>>> This brings libxenguest's lz4 decompression in line all the others,
>>>> rather
>>>> than using the unsafe decompressor from Xen (itself a port of
>>>> Linux's unsafe
>>>> decompressor).
>>
>> Generally, the patch series looks straightforward and low risk, so I
>> am comfortable taking it for this release. Considering that...
>>
>>>
>>> As stated in 84f04d8f0dbf ("libxc: add LZ4 decompression support"),
>>> there was
>>> no shared library available at the time (and on the SLES versions I
>>> worked
>>> with). Later a shared library appeared, but the -devel package still
>>> wasn't
>>> there. On my main dev system (intentionally a relatively old SLES
>>> version) I
>>> therefore wouldn't be able to build/test LZ4 anymore if we went this
>>> route.
>>> (FTAOD this isn't an outright objection, as the goal of the series is
>>> certainly good. It is mainly a data point to consider.)
>>
>> ...does not consider this an outright objection. While this may
>> become an issue sooner or later on older dev systems, if the change
>> is accepted into staging, we could switch to the shared library
>> approach in 4.22.
>
> Release-Acked-by: Oleksii Kurochko <oleksii.kurochko@gmail.com> 

I've included this incremental diff for CHANGELOG.

diff --git a/CHANGELOG.md b/CHANGELOG.md
index 1db3efc4864c..5cf19372a361 100644
--- a/CHANGELOG.md
+++ b/CHANGELOG.md
@@ -13,6 +13,7 @@ The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/)
    represent a wildcard input.
  - On x86:
    - Enable pf-fixup option by default for PVH dom0.
+   - The libxenguest bzImage loader now uses the system liblz4 library.
 
 ### Added
  - Support for per-domain Xenstore quota in C xenstored (includes


~Andrew

On 6/8/26 12:57 PM, Andrew Cooper wrote:
> On 08/06/2026 11:51 am, Oleksii Kurochko wrote:
>>
>>
>> On 6/3/26 3:01 PM, Oleksii Kurochko wrote:
>>>
>>>
>>> On 6/3/26 11:16 AM, Jan Beulich wrote:
>>>> On 03.06.2026 10:53, Andrew Cooper wrote:
>>>>> Switch to using the system liblz4.
>>>>>
>>>>> This brings libxenguest's lz4 decompression in line all the others,
>>>>> rather
>>>>> than using the unsafe decompressor from Xen (itself a port of
>>>>> Linux's unsafe
>>>>> decompressor).
>>>
>>> Generally, the patch series looks straightforward and low risk, so I
>>> am comfortable taking it for this release. Considering that...
>>>
>>>>
>>>> As stated in 84f04d8f0dbf ("libxc: add LZ4 decompression support"),
>>>> there was
>>>> no shared library available at the time (and on the SLES versions I
>>>> worked
>>>> with). Later a shared library appeared, but the -devel package still
>>>> wasn't
>>>> there. On my main dev system (intentionally a relatively old SLES
>>>> version) I
>>>> therefore wouldn't be able to build/test LZ4 anymore if we went this
>>>> route.
>>>> (FTAOD this isn't an outright objection, as the goal of the series is
>>>> certainly good. It is mainly a data point to consider.)
>>>
>>> ...does not consider this an outright objection. While this may
>>> become an issue sooner or later on older dev systems, if the change
>>> is accepted into staging, we could switch to the shared library
>>> approach in 4.22.
>>
>> Release-Acked-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
> 
> I've included this incremental diff for CHANGELOG.
> 
> diff --git a/CHANGELOG.md b/CHANGELOG.md
> index 1db3efc4864c..5cf19372a361 100644
> --- a/CHANGELOG.md
> +++ b/CHANGELOG.md
> @@ -13,6 +13,7 @@ The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/)
>      represent a wildcard input.
>    - On x86:
>      - Enable pf-fixup option by default for PVH dom0.
> +   - The libxenguest bzImage loader now uses the system liblz4 library.

Looks good to me.

Thanks.

~ Oleksii

On 03/06/2026 10:16 am, Jan Beulich wrote:
> On 03.06.2026 10:53, Andrew Cooper wrote:
>> Switch to using the system liblz4.
>>
>> This brings libxenguest's lz4 decompression in line all the others, rather
>> than using the unsafe decompressor from Xen (itself a port of Linux's unsafe
>> decompressor).
> As stated in 84f04d8f0dbf ("libxc: add LZ4 decompression support"), there was
> no shared library available at the time (and on the SLES versions I worked
> with). Later a shared library appeared, but the -devel package still wasn't
> there. On my main dev system (intentionally a relatively old SLES version) I
> therefore wouldn't be able to build/test LZ4 anymore if we went this route.
> (FTAOD this isn't an outright objection, as the goal of the series is
> certainly good. It is mainly a data point to consider.)

That was 13 years ago.  Are you saying that there's still an in-support
version of SLES which doesn't have liblz4 ?

~Andrew

On 03.06.2026 11:21, Andrew Cooper wrote:
> On 03/06/2026 10:16 am, Jan Beulich wrote:
>> On 03.06.2026 10:53, Andrew Cooper wrote:
>>> Switch to using the system liblz4.
>>>
>>> This brings libxenguest's lz4 decompression in line all the others, rather
>>> than using the unsafe decompressor from Xen (itself a port of Linux's unsafe
>>> decompressor).
>> As stated in 84f04d8f0dbf ("libxc: add LZ4 decompression support"), there was
>> no shared library available at the time (and on the SLES versions I worked
>> with). Later a shared library appeared, but the -devel package still wasn't
>> there. On my main dev system (intentionally a relatively old SLES version) I
>> therefore wouldn't be able to build/test LZ4 anymore if we went this route.
>> (FTAOD this isn't an outright objection, as the goal of the series is
>> certainly good. It is mainly a data point to consider.)
> 
> That was 13 years ago.  Are you saying that there's still an in-support
> version of SLES which doesn't have liblz4 ?

If "in-support" includes LTSS, then yes as far as liblz4-devel goes. If you
mean only ordinary support, then (afaict) no.

Jan