[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20211213140348.GA26562@MiWiFi-R3L-srv>
Date: Mon, 13 Dec 2021 22:03:48 +0800
From: Baoquan He <bhe@...hat.com>
To: Borislav Petkov <bp@...en8.de>
Cc: linux-kernel@...r.kernel.org, tglx@...utronix.de, mingo@...hat.com,
dave.hansen@...ux.intel.com, luto@...nel.org, peterz@...radead.org,
linux-mm@...ck.org, akpm@...ux-foundation.org, hch@....de,
robin.murphy@....com, cl@...ux.com, penberg@...nel.org,
rientjes@...gle.com, iamjoonsoo.kim@....com, vbabka@...e.cz,
m.szyprowski@...sung.com, John.p.donnelly@...cle.com,
kexec@...ts.infradead.org, rppt@...ux.ibm.com
Subject: Re: [PATCH RESEND v2 0/5] Avoid requesting page from DMA zone when
no managed pages
On 12/13/21 at 02:25pm, Borislav Petkov wrote:
> On Tue, Dec 07, 2021 at 11:16:31AM +0800, Baoquan He wrote:
> > > This low 1M lock down is needed because AMD SME encrypts memory making
> > > the old backup region mechanims impossible when switching into kdump
> > > kernel. And Intel engineer mentioned their TDX (Trusted domain extensions)
> > > which is under development in kernel also needs lock down the low 1M.
> > > So we can't simply revert above commits to fix the page allocation
> > > failure from DMA zone as someone suggested.
>
> Did you read
>
> f1d4d47c5851 ("x86/setup: Always reserve the first 1M of RAM")
>
> carefully for a more generically important reason as to why the first 1M
> should not be used?
Apparently I didn't. I slacked off and just grabbed things stored in my
brain. This is the right justification and missed. Thanks for pointing
it out.
Powered by blists - more mailing lists