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=-0.8 required=3.0 tests=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 B8048C47258 for ; Sat, 2 May 2020 18:03:15 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 5D71120787 for ; Sat, 2 May 2020 18:03:15 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=intel-com.20150623.gappssmtp.com header.i=@intel-com.20150623.gappssmtp.com header.b="aSBw5wCD" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 5D71120787 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=intel.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 8E6988E0005; Sat, 2 May 2020 14:03:14 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 8977E8E0001; Sat, 2 May 2020 14:03:14 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 785D88E0005; Sat, 2 May 2020 14:03:14 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0229.hostedemail.com [216.40.44.229]) by kanga.kvack.org (Postfix) with ESMTP id 5CF488E0001 for ; Sat, 2 May 2020 14:03:14 -0400 (EDT) Received: from smtpin01.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id 19D65181AEF10 for ; Sat, 2 May 2020 18:03:14 +0000 (UTC) X-FDA: 76772550708.01.swim31_5668764bbcb33 X-HE-Tag: swim31_5668764bbcb33 X-Filterd-Recvd-Size: 6598 Received: from mail-ed1-f68.google.com (mail-ed1-f68.google.com [209.85.208.68]) by imf02.hostedemail.com (Postfix) with ESMTP for ; Sat, 2 May 2020 18:03:13 +0000 (UTC) Received: by mail-ed1-f68.google.com with SMTP id j20so9891617edj.0 for ; Sat, 02 May 2020 11:03:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=intel-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=gzsuxDlItzKXIUBK7WGNpTkOsm9nq+BDdgFK8X2BWvo=; b=aSBw5wCDConKD/IcaaHbp4Mo0CTJ0pgKRvNWRkiIWGE3lCN/oPbrEa9/oKAglpfRn1 ybYK1kBJxRVbPzvApGi7N1gI88wlw4xjREME4zX7kVXKZH3FDgSbie3ks5shBRY8TZ6q DMFWhZRW7RkjeJCSKPKh/8pZ2QWGSZw/Nyq/zAlnOngdfv/+o/QV9wf4QVQZ5gXVDkzN XNN+MYW95/ejtNi3wUzQ6oJ8i+BfB05eb9CwAbUAIbruiYbVwz5lfsdGnAXaouOdPAgk c8v1YIbx6b+WQ999NPSKnSrIN3qI9oKtRGvdPYhTcKRXMBwc/GxItvO5XlgyBCaOSzcl 2H2w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=gzsuxDlItzKXIUBK7WGNpTkOsm9nq+BDdgFK8X2BWvo=; b=OnMB9Q1xAYU9y+G1Yscp9h5EOwydN90gOOZdo+PkO/0dZXFjW7UZdelVxgp7JK5kOe 3s0OHgAWA9yaiIc1ANDA6DaOXXM69Uu1JZnW3dhjERop06RQkmsmyHuJiTkVtsNQE28q U84R2EIFT9+P2IfJbOcw70+NMIoUP0ycFEkXLmaCMBlSbMn0dvvyiJ4x118M88ybNzmD 8I01aDuhPsNaW+lwu2yYm2X6Xpgas2YQz0UboTeuk5adtwaRCWbzYpKLcpncVyzNK/Ak XidAIjixihaP21NVTxwT7O2UGrdLyg8WKvQQzqxh8QuPKuaMrB7TCLuZNWjKdbXoBD95 WnNA== X-Gm-Message-State: AGi0PubrhqLo8vIhv+4BqZimoy3uuekaIiZ56LzbhmffAJOruNlOjDzz 3OgxnDCQukBJm/IVJLNC8+eWDKHQ76mhFkq5zRgt2w== X-Google-Smtp-Source: APiQypJrbz2VzfjebhxcGzu52aKY5ET0/26CFym5+FOkkSLJ9Vu46v3NJUgCYAVe4ZsgBJWlfsgCXWWgDBxtIIIlF1U= X-Received: by 2002:a05:6402:3136:: with SMTP id dd22mr8275680edb.165.1588442592251; Sat, 02 May 2020 11:03:12 -0700 (PDT) MIME-Version: 1.0 References: <20200430102908.10107-1-david@redhat.com> <875zdg26hp.fsf@x220.int.ebiederm.org> <20200430152403.e0d6da5eb1cad06411ac6d46@linux-foundation.org> <5c908ec3-9495-531e-9291-cbab24f292d6@redhat.com> <2d019c11-a478-9d70-abd5-4fd2ebf4bc1d@redhat.com> <62dd4ce2-86cc-5b85-734f-ec8766528a1b@redhat.com> <0169e822-a6cc-1543-88ed-2a85d95ffb93@redhat.com> <9f3a813e-dc1d-b675-6e69-85beed3057a4@redhat.com> <04242d48-5fa9-6da4-3e4a-991e401eb580@redhat.com> <8242c0c5-2df2-fc0c-079a-3be62c113a11@redhat.com> <467ccba3-80ac-085c-3127-d5618d77d3e0@redhat.com> In-Reply-To: <467ccba3-80ac-085c-3127-d5618d77d3e0@redhat.com> From: Dan Williams Date: Sat, 2 May 2020 11:03:01 -0700 Message-ID: Subject: Re: [PATCH v2 2/3] mm/memory_hotplug: Introduce MHP_NO_FIRMWARE_MEMMAP To: David Hildenbrand Cc: Andrew Morton , "Eric W. Biederman" , Linux Kernel Mailing List , Linux MM , virtio-dev@lists.oasis-open.org, virtualization@lists.linux-foundation.org, linuxppc-dev , Linux ACPI , linux-nvdimm , linux-hyperv@vger.kernel.org, linux-s390 , xen-devel , Michal Hocko , "Michael S . Tsirkin" , Michal Hocko , Pankaj Gupta , Wei Yang , Baoquan He , Dave Hansen Content-Type: text/plain; charset="UTF-8" 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 Sat, May 2, 2020 at 2:27 AM David Hildenbrand wrote: > > >> Now, let's clarify what I want regarding virtio-mem: > >> > >> 1. kexec should not add virtio-mem memory to the initial firmware > >> memmap. The driver has to be in charge as discussed. > >> 2. kexec should not place kexec images onto virtio-mem memory. That > >> would end badly. > >> 3. kexec should still dump virtio-mem memory via kdump. > > > > Ok, but then seems to say to me that dax/kmem is a different type of > > (driver managed) than virtio-mem and it's confusing to try to apply > > the same meaning. Why not just call your type for the distinct type it > > is "System RAM (virtio-mem)" and let any other driver managed memory > > follow the same "System RAM ($driver)" format if it wants? > > I had the same idea but discarded it because it seemed to uglify the > add_memory() interface (passing yet another parameter only relevant for > driver managed memory). Maybe we really want a new one, because I like > that idea: > > /* > * Add special, driver-managed memory to the system as system ram. > * The resource_name is expected to have the name format "System RAM > * ($DRIVER)", so user space (esp. kexec-tools)" can special-case it. > * > * For this memory, no entries in /sys/firmware/memmap are created, > * as this memory won't be part of the raw firmware-provided memory map > * e.g., after a reboot. Also, the created memory resource is flagged > * with IORESOURCE_MEM_DRIVER_MANAGED, so in-kernel users can special- > * case this memory (e.g., not place kexec images onto it). > */ > int add_memory_driver_managed(int nid, u64 start, u64 size, > const char *resource_name); > > > If we'd ever have to special case it even more in the kernel, we could > allow to specify further resource flags. While passing the driver name > instead of the resource_name would be an option, this way we don't have > to hand craft new resource strings for added memory resources. > > Thoughts? Looks useful to me and simplifies walking /proc/iomem. I personally like the safety of the string just being the $driver component of the name, but I won't lose sleep if the interface stays freeform like you propose.