From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id E0A0FC77B7C for ; Fri, 12 May 2023 10:59:35 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 784CC6B0071; Fri, 12 May 2023 06:59:35 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 734C36B0074; Fri, 12 May 2023 06:59:35 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5FC9D6B0075; Fri, 12 May 2023 06:59:35 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 504106B0071 for ; Fri, 12 May 2023 06:59:35 -0400 (EDT) Received: from smtpin24.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id EDE4D1A0F22 for ; Fri, 12 May 2023 10:59:34 +0000 (UTC) X-FDA: 80781307068.24.C3BF94A Received: from mga03.intel.com (mga03.intel.com [134.134.136.65]) by imf15.hostedemail.com (Postfix) with ESMTP id D3C89A000C for ; Fri, 12 May 2023 10:59:31 +0000 (UTC) Authentication-Results: imf15.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=L5PQ85tm; spf=none (imf15.hostedemail.com: domain of kirill.shutemov@linux.intel.com has no SPF policy when checking 134.134.136.65) smtp.mailfrom=kirill.shutemov@linux.intel.com; dmarc=pass (policy=none) header.from=intel.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1683889172; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=5VhKIvOuUIsbjtDiuabupcCEQEeixpgA7jeDbrlGh/I=; b=MXL6fRGR9BEkRbhfcxnsaLEOWPcG1b7e456euTygFw3D0B4y1G9ei5rHTyYdD5eI3F4bDT uo6eb7twR7D6QHM4+rrjn1yPVjmB8to4QSV0pFvRs+wYviDtkrPMZ+EfjORfrNzUqtvTd+ fLygAmIT/66eplYjFnwtnG84iOkId/k= ARC-Authentication-Results: i=1; imf15.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=L5PQ85tm; spf=none (imf15.hostedemail.com: domain of kirill.shutemov@linux.intel.com has no SPF policy when checking 134.134.136.65) smtp.mailfrom=kirill.shutemov@linux.intel.com; dmarc=pass (policy=none) header.from=intel.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1683889172; a=rsa-sha256; cv=none; b=w+AMZfYIXembyitALOsc9oLDZGv9IpW9rY6c0fjR1eVbT4vbM/X2VJayYgSweSJDwsK3Qn MmpGgU1o2paKKcyCYt1IuReFzERnik8gJV+Vo0YydJtlyGHCDqjjBqeTrN7mMR+DGREQg8 CkPi1sFpJHGk+9lHOYNpwPgbUCdq9SU= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1683889173; x=1715425173; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=W/Sy5iEXYzPeG4qafOn/+5F5tHWJJF3o7KWjI2bYvRU=; b=L5PQ85tmnIPMNDYuFG7HqXQ8ostVa0QymdGrapolBbTkgyXUx0duCuHC Nyyp+t3h0CF2m4oTQmPxBSaGgl10vFsy4HWmZTrM7vryuti5NXSgskS+B EFBpRdqPhDHt4IpcXsfgea675uj0eBYwrAY0V2p+rRHg0A1mkAMVMbrFA efFUy5nK5565nQv1skI+vH2h/bD2B04f+6jXppfQL889sl4WncVSBDkK3 TZUgqhfo/F7OatqmrRbUru+MmHm4bEF8q900R+3IbGbiXw/DKTO6YzW8K SwYfXOkjg1G2PVYz0GipPyoJj5IgR2Mpt9BQ/QCIA8o8mLyyM9LVw2dMS A==; X-IronPort-AV: E=McAfee;i="6600,9927,10707"; a="353896771" X-IronPort-AV: E=Sophos;i="5.99,269,1677571200"; d="scan'208";a="353896771" Received: from orsmga007.jf.intel.com ([10.7.209.58]) by orsmga103.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 12 May 2023 03:59:31 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10707"; a="694200727" X-IronPort-AV: E=Sophos;i="5.99,269,1677571200"; d="scan'208";a="694200727" Received: from akigyosi-mobl3.ger.corp.intel.com (HELO box.shutemov.name) ([10.249.37.101]) by orsmga007-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 12 May 2023 03:59:22 -0700 Received: by box.shutemov.name (Postfix, from userid 1000) id 16E0F10CD92; Fri, 12 May 2023 13:59:19 +0300 (+03) Date: Fri, 12 May 2023 13:59:19 +0300 From: "Kirill A. Shutemov" To: Ard Biesheuvel Cc: "Kirill A. Shutemov" , Borislav Petkov , Andy Lutomirski , Dave Hansen , Sean Christopherson , Andrew Morton , Joerg Roedel , Andi Kleen , Kuppuswamy Sathyanarayanan , David Rientjes , Vlastimil Babka , Tom Lendacky , Thomas Gleixner , Peter Zijlstra , Paolo Bonzini , Ingo Molnar , Dario Faggioli , Mike Rapoport , David Hildenbrand , Mel Gorman , marcelo.cerri@canonical.com, tim.gardner@canonical.com, khalid.elmously@canonical.com, philip.cox@canonical.com, aarcange@redhat.com, peterx@redhat.com, x86@kernel.org, linux-mm@kvack.org, linux-coco@lists.linux.dev, linux-efi@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCHv10 04/11] efi/x86: Implement support for unaccepted memory Message-ID: <20230512105919.lgy3cvio6m2vcygn@box.shutemov.name> References: <20230507234618.18067-1-kirill.shutemov@linux.intel.com> <20230507234618.18067-5-kirill.shutemov@linux.intel.com> <20230508190043.ouauzbghn27khdy4@box.shutemov.name> <20230509005634.qtuiodpirexbxu2k@box.shutemov.name> <20230512015909.2fj7bmp3ejc3owhs@box.shutemov.name> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspam-User: X-Rspamd-Server: rspam01 X-Rspamd-Queue-Id: D3C89A000C X-Stat-Signature: 3ene4syw4iqje8h8yyuw46jaozeijoco X-HE-Tag: 1683889171-980973 X-HE-Meta: U2FsdGVkX19rrPxlW9M0ou8eg6j9Xics7yuHKv6BUn4Cb7Jj9wlnNRb1JdnEptCUAfo/yTWW0vIXa6DAxf/W47DLPpTu9pTAhNDVvb1GDVNOr/A/c2rhfoBUKtzHmRTcX06tzV1Q2888npK11AYLgyN39EXqMyfDvvE6Z80YYllwJhq0EIJ6Cf1QuYv+I92C96VdUFTvmweGcpR4BiRGGKMJTr59T3DdqnDw1mX0OKv8f51eyUR00ef0nYTzCm1xdfcljDUpuhxMphaAAooJ1IuY79p5tgbeh/3+qTOgm4mbLwrOvyWMKL5u3ekmwUlePA2xgXYtt1aE5yzo1f2K8eFq+A9bvePygpW/pxLG6FcGN9LmKZCTFJZWWmC2fUhhkfWU+AEmPUnmLSqsitujPD6McTgrIbkFYT/K0Pn0WKXoE44aze8sEfEW+hEvY+uqolMd3xWcrz3PBkL9/emDOkrlNnruYX4ZgkZ+FWMHGOt+Lw1+th+DWMYJpX5AYgocNRQDRyCjFyFjFzvvFJ3vULFkfGaXi/1gERyPwJfjgGOV1FcPmQ3ZNgvACFbMxO9vmZS8x6jXBvW+UnmSMBFfBgzGApu3jc81TToOzhhMXrSG+k6dUp3wDGIacNrXerzbR3WvbxbgCD8JlNFdVniBw2Rjv9jHvmTzy6njoTojfmyrA0H4NQMvP2UnXirStlIZrAF4zMxeB+RbhRvBSIRMS6Tmy6Enp834nYNYXu+udhsObsu1np9frj97AS0nocKqPTI1P14GSm3wZQcvQggnkazdLonuXjoARErOzKzXO+JBjLTJYCdpYn6/Px6QAoVaiK8Gp2nGQib+cYMjOVInRRskWs3eOhVGlUyv4Jw2zopzEKcntlQH3unQ2UxnoTDUdVh4TiErLP3ogmJ51xlXyERPMwzzsVaN6ZxQ85qAlM+ImdYr6CG8nZAkkYmpbV34pCsmCOKfn4ulb1a120o xmmk+tvZ dmmmUEvMg+wwqMu/aym9UBFKsbkKeeCi7nekvU1wbZC6orP9CAmwLzar8JPPGKDOzvcu9/O6S1mIRcdG9lSZATETuCDdv9T1QaSjcJd1dVUdITfc= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Fri, May 12, 2023 at 09:39:30AM +0200, Ard Biesheuvel wrote: > Please replace PMD_SIZE with something along the lines of > EFI_UNACCEPTED_UNIT_SIZE and #define it to PMD_SIZE in > arch/x86/include/asm/efi.h. > > The comment below about the size of the bitmap vs the size of the > address space should probably move there as well. Okay, will do. > > +void accept_memory(phys_addr_t start, phys_addr_t end) > > +{ > > + unsigned long range_start, range_end; > > + unsigned long bitmap_size; > > + u64 unit_size; > > + > > + if (!unaccepted_table) > > + return; > > + > > + unit_size = unaccepted_table->unit_size; > > + > > + /* > > + * Only care for the part of the range that is represented > > + * in the bitmap. > > + */ > > + if (start < unaccepted_table->phys_base) > > + start = unaccepted_table->phys_base; > > + if (end < unaccepted_table->phys_base) > > + return; > > + > > + /* Translate to offsets from the beginning of the bitmap */ > > + start -= unaccepted_table->phys_base; > > + end -= unaccepted_table->phys_base; > > + > > + /* Make sure not to overrun the bitmap */ > > + if (end > unaccepted_table->size * unit_size * BITS_PER_BYTE) > > + end = unaccepted_table->size * unit_size * BITS_PER_BYTE; > > + > > Should we warn here? No. accept_memory() is nop for conventional memory (memblock calls it unconditionally). With the fixup, we only allocate bitmap for the range of physical address space where we have unaccepted memory. So if there's conventional memory after unaccepted, bitmap will not cover it. -- Kiryl Shutsemau / Kirill A. Shutemov