Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753433AbcCGRSw (ORCPT ); Mon, 7 Mar 2016 12:18:52 -0500 Received: from mail-oi0-f45.google.com ([209.85.218.45]:34265 "EHLO mail-oi0-f45.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752822AbcCGRSo (ORCPT ); Mon, 7 Mar 2016 12:18:44 -0500 MIME-Version: 1.0 In-Reply-To: <1457373413.15454.334.camel@hpe.com> References: <20160303215304.1014.69931.stgit@dwillia2-desk3.amr.corp.intel.com> <20160303215315.1014.95661.stgit@dwillia2-desk3.amr.corp.intel.com> <1457146138.15454.277.camel@hpe.com> <1457373413.15454.334.camel@hpe.com> Date: Mon, 7 Mar 2016 09:18:42 -0800 Message-ID: Subject: Re: [PATCH v2 2/3] libnvdimm, pmem: adjust for section collisions with 'System RAM' From: Dan Williams To: Toshi Kani Cc: "linux-nvdimm@lists.01.org" , linux-mm , Linux Kernel Mailing List Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1280 Lines: 24 On Mon, Mar 7, 2016 at 9:56 AM, Toshi Kani wrote: > On Fri, 2016-03-04 at 18:23 -0800, Dan Williams wrote: >> On Fri, Mar 4, 2016 at 6:48 PM, Toshi Kani wrote: [..] >> As far as I can see >> all we do is ask firmware implementations to respect Linux section >> boundaries and otherwise not change alignments. > > In addition to the requirement that pmem range alignment may not change, > the code also requires a regular memory range does not change to intersect > with a pmem section later. This seems fragile to me since guest config may > vary / change as I mentioned above. > > So, shouldn't the driver fails to attach when the range is not aligned by > the section size? Since we need to place a requirement to firmware anyway, > we can simply state that it must be aligned by 128MiB (at least) on x86. > Then, memory and pmem physical layouts can be changed as long as this > requirement is met. We can state that it must be aligned, but without a hard specification I don't see how we can guarantee it. We will fail the driver load with a warning if our alignment fixups end up getting invalidated by a later configuration change, but in the meantime we cover the gap of a BIOS that has generated a problematic configuration.