Re: [PATCHv4 18/18] x86: Introduce CONFIG_X86_INTEL_MKTME

[Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>]

On Mon, Jul 09, 2018 at 11:59:33AM -0700, Dave Hansen wrote:
> On 07/09/2018 11:52 AM, Konrad Rzeszutek Wilk wrote:
> > On Mon, Jul 09, 2018 at 11:44:33AM -0700, Dave Hansen wrote:
> >> On 07/09/2018 11:36 AM, Konrad Rzeszutek Wilk wrote:
> >>> On Tue, Jun 26, 2018 at 05:22:45PM +0300, Kirill A. Shutemov wrote:
> >>> Rip out the X86?
> >>>> +	bool "Intel Multi-Key Total Memory Encryption"
> >>>> +	select DYNAMIC_PHYSICAL_MASK
> >>>> +	select PAGE_EXTENSION
> >>>
> >>> And maybe select 5-page?
> >>
> >> Why?  It's not a strict dependency.  You *can* build a 4-level kernel
> >> and run it on smaller systems.
> > 
> > Sure, but in one of his commits he mentions that we may run in overlapping
> > physical memory if we use 4-level paging. Hence why not just move to 5-level
> > paging and simplify this.
> 
> I'm not sure it _actually_ simplifies anything.  We still need code to
> handle the cases where we bump into the limits because even 5-level
> paging systems can hit the *architectural* limits.  We just don't think
> we'll bump into those limits any time soon in practice since they're
> 512x larger on 5-level systems.
> 
> But, a future system that needs physical address space or has a bunch
> more KeyID bits might bump into the limits.

Yikes. So when will we expand to 128-bit page fields?

> 
> It's also _possible_ that a processor could come out that supports MKTME
> but not 5-level paging, or a hypervisor would expose such a
> configuration to a guest.  We've asked our colleagues very nicely that
> Intel not make a processor that does this, but it's still possible one
> shows up.