[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20210420095115.GE5029@zn.tnic>
Date: Tue, 20 Apr 2021 11:51:15 +0200
From: Borislav Petkov <bp@...en8.de>
To: Dave Hansen <dave.hansen@...el.com>
Cc: Andy Lutomirski <luto@...capital.net>,
Brijesh Singh <brijesh.singh@....com>,
linux-kernel@...r.kernel.org, x86@...nel.org, kvm@...r.kernel.org,
linux-crypto@...r.kernel.org, ak@...ux.intel.com,
herbert@...dor.apana.org.au, Thomas Gleixner <tglx@...utronix.de>,
Ingo Molnar <mingo@...hat.com>, Joerg Roedel <jroedel@...e.de>,
"H. Peter Anvin" <hpa@...or.com>, Tony Luck <tony.luck@...el.com>,
"Peter Zijlstra (Intel)" <peterz@...radead.org>,
Paolo Bonzini <pbonzini@...hat.com>,
Tom Lendacky <thomas.lendacky@....com>,
David Rientjes <rientjes@...gle.com>,
Sean Christopherson <seanjc@...gle.com>,
Vlastimil Babka <vbabka@...e.cz>
Subject: Re: [RFC Part2 PATCH 04/30] x86/mm: split the physmap when adding
the page in RMP table
On Mon, Apr 19, 2021 at 11:33:08AM -0700, Dave Hansen wrote:
> My point was just that you can't _easily_ do the 2M->4k kernel mapping
> demotion in a page fault handler, like I think Borislav was suggesting.
Yeah, see my reply to Brijesh. Not in the #PF handler but when the guest
does update the RMP table on page allocation, we should split the kernel
mapping too, so that it corresponds to what's being changed in the RMP
table.
Dunno how useful it would be if we also do coalescing of 4K pages into
their corresponding 2M pages... I haven't looked at set_memory.c for a
long time and have forgotten about all details...
In any case, my main goal here is to keep the tables in sync so that we
don't have to do crazy splitting in unsafe contexts like #PF. I hope I'm
making sense...
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
Powered by blists - more mailing lists