[EXTERNAL] Re: [RFC PATCH v2 0/7] Introduce persistent memory pool

[KY Srinivasan]

> -----Original Message-----
> From: Dave Hansen <dave.hansen at intel.com>
> Sent: Thursday, September 28, 2023 10:38 AM
> To: David Hildenbrand <david at redhat.com>; Stanislav Kinsburskii
> <skinsburskii at linux.microsoft.com>; Baoquan He <bhe at redhat.com>
> Cc: tglx at linutronix.de; mingo at redhat.com; bp at alien8.de;
> dave.hansen at linux.intel.com; x86 at kernel.org; hpa at zytor.com;
> ebiederm at xmission.com; akpm at linux-foundation.org;
> stanislav.kinsburskii at gmail.com; corbet at lwn.net; linux-
> kernel at vger.kernel.org; kexec at lists.infradead.org; linux-mm at kvack.org; KY
> Srinivasan <kys at microsoft.com>; jgowans at amazon.com; wei.liu at kernel.org;
> arnd at arndb.de; gregkh at linuxfoundation.org; graf at amazon.de;
> pbonzini at redhat.com
> Subject: [EXTERNAL] Re: [RFC PATCH v2 0/7] Introduce persistent memory pool
> 
> On 9/28/23 10:35, David Hildenbrand wrote:
> > On 28.09.23 15:22, Dave Hansen wrote:
> >> On 9/27/23 09:13, Stanislav Kinsburskii wrote:
> >>> Once deposited, these pages can't be accessed by Linux anymore and
> >>> thus must be preserved in "used" state across kexec, as hypervisor
> >>> state is unware of kexec.
> >>
> >> If Linux can't access them, they're not RAM any more.  I'd much
> >> rather remove them from the memory map and move on with life rather
> >> than implement a bunch of new ABI that's got to be handed across kernels.
> >
> > The motivation of handling kexec (faster?) in a hyper-v domain doesn't
> > sound particularly compelling got me for such features. If you
> > inflated memory, just don't allow to kexec. It's been broken for years IIUC.
> 
> That's a good point.  What prevents deflating before kexec?


The guest has returned the memory to the host as part of inflating the balloon and so,
this memory has to be returned by the host before you can deflate. The best option
is to not kexec when the memory has been returned to the host.

Regards,

K. Y