Message-ID: <c0f89d9d-98c3-4b04-9077-d92a863db088@amazon.com>
Date:   Thu, 14 Dec 2023 17:02:40 +0100
From:   Alexander Graf <graf@...zon.com>
To:     "Eric W. Biederman" <ebiederm@...ssion.com>
CC:     <linux-kernel@...r.kernel.org>,
        <linux-trace-kernel@...r.kernel.org>, <linux-mm@...ck.org>,
        <devicetree@...r.kernel.org>,
        <linux-arm-kernel@...ts.infradead.org>,
        <kexec@...ts.infradead.org>, <linux-doc@...r.kernel.org>,
        <x86@...nel.org>, "H. Peter Anvin" <hpa@...or.com>,
        Andy Lutomirski <luto@...nel.org>,
        Peter Zijlstra <peterz@...radead.org>,
        Rob Herring <robh+dt@...nel.org>,
        Steven Rostedt <rostedt@...dmis.org>,
        Andrew Morton <akpm@...ux-foundation.org>,
        "Mark Rutland" <mark.rutland@....com>,
        Tom Lendacky <thomas.lendacky@....com>,
        Ashish Kalra <ashish.kalra@....com>,
        James Gowans <jgowans@...zon.com>,
        Stanislav Kinsburskii <skinsburskii@...ux.microsoft.com>,
        <arnd@...db.de>, <pbonzini@...hat.com>,
        <madvenka@...ux.microsoft.com>,
        Anthony Yznaga <anthony.yznaga@...cle.com>,
        Usama Arif <usama.arif@...edance.com>,
        "David Woodhouse" <dwmw@...zon.co.uk>,
        Benjamin Herrenschmidt <benh@...nel.crashing.org>
Subject: Re: [PATCH 00/15] kexec: Allow preservation of ftrace buffers

Hey Eric,

On 14.12.23 15:58, Eric W. Biederman wrote:
> Alexander Graf <graf@...zon.com> writes:
>
>> Kexec today considers itself purely a boot loader: When we enter the new
>> kernel, any state the previous kernel left behind is irrelevant and the
>> new kernel reinitializes the system.
>>
>> However, there are use cases where this mode of operation is not what we
>> actually want. In virtualization hosts for example, we want to use kexec
>> to update the host kernel while virtual machine memory stays untouched.
>> When we add device assignment to the mix, we also need to ensure that
>> IOMMU and VFIO states are untouched. If we add PCIe peer to peer DMA, we
>> need to do the same for the PCI subsystem. If we want to kexec while an
>> SEV-SNP enabled virtual machine is running, we need to preserve the VM
>> context pages and physical memory. See James' and my Linux Plumbers
>> Conference 2023 presentation for details:
>>
>>    https://lpc.events/event/17/contributions/1485/
>>
>> To start us on the journey to support all the use cases above, this
>> patch implements basic infrastructure to allow hand over of kernel state
>> across kexec (Kexec HandOver, aka KHO). As example target, we use ftrace:
>> With this patch set applied, you can read ftrace records from the
>> pre-kexec environment in your post-kexec one. This creates a very powerful
>> debugging and performance analysis tool for kexec. It's also slightly
>> easier to reason about than full blown VFIO state preservation.
>>
>> == Alternatives ==
>>
>> There are alternative approaches to (parts of) the problems above:
>>
>>    * Memory Pools [1] - preallocated persistent memory region + allocator
>>    * PRMEM [2] - resizable persistent memory regions with fixed metadata
>>                  pointer on the kernel command line + allocator
>>    * Pkernfs [3] - preallocated file system for in-kernel data with fixed
>>                    address location on the kernel command line
>>    * PKRAM [4] - handover of user space pages using a fixed metadata page
>>                  specified via command line
>>
>> All of the approaches above fundamentally have the same problem: They
>> require the administrator to explicitly carve out a physical memory
>> location because they have no mechanism outside of the kernel command
>> line to pass data (including memory reservations) between kexec'ing
>> kernels.
>>
>> KHO provides that base foundation. We will determine later whether we
>> still need any of the approaches above for fast bulk memory handover of for
>> example IOMMU page tables. But IMHO they would all be users of KHO, with
>> KHO providing the foundational primitive to pass metadata and bulk memory
>> reservations as well as provide easy versioning for data.
> What you are describe in many ways is the same problem as
> kexec-on-panic.  The goal of leaving devices running absolutely requires
> carving out memory for the new kernel to live in while it is coming up
> so that DMA from a device that was not shutdown down does not stomp the
> kernel coming up.


