From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Received: from mga12.intel.com ([192.55.52.136]) by Galois.linutronix.de with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1fEd1x-000700-Ll for speck@linutronix.de; Fri, 04 May 2018 17:53:58 +0200 Date: Fri, 4 May 2018 08:53:54 -0700 From: Andi Kleen Subject: [MODERATED] Re: [PATCH 8/8] L1TFv3 3 Message-ID: <20180504155354.GF75137@tassilo.jf.intel.com> References: <62b4a73ea2fd6453e0aa3d7493ce8a46b5bb13ca.1525403858.git.ak@linux.intel.com> <20180504141951.GE75137@tassilo.jf.intel.com> <20180504143424.GX4535@dhcp22.suse.cz> MIME-Version: 1.0 In-Reply-To: <20180504143424.GX4535@dhcp22.suse.cz> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: speck@linutronix.de List-ID: On Fri, May 04, 2018 at 04:34:24PM +0200, speck for Michal Hocko wrote: > On Fri 04-05-18 07:19:51, speck for Andi Kleen wrote: > > > > BTW this one is a somewhat tricky and new patch. Would be good if VM people > > could take a good look at the assumptions and the logic. Thanks. > > I have to confess that it is not entirely clear to me how any bios can > put MMIO that high and things still keep working but in principle, the How? It can of course put any mapping there that doesn't have another address restriction. Devices with large mappings usually don't have restrictions smaller than the MAX_PA size of the CPU (46 bits), so it's an arbitrary choice. Mappings with restrictions will of course be in the 4GB hole. -Andi