From: Julien Grall <jgrall@amazon.com>

Hi all,

The main goal of this series is to address the bug report [1]. It is not
possible

While testing the series, I also noticed that it is not possible to
re-use the same compressed kernel for multiple domains as the module
will be overwritten during the first decompression.

I am still a bit undecided how to fix it. We can either create a new
module for the uncompressed kernel and link with the compressed kernel.
Or we could decompress everytime.

One inconvenience to kernel to only decompress once is we have to keep
it until all the domains have booted. This may means a lot of memory to be
wasted just for keeping the uncompressed kernel (one my setup, it takes
~3 times more space).

Any opinions on how to approach it?

Cheers,

[1] https://lists.xenproject.org/archives/html/xen-users/2021-02/msg00027.html

Julien Grall (2):
  xen/arm: kernel: Propagate the error if we fail to decompress the
    kernel
  xen/gunzip: Allow perform_gunzip() to be called multiple times

 xen/arch/arm/kernel.c | 8 +++++++-
 xen/common/gunzip.c   | 5 +++++
 xen/common/inflate.c  | 6 ++++++
 3 files changed, 18 insertions(+), 1 deletion(-)

-- 
2.17.1

On 02.04.2021 17:21, Julien Grall wrote:
> From: Julien Grall <jgrall@amazon.com>
> 
> Hi all,
> 
> The main goal of this series is to address the bug report [1]. It is not
> possible

...?

> While testing the series, I also noticed that it is not possible to
> re-use the same compressed kernel for multiple domains as the module
> will be overwritten during the first decompression.
> 
> I am still a bit undecided how to fix it. We can either create a new
> module for the uncompressed kernel and link with the compressed kernel.
> Or we could decompress everytime.
> 
> One inconvenience to kernel to only decompress once is we have to keep
> it until all the domains have booted. This may means a lot of memory to be
> wasted just for keeping the uncompressed kernel (one my setup, it takes
> ~3 times more space).
> 
> Any opinions on how to approach it?

Well, it's not "until all the domains have booted", but until all the
domains have had their kernel image placed in the designated piece of
memory. So while for the time being multiple decompression may indeed
be a reasonable approach, longer term one could populate all the
domains' memory in two steps - first just the kernel space for all of
them, then load the kernel(s), then populate the rest of the memory.

Jan

Hi Jan,

On 06/04/2021 08:45, Jan Beulich wrote:
> On 02.04.2021 17:21, Julien Grall wrote:
>> From: Julien Grall <jgrall@amazon.com>
>>
>> Hi all,
>>
>> The main goal of this series is to address the bug report [1]. It is not
>> possible
> 
> ...?

Urgh, I forgot to add the rest of the sentence :/. I was meant to say 
that it is not possible to decompress multiple kernels (doesn't need to 
be the same) today.

> 
>> While testing the series, I also noticed that it is not possible to
>> re-use the same compressed kernel for multiple domains as the module
>> will be overwritten during the first decompression.
>>
>> I am still a bit undecided how to fix it. We can either create a new
>> module for the uncompressed kernel and link with the compressed kernel.
>> Or we could decompress everytime.
>>
>> One inconvenience to kernel to only decompress once is we have to keep
>> it until all the domains have booted. This may means a lot of memory to be
>> wasted just for keeping the uncompressed kernel (one my setup, it takes
>> ~3 times more space).
>>
>> Any opinions on how to approach it?
> 
> Well, it's not "until all the domains have booted", but until all the
> domains have had their kernel image placed in the designated piece of
> memory. So while for the time being multiple decompression may indeed
> be a reasonable approach, longer term one could populate all the
> domains' memory in two steps - first just the kernel space for all of
> them, then load the kernel(s), then populate the rest of the memory.

Right, I am not sure this brings us to a better position. We would want 
to use superpage mapping for the guest memory as much as possible for 
performance reason.

So we may end up to populate the full memory of each guests. Therefore, 
I am not sure the split is that worth it.

Cheers,

-- 
Julien Grall

Hi,

On 02/04/2021 16:21, Julien Grall wrote:
> From: Julien Grall <jgrall@amazon.com>
> 
> Hi all,
> 
> The main goal of this series is to address the bug report [1]. It is not
> possible
> 
> While testing the series, I also noticed that it is not possible to
> re-use the same compressed kernel for multiple domains as the module
> will be overwritten during the first decompression.
> 
> I am still a bit undecided how to fix it. We can either create a new
> module for the uncompressed kernel and link with the compressed kernel.
> Or we could decompress everytime.
> 
> One inconvenience to kernel to only decompress once is we have to keep
> it until all the domains have booted. This may means a lot of memory to be
> wasted just for keeping the uncompressed kernel (one my setup, it takes
> ~3 times more space).
> 
> Any opinions on how to approach it?
> 
> Cheers,
> 
> [1] https://lists.xenproject.org/archives/html/xen-users/2021-02/msg00027.html
> 
> Julien Grall (2):
>    xen/arm: kernel: Propagate the error if we fail to decompress the
>      kernel
>    xen/gunzip: Allow perform_gunzip() to be called multiple times

I have committed the second patch as it is independent. The first patch 
still need some reviews.

Cheers,

-- 
Julien Grall