[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [XEN PATCH 2/2] x86/Dom0: Use streaming decompression for ZSTD compressed kernels


  • To: Rafaël Kooi <rafael_andreas@xxxxxxxxxxx>
  • From: Jan Beulich <jbeulich@xxxxxxxx>
  • Date: Wed, 10 May 2023 10:03:03 +0200
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=suse.com; dmarc=pass action=none header.from=suse.com; dkim=pass header.d=suse.com; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=pVAIGQMnGL6MDJ42uGSoqBIUzYduE/3zimVh4z8RD6M=; b=Jm5pHSC3OKLeuq4ilPtvcVdjKiur92osYcJ8K86xyDipQhOl+3cggZQaPEA9l2Hc87/R6VQLsCfBs5h6ux1oukBDMq/cHXKuVUjxavB+RE1UFiP2r8R1kitcHL+Q0s1gHZsev2KzJSxnYoFXCxsr13KNfz2sQ6ftYS0T8Q5q6eEwOxvLob+L39EFeD/MYXI8XxMawN4RMbKkN5N2RSOAX90gIQAv7FZPLEnH9EuylaaeEVUVfNdgZNjpoer7kL+eBD+Kpl+iLR2zlm6AdCAzPptZWpoClU1KthN2zrFqb6mOoVr4b0E5Dl9bLVslxUz6BW0J7I6q5ORrO8ujnhzwoA==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=L5RY3f4CO4rCqU7IDnvx3lUUT/gv13SDXAh8lMH1udCL3LOqe0Cow8Cb4fl8XTbm4RjU0iG1h2IN5va8Nqd2Gy10GEcLO4YGt40RYyGIP2s3LWju37OntGhEFSnlyErbPCPuz/Ar1/Xakd6KEaJRDyldcbTFApjA/LJrvzmOZzIaaPuFNOWa8Oy6DdWkTOMkXgVhKioTItbubtqfoGAuy9MEeo/eM6wdqYcZQbLnCt6LzHg4p+9RNXBoyXqbnubgv2J5rJc0UR9hR5GkiZcn1BlbxeWeSRXta9vb5aEPyJRNm7P4katUdhwcwWdriKtG3g3o/r45SyHzLaU+a1NaYA==
  • Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=suse.com;
  • Cc: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, George Dunlap <george.dunlap@xxxxxxxxxx>, Julien Grall <julien@xxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxxx
  • Delivery-date: Wed, 10 May 2023 08:03:28 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 10.05.2023 02:18, Rafaël Kooi wrote:
> On Arch Linux kernel decompression will fail when Xen has been unified
> with the kernel and initramfs as a single binary. This change works for
> both streaming and non-streaming ZSTD content.

This could do with better explaining what "unified" means, and how
streaming decompression actually makes a difference.

> --- a/xen/common/decompress.c
> +++ b/xen/common/decompress.c
> @@ -3,11 +3,26 @@
>  #include <xen/string.h>
>  #include <xen/decompress.h>
>  
> +typedef struct _ZSTD_state
> +{
> +    void *write_buf;
> +    unsigned int write_pos;
> +} ZSTD_state;
> +
>  static void __init cf_check error(const char *msg)
>  {
>      printk("%s\n", msg);
>  }
>  
> +static int __init cf_check ZSTD_flush(void *buf, unsigned int pos,
> +                                      void *userptr)
> +{
> +    ZSTD_state *state = (ZSTD_state*)userptr;
> +    memcpy(state->write_buf + state->write_pos, buf, pos);
> +    state->write_pos += pos;
> +    return pos;
> +}

This doesn't really belong here, but will (I expect) go away anyway once
you drop the earlier patch.

> @@ -17,22 +32,32 @@ int __init decompress(void *inbuf, unsigned int len, void 
> *outbuf)
>  #endif
>  
>      if ( len >= 3 && !memcmp(inbuf, "\x42\x5a\x68", 3) )
> -        return bunzip2(inbuf, len, NULL, NULL, outbuf, NULL, error);
> +        return bunzip2(inbuf, len, NULL, NULL, outbuf, NULL, error, NULL);
>  
>      if ( len >= 6 && !memcmp(inbuf, "\3757zXZ", 6) )
> -        return unxz(inbuf, len, NULL, NULL, outbuf, NULL, error);
> +        return unxz(inbuf, len, NULL, NULL, outbuf, NULL, error, NULL);
>  
>      if ( len >= 2 && !memcmp(inbuf, "\135\000", 2) )
> -        return unlzma(inbuf, len, NULL, NULL, outbuf, NULL, error);
> +        return unlzma(inbuf, len, NULL, NULL, outbuf, NULL, error, NULL);
>  
>      if ( len >= 5 && !memcmp(inbuf, "\x89LZO", 5) )
> -        return unlzo(inbuf, len, NULL, NULL, outbuf, NULL, error);
> +        return unlzo(inbuf, len, NULL, NULL, outbuf, NULL, error, NULL);
>  
>      if ( len >= 2 && !memcmp(inbuf, "\x02\x21", 2) )
> -     return unlz4(inbuf, len, NULL, NULL, outbuf, NULL, error);
> +        return unlz4(inbuf, len, NULL, NULL, outbuf, NULL, error, NULL);

This also looks wrong here - if the earlier patch was to be kept, I expect
all these adjustments would have to move there. Otherwise build would be
broken when just the 1st patch is in place.

>      if ( len >= 4 && !memcmp(inbuf, "\x28\xb5\x2f\xfd", 4) )
> -     return unzstd(inbuf, len, NULL, NULL, outbuf, NULL, error);
> +    {
> +        // NOTE (Rafaël): On Arch Linux the kernel is compressed in a way
> +        // that requires streaming ZSTD decompression. Otherwise 
> decompression
> +        // will fail when using a unified EFI binary. Somehow decompression
> +        // works when not using a unified EFI binary, I suspect this is the
> +        // kernel self decompressing. Or there is a code path that I am not
> +        // aware of that takes care of the use case properly.

Along the lines of what I've said for the description, this wants to avoid
terms like "somehow" if at all possible.

We also don't normally put our names in such comments.

Finally please see ./CODING_STYLE for how we expect comments to be
formatted.

Jan



 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.