Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Date:   Thu, 14 May 2020 12:29:53 +0300
From:   Mike Rapoport <rppt@linux.ibm.com>
To:     Alexandre Chartre <alexandre.chartre@oracle.com>
Cc:     tglx@linutronix.de, mingo@redhat.com, bp@alien8.de, hpa@zytor.com,
        dave.hansen@linux.intel.com, luto@kernel.org, peterz@infradead.org,
        x86@kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org,
        pbonzini@redhat.com, konrad.wilk@oracle.com,
        jan.setjeeilers@oracle.com, liran.alon@oracle.com,
        junaids@google.com, graf@amazon.de, rppt@linux.vnet.ibm.com,
        kuzuno@gmail.com, mgross@linux.intel.com
Subject: Re: [RFC v4][PATCH part-2 00/13] ASI - Part II (Decorated Page-Table)
Message-ID: <20200514092953.GA1059226@linux.ibm.com>
References: <20200504145810.11882-1-alexandre.chartre@oracle.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20200504145810.11882-1-alexandre.chartre@oracle.com>
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

Hello Alexandre,

On Mon, May 04, 2020 at 04:57:57PM +0200, Alexandre Chartre wrote:
> This is part II of ASI RFC v4. Please refer to the cover letter of
> part I for an overview the ASI RFC.
> 
>   https://lore.kernel.org/lkml/20200504144939.11318-1-alexandre.chartre@oracle.com/
> 
> This part introduces decorated page-table which encapsulate native page
> table (e.g. a PGD) in order to provide convenient page-table management
> functions, such as tracking address range mapped in a page-table or
> safely handling references to another page-table.
> 
> Decorated page-table can then be used to easily create and manage page
> tables to be used with ASI. It will be used by the ASI test driver (see
> part III) and later by KVM ASI.
> 
> Decorated page-table is independent of ASI, and can potentially be used
> anywhere a page-table is needed.
 
This is very impressive work!

I wonder why did you decide to make dpt x86-specific? Unless I've missed
simething, the dpt implementation does not rely on anything architecture
specific and can go straight to linux/mm.

Another thing that comes to mind is that we already have a very
decorated page table, which is mm_struct. I admit that my attempt to
split out the core page table bits from the mm_struct [1] didn't  went
far, but I still think we need a first class abstraction for the page
table that will be used by both user memory management and the
management of the reduced kernel address spaces.


[1] https://git.kernel.org/pub/scm/linux/kernel/git/rppt/linux.git/log/?h=pg_table/v0.0

> Thanks,
> 
> alex.
> 
> -----
> 
> Alexandre Chartre (13):
>   mm/x86: Introduce decorated page-table (dpt)
>   mm/dpt: Track buffers allocated for a decorated page-table
>   mm/dpt: Add decorated page-table entry offset functions
>   mm/dpt: Add decorated page-table entry allocation functions
>   mm/dpt: Add decorated page-table entry set functions
>   mm/dpt: Functions to populate a decorated page-table from a VA range
>   mm/dpt: Helper functions to map module into a decorated page-table
>   mm/dpt: Keep track of VA ranges mapped in a decorated page-table
>   mm/dpt: Functions to clear decorated page-table entries for a VA range
>   mm/dpt: Function to copy page-table entries for percpu buffer
>   mm/dpt: Add decorated page-table remap function
>   mm/dpt: Handle decorated page-table mapped range leaks and overlaps
>   mm/asi: Function to init decorated page-table with ASI core mappings
> 
>  arch/x86/include/asm/asi.h |    2 +
>  arch/x86/include/asm/dpt.h |   89 +++
>  arch/x86/mm/Makefile       |    2 +-
>  arch/x86/mm/asi.c          |   57 ++
>  arch/x86/mm/dpt.c          | 1051 ++++++++++++++++++++++++++++++++++++
>  5 files changed, 1200 insertions(+), 1 deletion(-)
>  create mode 100644 arch/x86/include/asm/dpt.h
>  create mode 100644 arch/x86/mm/dpt.c
> 
> -- 
> 2.18.2
> 

-- 
Sincerely yours,
Mike.