Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755541AbcCNKae (ORCPT ); Mon, 14 Mar 2016 06:30:34 -0400 Received: from mail-wm0-f65.google.com ([74.125.82.65]:34511 "EHLO mail-wm0-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752344AbcCNKaY (ORCPT ); Mon, 14 Mar 2016 06:30:24 -0400 Date: Mon, 14 Mar 2016 11:30:19 +0100 From: Ingo Molnar To: Matt Fleming Cc: Scott Ashcroft , "H . Peter Anvin" , Thomas Gleixner , Ard Biesheuvel , linux-kernel@vger.kernel.org, linux-efi@vger.kernel.org, Maarten Lankhorst , Matthew Garrett , Borislav Petkov , Ben Hutchings , Raphael Hertzog , Roger Shimizu , Alexis Murzeau Subject: Re: [PATCH] x86/efi: Always map boot service regions into new EFI page tables Message-ID: <20160314103019.GA32573@gmail.com> References: <1457695163-29632-1-git-send-email-matt@codeblueprint.co.uk> <1457695163-29632-2-git-send-email-matt@codeblueprint.co.uk> <1457888975.3884.9.camel@talk21.com> <20160313215847.GA2619@codeblueprint.co.uk> <20160313230736.GB2619@codeblueprint.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160313230736.GB2619@codeblueprint.co.uk> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 790 Lines: 25 * Matt Fleming wrote: > diff --git a/arch/x86/mm/pageattr.c b/arch/x86/mm/pageattr.c > index 8fee5b6f8f66..af74849e8c0f 100644 > --- a/arch/x86/mm/pageattr.c > +++ b/arch/x86/mm/pageattr.c > @@ -1055,7 +1055,7 @@ static int populate_pud(struct cpa_data *cpa, unsigned long start, pgd_t *pgd, > /* > * Map everything starting from the Gb boundary, possibly with 1G pages > */ > - while (end - start >= PUD_SIZE) { > + while (cpu_has_gbpages && end - start >= PUD_SIZE) { > set_pud(pud, __pud(cpa->pfn << PAGE_SHIFT | _PAGE_PSE | > massage_pgprot(pud_pgprot))); Btw., can 'cpa->pfn << PAGE_SHIFT' possibly work on 32-bit systems? cpa->pfn is unsigned long, so the result gets truncated to 32 bits ... cpa->pfn should be u64. Thanks, Ingo