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 X-Spam-Level: X-Spam-Status: No, score=-3.8 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 5D5D3C4742C for ; Tue, 3 Nov 2020 12:54:08 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id CA34320731 for ; Tue, 3 Nov 2020 12:54:07 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="xUdtJKW8"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=mg.codeaurora.org header.i=@mg.codeaurora.org header.b="Uw8Oi1cs" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org CA34320731 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=codeaurora.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Type: Content-Transfer-Encoding:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:Message-ID:References:In-Reply-To:Subject:To:From: Date:MIME-Version:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=z7RBs3KGihI268d/AolYn3OWzKCNRudeyneFTKhDhiI=; b=xUdtJKW8WiiaPsCmrRMK5Uq8I CrxEZYreEXkYrjKb1rsriWjbjsDozq1ahES20yyJOpohbwvHHEgWG+OZ/qyVjq4RJfLIlpKDb34W2 fi7mZpt1D62EznjY9FTXTMNrZqde50vDNKo+nDdPXvFx0ppz+WbB/X0S6Dt+TL6DMH6w+MMTalynK +dQc+e6QF8KezAb9OdaEwf5fwX5Vavj3xW1YkBwHlWaTTaIVICa40MOsbwAPxslX741eL0NY713hP HBTKWPR7Moa83pVDqY9heOFnNs0i86ntk2pCCk49Zbanb8Z3+S+eSfaJS2+n6FdgyTQqbXoS3X0AO B1qfIvRpA==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kZvoX-00005K-8D; Tue, 03 Nov 2020 12:53:29 +0000 Received: from z5.mailgun.us ([104.130.96.5]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1kZvoO-0008UF-CD for linux-arm-kernel@lists.infradead.org; Tue, 03 Nov 2020 12:53:24 +0000 DKIM-Signature: a=rsa-sha256; v=1; c=relaxed/relaxed; d=mg.codeaurora.org; q=dns/txt; s=smtp; t=1604408000; h=Message-ID: References: In-Reply-To: Subject: Cc: To: From: Date: Content-Transfer-Encoding: Content-Type: MIME-Version: Sender; bh=3euWrf7R06QN8CqTw6UG20KChFG7Q3BWaZnvp+cCPsk=; b=Uw8Oi1cshHOuBvPjS/K/vQbqh4arPeZ6zxO1m6QW+G0uWEeUjumJN+QVz/MLMl4esbBs7a42 2xR0PUhfHFJ7BnUS4518RkIzpbMpc9JWvpkqCVFpLX1ujShM6T3qvEI5m/yP2TdK3VZ7A/VA PrNp7lgqXXGpjxyTMSpTcW0iPX4= X-Mailgun-Sending-Ip: 104.130.96.5 X-Mailgun-Sid: WyJiYzAxZiIsICJsaW51eC1hcm0ta2VybmVsQGxpc3RzLmluZnJhZGVhZC5vcmciLCAiYmU5ZTRhIl0= Received: from smtp.codeaurora.org (ec2-35-166-182-171.us-west-2.compute.amazonaws.com [35.166.182.171]) by smtp-out-n01.prod.us-west-2.postgun.com with SMTP id 5fa152bf93c4278c722ea0bc (version=TLS1.2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256); Tue, 03 Nov 2020 12:53:19 GMT Received: by smtp.codeaurora.org (Postfix, from userid 1001) id 193A8C4339C; Tue, 3 Nov 2020 02:15:44 +0000 (UTC) Received: from mail.codeaurora.org (localhost.localdomain [127.0.0.1]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: sudaraja) by smtp.codeaurora.org (Postfix) with ESMTPSA id 6FF0FC43382; Tue, 3 Nov 2020 02:15:43 +0000 (UTC) MIME-Version: 1.0 Date: Mon, 02 Nov 2020 18:15:43 -0800 From: Sudarshan Rajagopalan To: David Hildenbrand Subject: Re: mm/memblock: export memblock_{start/end}_of_DRAM In-Reply-To: <7b50c0fa-bbeb-1041-c05c-2667134044b6@redhat.com> References: <7b50c0fa-bbeb-1041-c05c-2667134044b6@redhat.com> Message-ID: <8ddfc74f0bd529ad78bd2e2d0b95a6c6@codeaurora.org> X-Sender: sudaraja@codeaurora.org User-Agent: Roundcube Webmail/1.3.9 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20201103_075320_681530_85CE714F X-CRM114-Status: GOOD ( 47.14 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Mark Rutland , Anshuman Khandual , Catalin Marinas , linux-kernel@vger.kernel.org, Steven Price , Suren Baghdasaryan , Mike Rapoport , Greg Kroah-Hartman , Will Deacon , linux-arm-kernel@lists.infradead.org, Pratik Patel Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="utf-8"; Format="flowed" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org T24gMjAyMC0xMC0yOSAyMzo0MSwgRGF2aWQgSGlsZGVuYnJhbmQgd3JvdGU6Cj4gT24gMjkuMTAu MjAgMjI6MjksIFN1ZGFyc2hhbiBSYWphZ29wYWxhbiB3cm90ZToKPj4gSGVsbG8gYWxsLAo+PiAK PiAKPiBIaSEKPiAKCkhpIERhdmlkLi4gdGhhbmtzIGZvciB0aGUgcmVzcG9uc2UgYXMgYWx3YXlz LgoKPj4gV2UgaGF2ZSBhIHVzZWNhc2Ugd2hlcmUgYSBtb2R1bGUgZHJpdmVyIGFkZHMgY2VydGFp biBtZW1vcnkgYmxvY2tzIAo+PiB1c2luZwo+PiBhZGRfbWVtb3J5X2RyaXZlcl9tYW5hZ2VkKCks IHNvIHRoYXQgaXQgY2FuIHBlcmZvcm0gbWVtb3J5IGhvdHBsdWcKPj4gb3BlcmF0aW9ucyBvbiB0 aGVzZSBibG9ja3MuIEluIGdlbmVyYWwsIHRoZXNlIG1lbW9yeSBibG9ja3MgYXJlbuKAmXQKPj4g c29tZXRoaW5nIHRoYXQgZ2V0cyBwaHlzaWNhbGx5IGFkZGVkIGxhdGVyLCBidXQgaXMgcGFydCBv ZiBhY3R1YWwgUkFNCj4+IHRoYXQgc3lzdGVtIGJvb3RlZCB1cCB3aXRoLiBNZWFuaW5nIOKAkyB3 ZSBzZXQgdGhlIOKAmG1lbT3igJkgY21kbGluZQo+PiBwYXJhbWV0ZXIgdG8gbGltaXQgdGhlIG1l bW9yeSBhbmQgbGF0ZXIgYWRkIHRoZSByZW1haW5pbmcgb25lcyB1c2luZwo+PiBhZGRfbWVtb3J5 KigpIHZhcmlhbnRzLgo+PiAKPj4gVGhlIGJhc2ljIGlkZWEgaXMgdG8gaGF2ZSBkcml2ZXIgaGF2 ZSBvd25lcnNoaXAgYW5kIG1hbmFnZSBjZXJ0YWluCj4+IG1lbW9yeSBibG9ja3MgZm9yIGhvdHBs dWcgb3BlcmF0aW9ucy4KPiAKPiBTbywgaW4gc3VtbWFyeSwgeW91J3JlIHN0aWxsIGFidXNpbmcg dGhlIG1lbW9yeSBob3QodW4pcGx1Zwo+IGluZnJhc3RydWN0dXJlIGZyb20geW91ciBkcml2ZXIg LSBqdXN0IG5vdCBpbiBhIHNldmVyZSB3YXkgYXMgYmVmb3JlLgo+IEFuZCBJJ2xsIHRlbGwgeW91 IHdoeSwgc28geW91IG1pZ2h0IHVuZGVyc3RhbmQgd2h5IGV4cG9zaW5nIHRoaXMgQVBJCj4gaXMg bm90IHJlYWxseSBhIGdvb2QgaWRlYSBhbmQgd2h5IHlvdXIgZHJpdmVyIHdvdWxkbid0IC0gZm9y IGV4YW1wbGUgLQo+IGJlIHVwc3RyZWFtIG1hdGVyaWFsLgo+IAo+IERvbid0IGdldCBtZSB3cm9u Zywgd2hhdCB5b3UgYXJlIGRvaW5nIG1pZ2h0IGJlIG9rIGluIHlvdXIgY29udGV4dCwKPiBidXQg aXQncyBzaW1wbHkgbm90IHVuaXZlcnNhbGx5IGFwcGxpY2FibGUgaW4gb3VyIGN1cnJlbnQgbW9k ZWwuCj4gCj4gT3JkaW5hcnkgc3lzdGVtIFJBTSB3b3JrcyBkaWZmZXJlbnQgdGhhbiBtYW55IG90 aGVyIGRldmljZXMgKGxpa2UgUENJCj4gZGV2aWNlcykgd2hlcmVieSAqc29tZXRoaW5nKiBzZW5z ZXMgdGhlIGRldmljZSBhbmQgZXhwb3NlcyBpdCB0byB0aGUKPiBzeXN0ZW0sIGFuZCBzb21lIGF2 YWlsYWJsZSBkcml2ZXIgYmluZHMgdG8gaXQgYW5kIG93bnMgdGhlIG1lbW9yeS4KPiAKPiBNZW1v cnkgaXMgZGV0ZWN0ZWQgYnkgYSBkcml2ZXIgYW5kIGFkZGVkIHRvIHRoZSBzeXN0ZW0gdmlhIGUu Zy4sCj4gYWRkX21lbW9yeV9kcml2ZXJfbWFuYWdlZCgpLiBNZW1vcnkgZGV2aWNlcyBhcmUgY3Jl YXRlZCBhbmQgdGhlIG1lbW9yeQo+IGlzIGRpcmVjdGx5IGhhbmRlZCBvZmYgdG8gdGhlIHN5c3Rl bSwgdG8gYmUgdXNlZCBhcyBzeXN0ZW0gUkFNIGFzIHNvb24KPiBhcyBtZW1vcnkgZGV2aWNlcyBh cmUgb25saW5lZC4gVGhlcmUgaXMgbm8gZHJpdmVyIHRoYXQgImJpbmRzIiBtZW1vcnkKPiBsaWtl IG90aGVyIGRldmljZXMgLSBpdCdzIHJhdGhlciB0aGUgY29yZSAoYnVkZHkpIHRoYXQgdXNlcy9v d25zIHRoYXQKPiBtZW1vcnkgaW1tZWRpYXRlbHkgYWZ0ZXIgZGV2aWNlIGNyZWF0aW9uLgo+IAoK SSBzZWUuLiBhbmQgSSBhZ3JlZSB0aGF0IGRyaXZlcnMgYXJlIG1lYW50IHRvICpzZW5zZSogdGhh dCBzb21ldGhpbmcgCmNoYW5nZWQgb3IgbmV3bHkgYWRkZWQsIHNvIHRoYXQgZHJpdmVyIGNhbiBj aGVjayBpZiBpdCdzIHRoZSBvbmUgCnJlc3BvbnNpYmxlIG9yIGNvbXBhdGlibGUgZm9yIGhhbmRs aW5nIHRoaXMgZW50aXR5IGFuZCBiaW5kcyB0byBpdC4gU28gSSAKZ3Vlc3Mgd2hhdCBpdCBib2ls cyBkb3duIHRvIGlzIC0gYSBkcml2ZXIgdGhhdCB1c2VzIG1lbW9yeSBob3RwbHVnIApfY2Fubm90 XyBhZGQvcmVtb3ZlIG9yIGhhdmUgb3duZXJzaGlwIG9mIG1lbWJsb2NrIGJvb3QgbWVtb3J5LCBi dXQgZm9yIAp0aGUgbmV3bHkgYWRkZWQgUkFNIGJsb2NrcyBsYXRlciBvbi4KCkkgd2FzIHRyeWlu ZyB0byBtaW1pYyB0aGUgZGV0ZWN0aW5nIGFuZCBhZGRpbmcgb2YgZXh0cmEgUkFNIGJ5IGxpbWl0 aW5nIAp0aGUgU3lzdGVtIFJBTSB3aXRoICJtZW09WEdCIiBhcyB0aG91Z2ggc3lzdGVtIGJvb3Rl ZCB3aXRoIFhHQiBvZiBib290IAptZW1vcnkgYW5kIGxhdGVyIGFkZCB0aGUgcmVtYWluaW5nIGJs b2NrcyAoZm9yY2UgZGV0ZWN0aW9uIGFuZCBhZGRpbmcpIAp1c2luZyBhZGRfbWVtb3JZLWRyaXZl cl9tYW5hZ2VyKCkuIFRoaXMgcmVtYWluaW5nIGJsb2NrcyBhcmUgY2FsY3VsYXRlZCAKYnkgJ3Bo eXNpY2FsIGVuZCBhZGRyIG9mIGJvb3QgbWVtb3J5JyAtICdtZW1ibG9ja19lbmRfb2ZfRFJBTScu IFRoZSAKInBoeXNpY2FsIGVuZCBhZGRyIG9mIGJvb3QgbWVtb3J5IiBpLmUuIHRoZSBhY3R1YWwg UkFNIHRoYXQgYm9vdGxvYWRlciAKaW5mb3JtcyB0byBrZXJuZWwgY2FuIGJlIG9idGFpbmVkIGJ5 IHNjYW5uaW5nIHRoZSAnbWVtb3J5JyBEVCBub2RlLgoKPj4gCj4+IEZvciB0aGUgZHJpdmVyIGJl IGFibGUgdG8ga25vdyBob3cgbXVjaCBtZW1vcnkgd2FzIGxpbWl0ZWQgYW5kIGhvdyAKPj4gbXVj aAo+PiBhY3R1YWxseSBwcmVzZW50LCB3ZSB0YWtlIHRoZSBkZWx0YSBvZiDigJhib290bWVtIHBo eXNpY2FsIGVuZCBhZGRyZXNz4oCZCj4+IGFuZCDigJhtZW1ibG9ja19lbmRfb2ZfRFJBTeKAmS4g VGhlICdib290bWVtIHBoeXNpY2FsIGVuZCBhZGRyZXNzJyBpcwo+PiBvYnRhaW5lZCBieSBzY2Fu bmluZyB0aGUgcmVnIHZhbHVlcyBpbiDigJhtZW1vcnnigJkgRFQgbm9kZSBhbmQgCj4+IGRldGVy bWluaW5nCj4+IHRoZSBtYXgge2FkZHIsc2l6ZX0uIFNpbmNlIG91ciBkcml2ZXIgaXMgZ2V0dGlu ZyBtb2R1bGFyaXplZCwgd2Ugd29u4oCZdAo+PiBoYXZlIGFjY2VzcyB0byBtZW1ibG9ja19lbmRf b2ZfRFJBTSAoaS5lLiBlbmQgYWRkcmVzcyBvZiBhbGwgbWVtb3J5Cj4+IGJsb2NrcyBhZnRlciDi gJhtZW094oCZIGlzIGFwcGxpZWQpLgo+IAo+IFdoYXQgeW91IGRvIHdpdGggIm1lbT0iIGlzIGZv cmNlIG1lbW9yeSBkZXRlY3Rpb24gdG8gaWdub3JlIHNvbWUgb2YKPiBpdCdzIGRldGVjdGVkIG1l bW9yeS4KPiAKPj4gCj4+IFNvIGNoZWNraW5nIGlmIG1lbWJsb2NrX3tzdGFydC9lbmR9X29mX0RS QU0oKSBzeW1ib2xzIGNhbiBiZSBleHBvcnRlZD8KPj4gQWxzbywgdGhpcyBpbmZvcm1hdGlvbiBj YW4gYmUgb2J0YWluZWQgYnkgdXNlcnNwYWNlIGJ5IGRvaW5nIOKAmGNhdAo+PiAvcHJvYy9pb21l beKAmSBhbmQgZ3JlcGluZyBmb3Ig4oCYU3lzdGVtIFJBTeKAmS4gU28gd29uZGVyaW5nIGlmIHVz ZXJzcGFjZSAKPj4gY2FuCj4gCj4gTm90IGNvcnJlY3Q6IHdpdGggIm1lbT0iLCBjYXQgL3Byb2Mv aW9tZW0gb25seSBzaG93cyAqZGV0ZWN0ZWQqICsKPiBhZGRlZCBzeXN0ZW0gUkFNLCBub3QgdGhl IHVubW9kaWZpZWQgZGV0ZWN0aW9uLgo+IAoKVGhhdCdzIGNvcnJlY3QgLSBJIG1lYW50ICdtZW1i bG9ja19lbmRfb2ZfRFJBTScgYWxvbmcgd2l0aCAibWVtPSIgY2FuIGJlIApjYWxjdWxhdGVkIHVz aW5nICdjYXQgL3Byb2MvaW9tZW0nIHdoaWNoIHNob3dzICJkZXRlY3RlZCBwbHVzIGFkZGVkIiAK U3lzdGVtIFJBTSwgYW5kIG5vdCB0aGUgcmVtYWluaW5nIHVuZGV0ZWN0ZWQgb25lIHdoaWNoIGdv dCBzdHJpcHBlZCBvZmYgCmR1ZSB0byAibWVtPVhHQiIuIEJhc2ljYWxseSwgJ21lbWJsb2NrX2Vu ZF9vZl9EUkFNJyBhZGRyZXNzIHdpdGggCidtZW09WEdCJyBpcyB7ZW5kIGFkZHIgb2YgYm9vdCBS QU0gLSBYR0J9Li4gd2hpY2ggd291bGQgYmUgc2FtZSBhcyBlbmQgCmFkZHJlc3Mgb2YgIlN5c3Rl bSBSQU0iIHNob3dlZCBpbiAvcHJvYy9pb21lbS4KClRoZSByZWFzb25pbmcgZm9yIHRoaXMgaXMg LSBpZiB1c2Vyc3BhY2UgY2FuIGhhdmUgYWNjZXNzIHRvIHN1Y2ggaW5mbyAKYW5kIGNhbGN1bGF0 ZSB0aGUgbWVtYmxvY2sgZW5kIGFkZHJlc3MsIHdoeSBub3QgbGV0IGRyaXZlcnMgaGF2ZSB0aGlz IAppbmZvIHVzaW5nIG1lbWJsb2NrX2VuZF9vZl9EUkFNKCk/Cgo+PiBoYXZlIGFjY2VzcyB0byBz dWNoIGluZm8sIGNhbiB3ZSBhbGxvdyBrZXJuZWwgbW9kdWxlIGRyaXZlcnMgaGF2ZSAKPj4gYWNj ZXNzCj4+IGJ5IGV4cG9ydGluZyBtZW1ibG9ja197c3RhcnQvZW5kfV9vZl9EUkFNKCkuCj4+IAo+ PiBPciBhcmUgdGhlcmUgYW55IG90aGVyIHdheXMgd2hlcmUgYSBtb2R1bGUgZHJpdmVyIGNhbiBn ZXQgdGhlIGVuZAo+PiBhZGRyZXNzIG9mIHN5c3RlbSBtZW1vcnkgYmxvY2s/Cj4gCj4gQW5kIGhl cmUgaXMgb3VyIHByb2JsZW06IFlvdSBkaXNhYmxlZCAqZGV0ZWN0aW9uKiBvZiB0aGF0IG1lbW9y eSBieQo+IHRoZSByZXNwb25zaWJsZSBkcml2ZXIgKGhlcmU6IGNvcmUpLiBOb3cgeW91ciBkcml2 ZXIgd2FudHMgdG8ga25vdwo+IHdoYXQgd291bGQgaGF2ZSBiZWVuIGRldGVjdGVkLiBBc3N1bWUg eW91IGhhdmUgbWVtb3J5IGhvbGUgaW4gdGhhdAo+IHJlZ2lvbiAtIGl0IHdvdWxkIG5vdCB3b3Jr IGJ5IHNpbXBseSBsb29raW5nIGF0IHN0YXJ0L2VuZC4gWW91J3JlCj4gZHJpdmVyIGlzIG5vdCB0 aGUgb25lIGRvaW5nIHRoZSBkZXRlY3Rpb24uCj4gCgpSZWdhcmRpbmcgdGhlIG1lbW9yeSBob2xl IC0gdGhlIGRyaXZlciBjYW4gaW5zcGVjdCB0aGUgJ21lbW9yeScgRFQgbm9kZSAKdGhhdCBrZXJu ZWwgZ2V0cyBmcm9tIEFCTCBmcm9tIFJBTSBwYXJ0aXRpb24gdGFibGUgaWYgYW55IHN1Y2ggaG9s ZXMgCmV4aXN0IG9yIG5vdC4gSSBhZ3JlZSB0aGF0IGlmIHN1Y2ggaG9sZXMgZXhpc3RzLCBob3Qg YWRkaW5nIHdpbGwgZmFpbCAKc2luY2UgaXQgbmVlZHMgYmxvY2sgc2l6ZSB0byBiZSBhZGRlZC4K VGhlIHNhbWUgaXNzdWUgd2lsbCBhcmlzZSBpZiBhIFJBTSBzbG90IGlzIGFkZGVkIGFuZCBhIGRy aXZlciBzZW5zZXMgaXQgCmFuZCBpdCBvbmx5IGtub3dzIHRoZSBzdGFydC9lbmQgb2YgdGhpcyBS QU0gc2xvdCAodGhvdWdoIHN1Y2ggaG9sZXMgCmdlbmVyYWxseSBkb2Vzbid0IGV4aXN0cyBpbiBS QU0gc2xvdHMpLgoKVGhpcyBpcyBhZ2FpbiBzb21ldGhpbmcgc3BlY2lmaWMgdG8gb3VyIHRhcmdl dCB3aGljaCB3ZSBtYWtlIHN1cmUgdGhlcmUgCmFyZSBubyBzdWNoIGhvbGVzIGluIHRoZSB0b3Ag bW9zdCBtZW1vcnkgd2hpY2ggaXMgc3RyaXBwZWQgb2ZmIGJ5ICJtZW09IiAKYW5kIGxhdGVyIGFk ZGVkIGJ5IHRoZSBkcml2ZXIuIEkgYWdyZWUgdGhpcyBpcyBub3QgdW5pdmVyc2FsIHVwc3RyZWFt IAptYXRlcmlhbCB0eXBlLCBidXQgaXRzIGEgbWV0aG9kIHRoYXQgZHJpdmVycyBjYW4gdXRpbGl6 ZS4KCj4gQW5vdGhlciBpc3N1ZSBpczogd2hlbiB1c2luZyBzdWNoIG1lbW9yeSBmb3IgS1ZNIGd1 ZXN0cywgdGhlcmUgaXMgbm8KPiBtZWNoYW5pc20gdGhhdCB0cmFja3Mgb3duZXJzaGlwIG9mIHRo YXQgbWVtb3J5IC0gaW1hZ2luZSBhbm90aGVyCj4gZHJpdmVyIHdhbnRpbmcgdG8gdXNlIHRoYXQg bWVtb3J5LiBUaGlzIHJlYWxseSBvbmx5IHdvcmtzIGluIHNwZWNpYWwKPiBlbnZpcm9ubWVudHMu Cj4gCj4gWWV0IGFub3RoZXIgaXNzdWU6IHlvdSBjYW5ub3QgYXNzdW1lIHRoYXQgbWVtYmxvY2sg ZGF0YSB3aWxsIHN0YXkKPiBhcm91bmQgYWZ0ZXIgYm9vdC4gV2hpbGUgd2UgZG8gaXQgcmlnaHQg bm93IGZvciBhcm02NCwgdGhhdCBtaWdodAo+IGNoYW5nZSBhdCBzb21lIHBvaW50LiBUaGlzIGlz IGFsc28gb25lIG9mIHRoZSByZWFzb25zIHdoeSB3ZSBkb24ndAo+IGV4cG9ydCBhbnkgcmVhbCBt ZW1ibG9jayBkYXRhIHRvIGRyaXZlcnMuCj4gCj4gCj4gV2hlbiB1c2luZyAibWVtPSIgeW91IGhh dmUgdG8ga25vdyB0aGUgZXhhY3QgbGF5b3V0IG9mIHlvdXIgc3lzdGVtIFJBTQo+IGFuZCBjb21t dW5pY2F0ZSB0aGUgcmlnaHQgcGxhY2VzIGhvdyB0aGF0IGxheW91dCBsb29rcyBsaWtlIG1hbnVh bGx5Ogo+IGhlcmUsIHRvIHlvdXIgZHJpdmVyLgo+IAoKSSBhZ3JlZSB0aGUgaXNzdWVzIG1lbnRp b25lZCBoZXJlIHdpdGggdGhpcyBhcHByb2FjaCBhcmUgdmFsaWQgZnJvbSAKdXBzdHJlYW0gUE9W LCBidXQgd2UgYXJlbid0IHRyeWluZyB0byBtYWtlIGEgZ2VuZXJpYyBkcml2ZXIgZm9yIHRoaXMg CnVzZWNhc2UgYW5kIHVwc3RyZWFtIGl0LCBidXQgcmF0aGVyIGhhdmUgaXQgdGFpbG9yIG1hZGUg Zm9yIG91ciB1c2VjYXNlIAphbG9uZSB3aGVyZSB3ZSBrbm93IHRoZSBsYXlvdXQgb2YgdGhlIFN5 c3RlbSBSQU0gKG1heCBib290bWVtb3J5LCBubyAKaG9sZXMgZXRjKSBhbmQgd2UgdXRpbGl6ZSAi bWVtPSIgYW5kIG1lbW9yeSBob3RwbHVnIHNvIHRoYXQgZHJpdmVyIGNhbiAKYWRkIGFuZCBoYXZl IG93bmVyc2hpcCBvZiB0aGUgcmVtYWluaW5nIG1lbW9yeSBmb3IgbGF0ZXIgaG90cGx1ZyAKb3Bl cmF0aW9ucy4KCj4gVGhlIGNsZWFuIHdheSBvZiBkb2luZyB0aGluZ3MgdG9kYXkgaXMgdG8gYWxs b2NhdGUgUkFNIGFuZCB1c2UgaXQgZm9yCj4gZ3Vlc3RzIC0gZS5nLiwgdXNpbmcgaHVnZXRsYi9n aWdhbnRpYyBwYWdlcy4gQXMgSSBzYWlkLCB0aGVyZSBhcmUKPiBvdGhlciB0ZWNobmlxdWVzIGNv bWluZyB1cCB0byBkZWFsIHdpdGggbWluaW1pemluZyBzdHJ1Y3QgcGFnZQo+IG92ZXJoZWFkIC0g aWYgdGhhdCdzIHdoYXQgeW91J3JlIGNvbmNlcm5lZCB3aXRoIChJIHN0aWxsIGRvbid0IGtub3cK PiB3aHkgeW91J3JlIHJlbW92aW5nIHRoZSBtZW1vcnkgZnJvbSB0aGUgaG9zdCB3aGVuIGdpdmlu ZyBpdCB0byB0aGUKPiBndWVzdCkuCgpUaGUgb3ZlcmhlYWQgb2Ygc3RydXQgcGFnZSB3aXRoIGh1 Z2V0bGIgaXMgdmFsaWQsIGJ1dCB3ZSBoYXZlIG90aGVyIAp1c2VjYXNlcyBvdXRzaWRlIG9mIGlu dGVyLVZNIHNoYXJpbmcgd2hlcmUgd2UgcmVseSBvbiBtZW1vcnkgCmhvdHBsdWdnaW5nLiBJbiBn ZW5lcmFsLCB3ZSB3YW50IGEgd2F5IHRvIGJlIGFibGUgdG8gYWRkL3JlbW92ZSBhbmQgCm9mZmxp bmUvb25saW5lIGEgbWVtb3J5IHdoaWNoIGlzIHBhcnQgb2YgYm9vdC4gV2l0aCBhbGwgdGhlIHRv b2xzIAphdmFpbGFibGUgLSAibWVtPSIsICIvcHJvYy9pb21lbSIsICJtZW1vcnkiIERUIG5vZGUg YW5kIG1lbW9yeSBob3RwbHVnIApmcmFtZXdvcmssIGEgZHJpdmVyIGNhbiBzdGlsbCBiZSBhYmxl IHRvIGFjaGlldmUgdGhpcyBhbmQgdGhlc2UgdG9vbHMgCnRoYXQgYXJlIHByZXNlbnQgbm93IGRv ZXMgYWxsb3cgaXQuCgpLZWVwaW5nIHRoZSBpbnRlclZNIG1lbW9yeSBzaGFyaW5nIGFzaWRlLCB3 b3VsZCBpdCBiZSBva2F5IGlmIAptZW1ibG9ja19lbmRfb2ZfRFJBTSgpIGJlIGV4cG9ydGVkPyBM aWtlIEkgbWVudGlvbmVkIGJlZm9yZSwgdGhlcmUgY2FuIApiZSBhIHVzZXJzcGFjZSBzZXJ2aWNl IHRoYXQgY2FsY3VsYXRlcyB0aGlzIHVzaW5nICdjYXQgL3Byb2MvaW9tZW0nIGFuZCAKaGF2ZSBp dCBkZWxpdmVyZWQgdG8gZHJpdmVyIHZpYSBhIHN5c2ZzIG5vZGUuIFNvIEkgZG9udCBzZWUgYW55 IGhhcm0gaW4gCmV4cG9ydGluZyB0aGlzIGluZm8gdG8gZHJpdmVyLiBJIGFncmVlIG90aGVyIG1l bWJsb2NrIGluZm8gc2hvdWxkbid0IGJlIApleHBvc2VkIG91dHNpZGUgdG8gZHJpdmVycy4gQnV0 IEkgc2VlIG5vIGhhcm0gZm9yIAptZW1ibG9ja19lbmRfb2ZfRFJBTSgpLgoKSSB3aWxsIGJlIGds YWQgdG8gc2hhcmUgbW9yZSBpbmZvIGFib3V0IHRoZSB1c2VjYXNlIHdoZXJlIHdlIHVzZSB0aGlz IAphcHByb2FjaCBpZiB0aGF0IHdvdWxkIGhlbHAsIGFuZCBJIGNhbiBjaGVjayBhbmQgZ2V0IGJh Y2sgb24gaG93IG11Y2ggd2UgCmNhbiBzaGFyZSBzaW5jZSB0aGlzIGlzIGEgcHJvcHJpZXRhcnkg dXNlY2FzZSBmb3IgUXVhbGNvbW0uCgoKU3VkYXJzaGFuCgotLQpRdWFsY29tbSBJbm5vdmF0aW9u IENlbnRlciwgSW5jLiBpcyBhIG1lbWJlciBvZiBDb2RlIEF1cm9yYSBGb3J1bSwgYSAKTGludXgg Rm91bmRhdGlvbiBDb2xsYWJvcmF0aXZlIFByb2plY3QKCl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fCmxpbnV4LWFybS1rZXJuZWwgbWFpbGluZyBsaXN0Cmxp bnV4LWFybS1rZXJuZWxAbGlzdHMuaW5mcmFkZWFkLm9yZwpodHRwOi8vbGlzdHMuaW5mcmFkZWFk Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL2xpbnV4LWFybS1rZXJuZWwK 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 X-Spam-Level: X-Spam-Status: No, score=-3.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 4F0C8C388F7 for ; Tue, 3 Nov 2020 12:53:24 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id DCD7020731 for ; Tue, 3 Nov 2020 12:53:23 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=mg.codeaurora.org header.i=@mg.codeaurora.org header.b="qEy66a11" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728980AbgKCMxX (ORCPT ); Tue, 3 Nov 2020 07:53:23 -0500 Received: from z5.mailgun.us ([104.130.96.5]:53046 "EHLO z5.mailgun.us" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726388AbgKCMxW (ORCPT ); Tue, 3 Nov 2020 07:53:22 -0500 DKIM-Signature: a=rsa-sha256; v=1; c=relaxed/relaxed; d=mg.codeaurora.org; q=dns/txt; s=smtp; t=1604408001; h=Message-ID: References: In-Reply-To: Subject: Cc: To: From: Date: Content-Transfer-Encoding: Content-Type: MIME-Version: Sender; bh=3euWrf7R06QN8CqTw6UG20KChFG7Q3BWaZnvp+cCPsk=; b=qEy66a110kOQzhSYQnntAS1WnPUrCW6IK0j/ecw8GrU6wHcaixAQiZ+johE9IDN3WY2NaeQU ZC7rR4ZQjcswgzfH/OXhGbyHKZszw50GE6rg4whaktq3E2Y5DEvecIy9UvmwdN7ZVRCLN8au 3CuCHutKJ8E0vnqRAFbAVSGanp0= X-Mailgun-Sending-Ip: 104.130.96.5 X-Mailgun-Sid: WyI0MWYwYSIsICJsaW51eC1rZXJuZWxAdmdlci5rZXJuZWwub3JnIiwgImJlOWU0YSJd Received: from smtp.codeaurora.org (ec2-35-166-182-171.us-west-2.compute.amazonaws.com [35.166.182.171]) by smtp-out-n06.prod.us-east-1.postgun.com with SMTP id 5fa152c075bebe827ae70af3 (version=TLS1.2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256); Tue, 03 Nov 2020 12:53:20 GMT Sender: sudaraja=codeaurora.org@mg.codeaurora.org Received: by smtp.codeaurora.org (Postfix, from userid 1001) id 234BFC433A0; Tue, 3 Nov 2020 02:15:45 +0000 (UTC) Received: from mail.codeaurora.org (localhost.localdomain [127.0.0.1]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: sudaraja) by smtp.codeaurora.org (Postfix) with ESMTPSA id 6FF0FC43382; Tue, 3 Nov 2020 02:15:43 +0000 (UTC) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Mon, 02 Nov 2020 18:15:43 -0800 From: Sudarshan Rajagopalan To: David Hildenbrand Cc: Anshuman Khandual , Mark Rutland , Steven Price , Mike Rapoport , linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, Catalin Marinas , Will Deacon , Suren Baghdasaryan , Greg Kroah-Hartman , Pratik Patel Subject: Re: mm/memblock: export memblock_{start/end}_of_DRAM In-Reply-To: <7b50c0fa-bbeb-1041-c05c-2667134044b6@redhat.com> References: <7b50c0fa-bbeb-1041-c05c-2667134044b6@redhat.com> Message-ID: <8ddfc74f0bd529ad78bd2e2d0b95a6c6@codeaurora.org> X-Sender: sudaraja@codeaurora.org User-Agent: Roundcube Webmail/1.3.9 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2020-10-29 23:41, David Hildenbrand wrote: > On 29.10.20 22:29, Sudarshan Rajagopalan wrote: >> Hello all, >> > > Hi! > Hi David.. thanks for the response as always. >> We have a usecase where a module driver adds certain memory blocks >> using >> add_memory_driver_managed(), so that it can perform memory hotplug >> operations on these blocks. In general, these memory blocks aren’t >> something that gets physically added later, but is part of actual RAM >> that system booted up with. Meaning – we set the ‘mem=’ cmdline >> parameter to limit the memory and later add the remaining ones using >> add_memory*() variants. >> >> The basic idea is to have driver have ownership and manage certain >> memory blocks for hotplug operations. > > So, in summary, you're still abusing the memory hot(un)plug > infrastructure from your driver - just not in a severe way as before. > And I'll tell you why, so you might understand why exposing this API > is not really a good idea and why your driver wouldn't - for example - > be upstream material. > > Don't get me wrong, what you are doing might be ok in your context, > but it's simply not universally applicable in our current model. > > Ordinary system RAM works different than many other devices (like PCI > devices) whereby *something* senses the device and exposes it to the > system, and some available driver binds to it and owns the memory. > > Memory is detected by a driver and added to the system via e.g., > add_memory_driver_managed(). Memory devices are created and the memory > is directly handed off to the system, to be used as system RAM as soon > as memory devices are onlined. There is no driver that "binds" memory > like other devices - it's rather the core (buddy) that uses/owns that > memory immediately after device creation. > I see.. and I agree that drivers are meant to *sense* that something changed or newly added, so that driver can check if it's the one responsible or compatible for handling this entity and binds to it. So I guess what it boils down to is - a driver that uses memory hotplug _cannot_ add/remove or have ownership of memblock boot memory, but for the newly added RAM blocks later on. I was trying to mimic the detecting and adding of extra RAM by limiting the System RAM with "mem=XGB" as though system booted with XGB of boot memory and later add the remaining blocks (force detection and adding) using add_memorY-driver_manager(). This remaining blocks are calculated by 'physical end addr of boot memory' - 'memblock_end_of_DRAM'. The "physical end addr of boot memory" i.e. the actual RAM that bootloader informs to kernel can be obtained by scanning the 'memory' DT node. >> >> For the driver be able to know how much memory was limited and how >> much >> actually present, we take the delta of ‘bootmem physical end address’ >> and ‘memblock_end_of_DRAM’. The 'bootmem physical end address' is >> obtained by scanning the reg values in ‘memory’ DT node and >> determining >> the max {addr,size}. Since our driver is getting modularized, we won’t >> have access to memblock_end_of_DRAM (i.e. end address of all memory >> blocks after ‘mem=’ is applied). > > What you do with "mem=" is force memory detection to ignore some of > it's detected memory. > >> >> So checking if memblock_{start/end}_of_DRAM() symbols can be exported? >> Also, this information can be obtained by userspace by doing ‘cat >> /proc/iomem’ and greping for ‘System RAM’. So wondering if userspace >> can > > Not correct: with "mem=", cat /proc/iomem only shows *detected* + > added system RAM, not the unmodified detection. > That's correct - I meant 'memblock_end_of_DRAM' along with "mem=" can be calculated using 'cat /proc/iomem' which shows "detected plus added" System RAM, and not the remaining undetected one which got stripped off due to "mem=XGB". Basically, 'memblock_end_of_DRAM' address with 'mem=XGB' is {end addr of boot RAM - XGB}.. which would be same as end address of "System RAM" showed in /proc/iomem. The reasoning for this is - if userspace can have access to such info and calculate the memblock end address, why not let drivers have this info using memblock_end_of_DRAM()? >> have access to such info, can we allow kernel module drivers have >> access >> by exporting memblock_{start/end}_of_DRAM(). >> >> Or are there any other ways where a module driver can get the end >> address of system memory block? > > And here is our problem: You disabled *detection* of that memory by > the responsible driver (here: core). Now your driver wants to know > what would have been detected. Assume you have memory hole in that > region - it would not work by simply looking at start/end. You're > driver is not the one doing the detection. > Regarding the memory hole - the driver can inspect the 'memory' DT node that kernel gets from ABL from RAM partition table if any such holes exist or not. I agree that if such holes exists, hot adding will fail since it needs block size to be added. The same issue will arise if a RAM slot is added and a driver senses it and it only knows the start/end of this RAM slot (though such holes generally doesn't exists in RAM slots). This is again something specific to our target which we make sure there are no such holes in the top most memory which is stripped off by "mem=" and later added by the driver. I agree this is not universal upstream material type, but its a method that drivers can utilize. > Another issue is: when using such memory for KVM guests, there is no > mechanism that tracks ownership of that memory - imagine another > driver wanting to use that memory. This really only works in special > environments. > > Yet another issue: you cannot assume that memblock data will stay > around after boot. While we do it right now for arm64, that might > change at some point. This is also one of the reasons why we don't > export any real memblock data to drivers. > > > When using "mem=" you have to know the exact layout of your system RAM > and communicate the right places how that layout looks like manually: > here, to your driver. > I agree the issues mentioned here with this approach are valid from upstream POV, but we aren't trying to make a generic driver for this usecase and upstream it, but rather have it tailor made for our usecase alone where we know the layout of the System RAM (max bootmemory, no holes etc) and we utilize "mem=" and memory hotplug so that driver can add and have ownership of the remaining memory for later hotplug operations. > The clean way of doing things today is to allocate RAM and use it for > guests - e.g., using hugetlb/gigantic pages. As I said, there are > other techniques coming up to deal with minimizing struct page > overhead - if that's what you're concerned with (I still don't know > why you're removing the memory from the host when giving it to the > guest). The overhead of strut page with hugetlb is valid, but we have other usecases outside of inter-VM sharing where we rely on memory hotplugging. In general, we want a way to be able to add/remove and offline/online a memory which is part of boot. With all the tools available - "mem=", "/proc/iomem", "memory" DT node and memory hotplug framework, a driver can still be able to achieve this and these tools that are present now does allow it. Keeping the interVM memory sharing aside, would it be okay if memblock_end_of_DRAM() be exported? Like I mentioned before, there can be a userspace service that calculates this using 'cat /proc/iomem' and have it delivered to driver via a sysfs node. So I dont see any harm in exporting this info to driver. I agree other memblock info shouldn't be exposed outside to drivers. But I see no harm for memblock_end_of_DRAM(). I will be glad to share more info about the usecase where we use this approach if that would help, and I can check and get back on how much we can share since this is a proprietary usecase for Qualcomm. Sudarshan -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project