Received: by 2002:a6b:fb09:0:0:0:0:0 with SMTP id h9csp4100972iog; Tue, 28 Jun 2022 09:01:19 -0700 (PDT) X-Google-Smtp-Source: AGRyM1vZ0KMqP9/txEOm2jHQk+7hUFLHkkb3aO4kXem2ykREPaHTyKnCYvdHM+Mwp7XKyx7p6mAp X-Received: by 2002:a05:6a00:1a08:b0:510:a1db:1a91 with SMTP id g8-20020a056a001a0800b00510a1db1a91mr4298389pfv.69.1656432079649; Tue, 28 Jun 2022 09:01:19 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1656432079; cv=none; d=google.com; s=arc-20160816; b=ifsww+imrHAWicVoErRKlnJgctlIDRDn82LVRPv16hRogf02qEBxDWDpsNzd0YTuD2 6XLP+LujR4Yf10NH2IUsApq844ILg2LbMS07MdshN9XLlv2ZTCX9tn7T0mnVT0lvu0vh 9r3wNhRq5mLvlp+9OTIlGgqirHVo+J3HKNNnRHfzzeaGCkk+l9hae+ooBfq1DG1RF4SW cuoSPbG4l8iTz8RdkxbPAMxM301J6p8I0cwz/4+P9OYiId89cDRbFjqeXIDJy5GnEide k4DNKPq/zs87BshpssNKF97A7l+o4OmgwBLR5aFqNoNknl+cenHxK7FeXr4kSmJOiDNI Ldrw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to:from :references:cc:to:content-language:subject:user-agent:mime-version :date:message-id:dkim-signature; bh=tz+O91YjNFbfZKqZPeiuynxV69mPrTD+jMXPaDnOXl4=; b=VyTBxiMMOJtYpQawXtKiH/kEP0R5MhdbzYtdX2Zy0SeKa5lvdMXAZreQ4dROwT5v1L DswDs+zNX8Sz2pvI8VgKQPawxG3hCpkZBm/xqcQpoQwdkFFbQXPbOalVCRySP22OBNDB HSfHHvhGPDVkmQ8ctLPQg9CAKjIZEyd0qnOS5X5bVMK2R31htNZsU6qRYPMzAeWel+yg TxhZ5K98QG/5CpoDHSIW2H/c1uQE8dBoLQ9dFkX30KRuiJO8xA5MtWsH2t4xN0dcYnFP 41q6DcZED01H2TyIQIWpAPhvyrAElunf7ypa++Azw+0gjQdBouCeQGhlNCEE5EQowtoC yYFg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=YJxdjUpn; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id v6-20020a17090a898600b001e2c9663635si20362379pjn.159.2022.06.28.09.00.50; Tue, 28 Jun 2022 09:01:19 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=YJxdjUpn; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1348244AbiF1PxH (ORCPT + 99 others); Tue, 28 Jun 2022 11:53:07 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:33118 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1346284AbiF1PxF (ORCPT ); Tue, 28 Jun 2022 11:53:05 -0400 Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id BFF5A333; Tue, 28 Jun 2022 08:53:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1656431584; x=1687967584; h=message-id:date:mime-version:subject:to:cc:references: from:in-reply-to:content-transfer-encoding; bh=YNRS2j3hTEQ2v8S8S/DXdGWTlv0yIqKFJkVZbqJR1WM=; b=YJxdjUpnNaJtW+MD/SEZFLnY1WM7J5BZByZepePktGse5IyjsOvycT51 tEtkjqGIBuFQprHyvGsWnX0D2joN0Vuewy+jEup7hfMwdgiglSIeZZmFt GfkBdUG+P+XtMMOmxoRre205wmGBNV1CX0Nt7+IMc8Y/TtzNvaoO3NM04 0eURjoG6Upz8aM3CNHDjye8lgHjFoJCGtoow++LBnwkwWdPNOhmydlWVe cilRZ0jPToyg5SpsF+Uvyhora0PRHwD129mW64n/3yTkvy9GaMBPw8QX2 Gb1TJrC/EpKgQsGtdz/zqikwsbOd4WIs/dvFcMgEWThAukWxq83LJbIO7 w==; X-IronPort-AV: E=McAfee;i="6400,9594,10392"; a="281814469" X-IronPort-AV: E=Sophos;i="5.92,229,1650956400"; d="scan'208";a="281814469" Received: from orsmga007.jf.intel.com ([10.7.209.58]) by fmsmga103.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 28 Jun 2022 08:53:04 -0700 X-IronPort-AV: E=Sophos;i="5.92,229,1650956400"; d="scan'208";a="587912493" Received: from staibmic-mobl1.amr.corp.intel.com (HELO [10.209.67.166]) ([10.209.67.166]) by orsmga007-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 28 Jun 2022 08:53:03 -0700 Message-ID: <2eff7546-5ab5-d4cd-43f6-d66b6490d725@intel.com> Date: Tue, 28 Jun 2022 08:52:00 -0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.9.1 Subject: Re: [RFC v2] memmap: introduce cmdline parameter "memmap=nn[KMG]$" without start addr Content-Language: en-US To: lizhe.67@bytedance.com, tglx@linutronix.de, mingo@redhat.com, bp@alien8.de, dave.hansen@linux.intel.com, x86@kernel.org, hpa@zytor.com Cc: lizefan.x@bytedance.com, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org References: <20220628124529.15431-1-lizhe.67@bytedance.com> From: Dave Hansen In-Reply-To: <20220628124529.15431-1-lizhe.67@bytedance.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-7.5 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A, RCVD_IN_DNSWL_HI,SPF_HELO_NONE,SPF_NONE,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 6/28/22 05:45, lizhe.67@bytedance.com wrote: > From: Li Zhe > > In current kernel we can use memmap=nn[KMG]$ss[KMG] to reserve an > area of memory for userspace usage through /dev/mem. We have to > determine the start addr and length. In our scenario, we need > reserve or alloc large continuous physical memory at least 256M in > 512G's machine, and need reserve more memory in larger machine, at > just boot phase for a userspace program. And these memories will not > be freed to system before system reboot. The userspace program can > use the memory through /dev/mem to store some data. Besides, a > hardware will need the data stored by the userspace program to do > it's job. Why we need continuous memory is that the hardware can > only access memory without mmu. That's still a rather anemic description. I don't think we want this code in the kernel with that description, sorry. If you'd like to come back with an actual description, naming the exact hardware that you have *AND* explaining sane reasons for why the hardware doesn't have a normal kernel driver (or interface) like every other piece of hardware, then we can talk. But, otherwise, this isn't something that can go upstream.