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

[KY Srinivasan]

> -----Original Message-----
> From: Dave Hansen <dave.hansen@xxxxxxxxx>
> Sent: Thursday, September 28, 2023 10:38 AM
> To: David Hildenbrand <david@xxxxxxxxxx>; Stanislav Kinsburskii
> <skinsburskii@xxxxxxxxxxxxxxxxxxx>; Baoquan He <bhe@xxxxxxxxxx>
> Cc: tglx@xxxxxxxxxxxxx; mingo@xxxxxxxxxx; bp@xxxxxxxxx;
> dave.hansen@xxxxxxxxxxxxxxx; x86@xxxxxxxxxx; hpa@xxxxxxxxx;
> ebiederm@xxxxxxxxxxxx; akpm@xxxxxxxxxxxxxxxxxxxx;
> stanislav.kinsburskii@xxxxxxxxx; corbet@xxxxxxx; linux-
> kernel@xxxxxxxxxxxxxxx; kexec@xxxxxxxxxxxxxxxxxxx; linux-mm@xxxxxxxxx; KY
> Srinivasan <kys@xxxxxxxxxxxxx>; jgowans@xxxxxxxxxx; wei.liu@xxxxxxxxxx;
> arnd@xxxxxxxx; gregkh@xxxxxxxxxxxxxxxxxxx; graf@xxxxxxxxx;
> pbonzini@xxxxxxxxxx
> 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