From mboxrd@z Thu Jan  1 00:00:00 1970
Return-path: <ak@linux.intel.com>
Received: from mga01.intel.com ([192.55.52.88])
	by Galois.linutronix.de with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256)
	(Exim 4.80)
	(envelope-from <ak@linux.intel.com>)
	id 1fEbMz-00059w-D7
	for speck@linutronix.de; Fri, 04 May 2018 16:07:33 +0200
Date: Fri, 4 May 2018 07:07:30 -0700
From: Andi Kleen <ak@linux.intel.com>
Subject: [MODERATED] Re: [PATCH 1/8] L1TFv3 8
Message-ID: <20180504140730.GC75137@tassilo.jf.intel.com>
References: <cover.1525403858.git.ak@linux.intel.com>
 <0c2eb2235d5476b216693f1e9ec8394d58af20b3.1525403858.git.ak@linux.intel.com>
 <20180504134217.GS4535@dhcp22.suse.cz>
MIME-Version: 1.0
In-Reply-To: <20180504134217.GS4535@dhcp22.suse.cz>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
To: speck@linutronix.de
List-ID: <speck.linutronix.de>

On Fri, May 04, 2018 at 03:42:17PM +0200, speck for Michal Hocko wrote:
> On Thu 03-05-18 20:23:22, speck for Andi Kleen wrote:
> [...]
> >  #ifdef CONFIG_X86_PAE
> > -/* 44=32+12, the limit we can fit into an unsigned long pfn */
> > -#define __PHYSICAL_MASK_SHIFT	44
> > +/*
> > + * This is beyond the 44 bit limit imposed by the 32bit long pfns,
> > + * but we need the full mask to make sure inverted PROT_NONE
> > + * entries have all the host bits set in a guest.
> > + * The real limit is still 44 bits.
> 
> I cannot find where is that limit enforced.

I don't think there is an explicit check anywhere, but it would just silently
wrap everywhere PFNs are used.

But likely it would fail to allocate such a large mem_map in lowmem, so 
I doubt it could ever happen.

-Andi