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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <BL1PR21MB3113B31101E8E3E4BA08D9ACA0C1A@BL1PR21MB3113.namprd21.prod.outlook.com>
Date:   Thu, 28 Sep 2023 18:12:44 +0000
From:   KY Srinivasan <kys@...rosoft.com>
To:     Dave Hansen <dave.hansen@...el.com>,
        David Hildenbrand <david@...hat.com>,
        Stanislav Kinsburskii <skinsburskii@...ux.microsoft.com>,
        Baoquan He <bhe@...hat.com>
CC:     "tglx@...utronix.de" <tglx@...utronix.de>,
        "mingo@...hat.com" <mingo@...hat.com>,
        "bp@...en8.de" <bp@...en8.de>,
        "dave.hansen@...ux.intel.com" <dave.hansen@...ux.intel.com>,
        "x86@...nel.org" <x86@...nel.org>, "hpa@...or.com" <hpa@...or.com>,
        "ebiederm@...ssion.com" <ebiederm@...ssion.com>,
        "akpm@...ux-foundation.org" <akpm@...ux-foundation.org>,
        "stanislav.kinsburskii@...il.com" <stanislav.kinsburskii@...il.com>,
        "corbet@....net" <corbet@....net>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "kexec@...ts.infradead.org" <kexec@...ts.infradead.org>,
        "linux-mm@...ck.org" <linux-mm@...ck.org>,
        "jgowans@...zon.com" <jgowans@...zon.com>,
        "wei.liu@...nel.org" <wei.liu@...nel.org>,
        "arnd@...db.de" <arnd@...db.de>,
        "gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>,
        "graf@...zon.de" <graf@...zon.de>,
        "pbonzini@...hat.com" <pbonzini@...hat.com>
Subject: RE: [EXTERNAL] Re: [RFC PATCH v2 0/7] Introduce persistent memory
 pool




> -----Original Message-----
> From: Dave Hansen <dave.hansen@...el.com>
> Sent: Thursday, September 28, 2023 10:38 AM
> To: David Hildenbrand <david@...hat.com>; Stanislav Kinsburskii
> <skinsburskii@...ux.microsoft.com>; Baoquan He <bhe@...hat.com>
> Cc: tglx@...utronix.de; mingo@...hat.com; bp@...en8.de;
> dave.hansen@...ux.intel.com; x86@...nel.org; hpa@...or.com;
> ebiederm@...ssion.com; akpm@...ux-foundation.org;
> stanislav.kinsburskii@...il.com; corbet@....net; linux-
> kernel@...r.kernel.org; kexec@...ts.infradead.org; linux-mm@...ck.org; KY
> Srinivasan <kys@...rosoft.com>; jgowans@...zon.com; wei.liu@...nel.org;
> arnd@...db.de; gregkh@...uxfoundation.org; graf@...zon.de;
> pbonzini@...hat.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