Received: by 2002:a25:c205:0:0:0:0:0 with SMTP id s5csp4824578ybf; Wed, 4 Mar 2020 11:24:22 -0800 (PST) X-Google-Smtp-Source: ADFU+vvlJ00M9/H7DdPPQQfSYxDtAAApAp4EOsJM6a35BTkl3g96hmZXHdaQVTv/Eab0PDesYd/o X-Received: by 2002:a9d:3de4:: with SMTP id l91mr3696975otc.35.1583349862301; Wed, 04 Mar 2020 11:24:22 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1583349862; cv=none; d=google.com; s=arc-20160816; b=JHBtWVLdFmyyPXXYHQaOneGYMBipNQhQOnQxI9KPbcNJ3zK8jWh7fSgp5pFpOA6MuO tkE2VcVI+yrVjcGSwr8UGuMjP0Cl7gV0CKtaeyYB+4wzEuD4NvFPNTtSPBgYg165qKl+ 2/zxQN3bGC4RLKb44i9hWS+WdSFb+07OToWqycap6rnKYpEC9ydgj730Cu5FwTXOyQt3 Wvj3/S/kNJvydNzcgPLLcNi1EW9RpmzH2V7SJjut4VGbKPNWTtj0RXUkU4hXtzGe/TBq hP0nUq8Er7Dw0ElStW2Xgu9XuhKmnlpSOuaac8v+B3BBstC9/aY6grG9L6+yC3CGrjmS N7hg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=UwBJZH0XfzAQA9+xPW8JW1MjoVQK6kSu7HJWc7TL5ck=; b=ii46iZOFaE/xfHCe2la5rX6RZ0Dy0HzJ56imayOuo1fGLbrb4IRtBB60LkfH51RLhq bD5HslnpMmwfwWdD2ujvX1bl51Zxix+vSkDcpfKZhJ0lgsAoLaJvKY/Gb1oJoFoLHHRy 3qKRsDvsVFRrpMQ0kJm57fNHPxWQz2125SyG12lcaTNXZ7e6r6CuRBFeh+2XxEXpwkAb Yj0IBYkdcaVkM81xS9m+DAbx/JZDFYHKIiNp+N6Z9noUbpuIVauPJv/rMiuRCyATnz3p x/4EhA1oHZiQauzHkXfcUXSiQfweWY60XcuR+T06MJJl1jZUzazV2PhAvBXJqbYuzJs9 fvbQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=i4w9yaJN; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id o20si1666448otl.60.2020.03.04.11.24.02; Wed, 04 Mar 2020 11:24:22 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=i4w9yaJN; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2387398AbgCDTWu (ORCPT + 99 others); Wed, 4 Mar 2020 14:22:50 -0500 Received: from mail.kernel.org ([198.145.29.99]:45598 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726440AbgCDTWt (ORCPT ); Wed, 4 Mar 2020 14:22:49 -0500 Received: from mail-wr1-f46.google.com (mail-wr1-f46.google.com [209.85.221.46]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 5047024654 for ; Wed, 4 Mar 2020 19:22:48 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1583349768; bh=K6IbC9m66srtNpCpNfvPpNHw795EKm+SM6PSXFNj8WI=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=i4w9yaJNTvVe7/vVFfRjvAicNR9coBRGeOvnAA2okMleX1mkcWOYCx5dq88RP72/P ME68tu5GBXvGjy4YgjPssHTeAc0oXeGQ8IFV/X6ur4U/KHXo+saZp4wsChOZAjZFxU Ra2qSRbYSqsGc4qw4zJiS/c93Fl1Oycnouektkkk= Received: by mail-wr1-f46.google.com with SMTP id v2so3864893wrp.12 for ; Wed, 04 Mar 2020 11:22:48 -0800 (PST) X-Gm-Message-State: ANhLgQ3O4pJQgkSG9k6hLkdyKlU6Z7wMYpbHVjXVf1/L655YnH2CeqFi FpAv23YKk7l7zcqeiWdUEpHHa3mSXyi1YHJGs6Lx4Q== X-Received: by 2002:adf:f84a:: with SMTP id d10mr5648007wrq.208.1583349766740; Wed, 04 Mar 2020 11:22:46 -0800 (PST) MIME-Version: 1.0 References: <20200303205445.3965393-1-nivedita@alum.mit.edu> <20200303205445.3965393-2-nivedita@alum.mit.edu> <20200304154908.GB998825@rani.riverdale.lan> <20200304185042.GA281042@rani.riverdale.lan> <20200304191053.GA291311@rani.riverdale.lan> In-Reply-To: <20200304191053.GA291311@rani.riverdale.lan> From: Ard Biesheuvel Date: Wed, 4 Mar 2020 20:22:36 +0100 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH 1/4] x86/mm/pat: Handle no-GBPAGES case correctly in populate_pud To: Arvind Sankar Cc: Dave Hansen , Andy Lutomirski , Peter Zijlstra , Thomas Gleixner , Ingo Molnar , Borislav Petkov , "H. Peter Anvin" , "the arch/x86 maintainers" , linux-efi , Linux Kernel Mailing List Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 4 Mar 2020 at 20:10, Arvind Sankar wrote: > > On Wed, Mar 04, 2020 at 08:04:04PM +0100, Ard Biesheuvel wrote: > > On Wed, 4 Mar 2020 at 19:50, Arvind Sankar wrote: > > > > > > On Wed, Mar 04, 2020 at 07:44:50PM +0100, Ard Biesheuvel wrote: > > > > > > > > I've tried a couple of different ways, but I can't seem to get my > > > > memory map organized in the way that will trigger the error. > > > > > > What does yours look like? efi_merge_regions doesn't merge everything > > > that will eventually be mapped the same way, so if there are some > > > non-conventional memory regions scattered over the address space, it > > > might be breaking up the mappings to the point where this doesn't > > > trigger. > > > > I have a region > > > > [ 0.000000] efi: mem07: [Conventional Memory| | | | | | | | > > | |WB|WT|WC|UC] range=[0x0000000001400000-0x00000000b9855fff] > > (2948MB) > > > > which gets covered correctly > > > > [ 0.401766] 0x0000000000a00000-0x0000000040000000 1014M > > RW PSE NX pmd > > [ 0.403436] 0x0000000040000000-0x0000000080000000 1G > > RW PSE NX pud > > [ 0.404645] 0x0000000080000000-0x00000000b9800000 920M > > RW PSE NX pmd > > [ 0.405844] 0x00000000b9800000-0x00000000b9a00000 2M > > RW NX pte > > [ 0.407436] 0x00000000b9a00000-0x00000000baa00000 16M > > ro PSE x pmd > > [ 0.408591] 0x00000000baa00000-0x00000000bbe00000 20M > > RW PSE NX pmd > > [ 0.409751] 0x00000000bbe00000-0x00000000bc000000 2M > > RW NX pte > > [ 0.410821] 0x00000000bc000000-0x00000000be600000 38M > > RW PSE NX pmd > > > > However, the fact that you can provide a case where it does fail > > should be sufficient justification for taking this patch. I was just > > trying to give more than a regression-tested-by > > No, this case is exactly one that should break. But I think you're > running on a processor model that _does_ support GB pages, as shown by > the "pud" mapping there for the 1G-2G range. > > At least for my version of qemu, -cpu Haswell does not enable the > pdpe1gb feature. Which cpu did you specify? > The wrong one, obviously :-) With Haswell, I get [before] [ 0.368541] 0x0000000000900000-0x0000000000a00000 1M RW NX pte [ 0.369118] 0x0000000000a00000-0x0000000080000000 2038M RW PSE NX pmd [ 0.369592] 0x0000000080000000-0x00000000b9800000 920M pmd [ 0.370177] 0x00000000b9800000-0x00000000b9856000 344K pte [ 0.370649] 0x00000000b9856000-0x00000000b9a00000 1704K RW NX pte [ 0.371066] 0x00000000b9a00000-0x00000000baa00000 16M ro PSE x pmd and after [ 0.349577] 0x0000000000a00000-0x0000000080000000 2038M RW PSE NX pmd [ 0.350049] 0x0000000080000000-0x00000000b9800000 920M pmd [ 0.350514] 0x00000000b9800000-0x00000000b9856000 344K pte [ 0.351013] 0x00000000b9856000-0x00000000b9a00000 1704K RW NX pte so i'm still doing something wrong, I think?