Yes, part of the problem is similar: We need a safe space to boot from 
that doesn't overwrite existing data. What happens after is different: 
With panics, you're trying to rescue previous state for post-mortem 
analysis. You may even have intrinsic knowledge of the environment you 
came from, so you can optimize that rescuing. Nobody wants to continue 
running the system as if nothing happened after a panic.

With KHO, the kernels establish an ABI between each other to communicate 
any state that needs to get preserved and the rest gets reinitialized. 
After KHO, the new kernel continues executing workloads that were 
running before.

The ABI is important because the next environment may not have a chance 
to know about the previous environment's setup. Think for example of 
roll-out and roll-back scenarios: If I roll back into my previous 
environment because I determined something didn't work as expected after 
update, I'm moving the system into an environment that was built when 
the kexec source environment didn't even exist yet.


> If I understand the virtualization case some of those virtual machines
> are going to have virtual NICs that are going to want to DMA memory to
> the host system.  Which if I understand things correctly means that


No, to the *guest* system. This is about device assignment: The guest is 
in full control of the NICs that do DMA, so we have no chance to quiesce 
them.


> among the devices you explicitly want to keep running there is a not
> a way to avoid the chance of DMA coming in while the kernel is being
> changed.


Correct, because the host doesn't own the driver :).


> There is also a huge maintenance challenge associated with all of this.
>
> If you go with something that is essentially kexec-on-panic and then
> add a little bit to help find things in the memory of the previous
> kernel while the new kernel is coming up I can see it as a possibility.


That's roughly what the patch set is doing, yes. It avoids a static 
allocation ahead of time for next-kernel memory, because I only know the 
size of all components when we're actually doing the kexec. But the 
principle is similar.

The bit where the new kernel finds bits in the old memory is the KHO DT: 
A flattened device tree structure the old kernel passes to the new 
kernel. That contains all memory locations as well as additional 
metadata to "help find things" in a way that doesn't immediately break 
on every kernel change.


> As an example I think preserving ftrace data of kexec seems bizarre.
> I don't see how that is an interesting use case at all.  Not in
> the situation of preserving virtual machines, and not in the situation
> of kexec on panic.


It's super useful as self debugging aid: I already used it to profile 
the kexec path to find a few performance issues :). It's also really 
helpful - even without device assignment support yet - when you use it 
in combination with KVM trace points: You have a VM running backed by a 
DAX pmem device, then serialize its virtual device state, kexec, restore 
from the virtual device state, then the VM misbehaves.

With ftrace handover in place, you get a full trace of the flow which 
simplifies debugging of issues that happen during/because of the 
serialization/deserialization flow of KVM state.

But the main reason I chose ftrace to start with is that all other use 
cases require another concept: fd preservation. All the typical 
"objects" you want to preserve across kexec are anonymous file 
descriptors. So we need to also build a way in Linux that allows user 
space to request the kernel to preserve an fd using the kexec handover 
framework in this patch set. But that is another big discussion I wanted 
to keep separate: Ftrace is from kernel, to kernel and hence "easy".


> If you are doing an orderly shutdown and kernel switch you should be
> able to manually change the memory.  If you are not doing an orderly
> shutdown then I really don't get it.


I don't follow the paragraph above?


> I don't hate the capability you are trying to build.
>
> I have not read or looked at most of this so I am probably
> missing subtle details.
>
> As you are currently describing things I have the sense you have
> completely misframed the problem and are trying to solve the wrong parts
> of the problem.


Very well possible :). I hope the above clarifies it a bit. If not, 
please let me know where exactly it's unclear so I can elaborate.

If you have a few minutes, it would also be great if you could have a 
look at our slides [1] or even video [2] from LPC 2023 which go into 
detail of the end problem. Beware that I'm consciously *not* trying to 
solve the end problem yet: I want to take baby steps towards it. Nobody 
wants to review an 80 patches patch set where everything depends on 
everything else.


Alex


[1] 
https://lpc.events/event/17/contributions/1485/attachments/1296/2650/jgowans-preserving-across-kexec.pdf
[2] https://www.youtube.com/watch?v=cYrlV4bK1Y4




Amazon Development Center Germany GmbH
Krausenstr. 38
10117 Berlin
Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss
Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B
Sitz: Berlin
Ust-ID: DE 289 237 879

Powered by blists - more mailing lists