linux-kernel - Re: [RFC Part2 PATCH 04/30] x86/mm: split the physmap when adding the page in RMP table

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] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 25 Mar 2021 08:17:36 -0700
From:   Dave Hansen <dave.hansen@...el.com>
To:     Brijesh Singh <brijesh.singh@....com>,
        linux-kernel@...r.kernel.org, x86@...nel.org, kvm@...r.kernel.org,
        linux-crypto@...r.kernel.org
Cc:     ak@...ux.intel.com, herbert@...dor.apana.org.au,
        Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
        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>
Subject: Re: [RFC Part2 PATCH 04/30] x86/mm: split the physmap when adding the
 page in RMP table

On 3/24/21 10:04 AM, Brijesh Singh wrote:
> The spliting of the physmap is a temporary solution until we work to
> improve the kernel page fault handler to split the pages on demand.
> One of the disadvtange of splitting is that eventually, we will end up
> breaking down the entire physmap unless we combine the split pages back to
> a large page. I am open to the suggestation on various approaches we could
> take to address this problem.

Other than suggesting that the hardware be fixed to do the fracturing
itself?  :)

I suspect that this code is trying to be *too* generic.  I would expect
that very little of guest memory is actually shared with the host.  It's
also not going to be random guest pages.  The guest and the host have to
agree on these things, and I *think* the host is free to move the
physical backing around once it's shared.

So, let's say that there a guest->host paravirt interface where the
guest says in advance, "I want to share this page."  The host can split
at *that* point and *only* split that one page's mapping.  Any page
faults would occur only if the host screws up, and would result in an oops.

That also gives a point where the host can say, "nope, that hugetlbfs, I
can't split it".