Can't use kexec-tools for preserve-context kexec 'call'?

[David Woodhouse]

On Thu, 2024-12-12 at 11:02 +0800, Baoquan He wrote:
> Hi David,
> 
> On 12/09/24 at 02:07pm, David Woodhouse wrote:
> > In https://git.kernel.org/torvalds/c/07fa619f2a40c there is a test
> > program which uses kexec to invoke a 4-instruction 'executable' which
> > merely writes a byte to a serial port and returns.
> > 
> > It just loads a single kexec segment containing those four
> > instructions.
> > 
> > Should I have been able to do that using kexec-tools? I couldn't work
> > out how.
> > 
> > And even once it's loaded, 'kexec -f -e' does manage to invoke it, but
> > then reports 'No such file or directory' after the reboot() system call
> > returns success. Strace shows:
> 
> May I know why you are testing preserve-context feature recently? I
> noticed you have raised an issue inside kernel and worked out a draft
> patch, while you did't tell what use case or scenario preserve-context
> is used in. Asking this because you could be the 1st one to test it and
> report issues on preserve-context as far as I know these years.

Right now, I'm testing it because I touched that code path in
relocate_kernel_64.S and thus of *course* I have to test it. How could
anyone touch this code and *not* test for regressions?

> If there's newly found scenario preserve-context is needed, that's a
> good thing. Otherwise we may consider to put it in DEPRECATED list in
> kernel config so that we can finally take it off from kernel in several
> years, like this people won't meet it and need take time to study what
> it is and why it doesn't work as it was declared. What do you think?

By coincidence, however, I do happen to know of a production scenario
in which preserve-context kexec is used a few million times a week.
(Which is lucky, because I was able to crib some of my test case from
that code base.)

The reload-GDT fix is also already in that code base, FWIW, and I have
already frowned at them for not upstreaming it immediately, which was a
violation of our development policy.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5965 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/kexec/attachments/20241212/e48b9a0b/attachment.p7s>