On Thu, 20 Jul 2023 at 18:08, Dave Young <dyo...@redhat.com> wrote: > > On Thu, 20 Jul 2023 at 16:59, Pingfan Liu <pi...@redhat.com> wrote: > > > > On Thu, Jul 20, 2023 at 3:27 PM Dave Young <dyo...@redhat.com> wrote: > > > > > > Hi Pingfan, > > > > > > On Thu, 20 Jul 2023 at 10:05, Pingfan Liu <pi...@redhat.com> wrote: > > > > > > > > Hi Dave, > > > > > > > > Thanks for your insight. Please see the comments inline below. > > > > > > > > On Wed, Jul 19, 2023 at 11:00 AM Dave Young <dyo...@redhat.com> wrote: > > > > > > > > > > Hi Pingfan, Simon, > > > > > > > > > > On 07/17/23 at 09:07pm, Pingfan Liu wrote: > > > > > > As more complicated capsule kernel format occurs like zboot, where > > > > > > the > > > > > > compressed kernel is stored as a payload. The straight forward > > > > > > decompression can not meet the demand. > > > > > > > > > > > > As the first step, on aarch64, reading in the kernel file in a probe > > > > > > method and decide how to unfold the content by the method itself. > > > > > > > > > > > > This series introduce a new image probe interface probe2(), which > > > > > > returns three factors: kernel buffer, kernel size and kernel fd > > > > > > through > > > > > > a struct parsed_info. > > > > > > -1. the parsed kernel_buf should be returned so that it can be used > > > > > > by > > > > > > the image load method later. > > > > > > -2. the final fd passed to sys_kexec_file_load, since aarch64 > > > > > > kernel can > > > > > > only work with Image format, the outer payload should be stripped > > > > > > and a > > > > > > temporary file of Image should be created. > > > > > > > > > > I took a look at the Image.gz file load code, the current code can be > > > > > simplified with passing a fd directly instead of creating temp files > > > > > via > > > > > memfd_create with the already decompressed kernel_buf. > > > > > > > > > > The current file load is like below: > > > > > > > > > > do_kexec_file_load(): > > > > > 1.slurp_decompress_file > > > > > 2. probe > > > > > 3. load > > > > > 4. kexec_file_load > > > > > > > > > > In step 1, the Image.gz has been decompressed to kernel_buf, so just > > > > > create a virtual memfd copy to it, then save the virtual fd for step 4 > > > > > use. > > > > > > > > > > Otherwise in step 2 it is some sanity checking, step 3 is setting > > > > > something else eg. initrd_fd, cmdline. With the changes below Image > > > > > and > > > > > Image.gz will share same code. I think you can add the zboot > > > > > detection/checking code in the Image probe, load functions, with a new > > > > > info->kernel_fd, you can decompress the zboot kernel_buf and save to > > > > > another virtual memfd, and set to the info->kernel_fd. Then in step 4 > > > > > the kexec_file_load can just use it. > > > > > > > > > > > > > This only results in a minor change in the interface, not like mine. I > > > > prefer this method. > > > > > > > > > The kernel_buf itself is only used for sanity checking of the formats, > > > > > kernel only needs a file fd, so I think it should be fine and easier > > > > > than the original ways. > > > > > > > > > > > > > Overall, this new method minimally affects the function interface, in > > > > addition to the code simplification. > > > > I will try to take it in the next version. > > > > > > > Ok, great. Btw, it would be ideal if some of the pez_prepare work can > > > be done early before the slurp_decompress_file in > > > do_kexec_file_load(), then it could be just arch independent :) > > > > > > > I assume that you suggest the following big picture: > > if trying slurp_decompress_file() > > else trying pez_prepare() > > for (i = 0; i < file_types; i++) { > > if (file_type[i].probe(kernel_buf, kernel_size) >= 0) > > } > > > > But there is some check before pez_prepare() in pez_arm64_probe(), I > > am not sure whether they can be skipped or not. > > Ok, got it, if the zimage header of arm64 is arch specific , it should
s/zimage/zboot > still go to the arch part. > > Thanks > Dave _______________________________________________ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec