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.5 required=3.0 tests=DKIM_INVALID,DKIM_SIGNED, 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 AA25AC47254 for ; Sat, 2 May 2020 18:03:16 +0000 (UTC) Received: from ml01.01.org (ml01.01.org [198.145.21.10]) (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 8440420787 for ; Sat, 2 May 2020 18:03:16 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (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 8440420787 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=intel.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-nvdimm-bounces@lists.01.org Received: from ml01.vlan13.01.org (localhost [IPv6:::1]) by ml01.01.org (Postfix) with ESMTP id CB17F1009D113; Sat, 2 May 2020 11:01:50 -0700 (PDT) Received-SPF: Pass (mailfrom) identity=mailfrom; client-ip=2a00:1450:4864:20::544; helo=mail-ed1-x544.google.com; envelope-from=dan.j.williams@intel.com; receiver= Received: from mail-ed1-x544.google.com (mail-ed1-x544.google.com [IPv6:2a00:1450:4864:20::544]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id A13F910113FC7 for ; Sat, 2 May 2020 11:01:48 -0700 (PDT) Received: by mail-ed1-x544.google.com with SMTP id d16so9870463edq.7 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=q+QCSA/LNE2LM0QyWTFT3c7jhn1URV90PPq/gTsPVTRhxXDvPYco3TOF8KCUQubNYK LCpo8mydXlrFaUTfZrzHWzuQvRNS2IchL8bvMR3Em7Aw9RAvS/HCHBVbeNIrxcpEZc8K UsqRc4fnvVg4pPC39p8g8ksgaV19dmahobnOPpMDIyQxaemPcfWS1qiZg1RQxfIYs/gm yf+Ox76sSa4VtdgfOLhRguJ+lvO5PXk6+jN52vv33Fy9rFyOczKmIK8jfj6R0onQwphZ uTQGKD8Y5uDSdlzkHVB56WGslQv7JSDV+oBDypTHWqIC4b3hy/iFr8n+6gZ3MapS9f+e jbQg== X-Gm-Message-State: AGi0PuaWfjcDLmvOCdkS4yuRZ4dTPJeEHvhP8/NMo3FuDDf+et3Kq1zY HAzHoiST0jQkRIHst/mLJ1uBisExRNaH+YBC5heNig== 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 Message-ID-Hash: XFMNQNE3ENXPS3UXRHLQ3WUUWPIA55B2 X-Message-ID-Hash: XFMNQNE3ENXPS3UXRHLQ3WUUWPIA55B2 X-MailFrom: dan.j.williams@intel.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; suspicious-header 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 X-Mailman-Version: 3.1.1 Precedence: list List-Id: "Linux-nvdimm developer list." Archived-At: List-Archive: List-Help: List-Post: List-Subscribe: List-Unsubscribe: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit 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. _______________________________________________ Linux-nvdimm mailing list -- linux-nvdimm@lists.01.org To unsubscribe send an email to linux-nvdimm-leave@lists.01.org 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 ABDDAC47256 for ; Sat, 2 May 2020 18:03:15 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 902E12137B 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" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728161AbgEBSDO (ORCPT ); Sat, 2 May 2020 14:03:14 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:35054 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-FAIL-OK-FAIL) by vger.kernel.org with ESMTP id S1727988AbgEBSDO (ORCPT ); Sat, 2 May 2020 14:03:14 -0400 Received: from mail-ed1-x541.google.com (mail-ed1-x541.google.com [IPv6:2a00:1450:4864:20::541]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id BDF3AC061A0C for ; Sat, 2 May 2020 11:03:13 -0700 (PDT) Received: by mail-ed1-x541.google.com with SMTP id t12so9875356edw.3 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=aPOvOdVZMBJJQcM6IXK0MijR9nSkbXTI3KpMdHZE0rhIM0uK52e/1CMqQ+1U4LYgJU jQPFu/D/buWNedBwQoggrr+gbYMIeZgMbju6IoC5hxKJT42FCkERcpvfW1fAYKeP5OtZ hdmflnbIVc6ylUEP5VVixTJ/gCZBQKwEJhA5GWaQSSKMZHnuIuJv4XOIgFQuZR2eVt2F Zc9pRbdKIQcLInFbMqQZSnRerW5ALX8XVP9GNFjxJWh5wItB7ZBA+Vfr6BK7FC++6Nbj 2MRoROmLrBuVmeNCpXtlDQWHq+MMIG6Ic7zlv9gwc0vJpDLpKwuya7hsMs/SqbnIGdq2 oP8w== X-Gm-Message-State: AGi0PuZHFCHJW+ue1PCRFgG83FV0DRgoZNtSqGvZmlQnOw5QZ/cD810y 2vsSVkoclBvkVPMmqWBSg2i+Ux2vknfLPHQ2FQfIKQ== 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" Sender: linux-acpi-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-acpi@vger.kernel.org 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. 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. 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.6 required=3.0 tests=DKIM_INVALID,DKIM_SIGNED, 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 92CE4C3A5A9 for ; Sat, 2 May 2020 18:06:40 +0000 (UTC) Received: from lists.ozlabs.org (lists.ozlabs.org [203.11.71.2]) (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 E395A206CD for ; Sat, 2 May 2020 18:06:39 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (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 E395A206CD Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=intel.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Received: from bilbo.ozlabs.org (lists.ozlabs.org [IPv6:2401:3900:2:1::3]) by lists.ozlabs.org (Postfix) with ESMTP id 49Dxrr5LfDzDqTs for ; Sun, 3 May 2020 04:06:36 +1000 (AEST) Authentication-Results: lists.ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=intel.com (client-ip=2a00:1450:4864:20::544; helo=mail-ed1-x544.google.com; envelope-from=dan.j.williams@intel.com; receiver=) Authentication-Results: lists.ozlabs.org; dmarc=pass (p=none dis=none) header.from=intel.com Authentication-Results: lists.ozlabs.org; dkim=pass (2048-bit key; unprotected) header.d=intel-com.20150623.gappssmtp.com header.i=@intel-com.20150623.gappssmtp.com header.a=rsa-sha256 header.s=20150623 header.b=aSBw5wCD; dkim-atps=neutral Received: from mail-ed1-x544.google.com (mail-ed1-x544.google.com [IPv6:2a00:1450:4864:20::544]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 49Dxn861PszDrMJ for ; Sun, 3 May 2020 04:03:16 +1000 (AEST) Received: by mail-ed1-x544.google.com with SMTP id a8so9889028edv.2 for ; Sat, 02 May 2020 11:03:16 -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=VwYj0fMcKbQZzPMvcWkCtZb+1UkVrzUts69+q1aQ6jAhWMrjQmcWiO0TwaJRUZvJOF 7CyGuZg9cuWl2AfrcNb25lFOEdeHD00Ayb51QluuyR3U0EVC9c5QKz8aGDfE/K4ph5I7 e3NTu8iqDdfdqHMjqaTfhduVZCIHJZPGSGxOIU9djjvuzl3WVt0VXSFiSTNCt86FJYle mNI73mB5LVHCFPj99kuR1mmouhAErLgxuaOqJn7BBgIVf39lIs74xIJLxxyQ+wT9SaX0 8lQ7lSySqUyIDp2cj9JUztM9mJ9paxs+3v4nhuADMVLU25NCxZWM8Qk8K5yhY2dK747G sd5g== X-Gm-Message-State: AGi0PuY1LoxyNWZ2gINrKVmDWyos1H5NqP45kVYt4TnAy33xR8/SXF4z jGS4SdO/JijObIQjBe4FgAe9FvyZsYQcZ3cVNDJJcA== 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 Content-Type: text/plain; charset="UTF-8" X-BeenThere: linuxppc-dev@lists.ozlabs.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: virtio-dev@lists.oasis-open.org, linux-hyperv@vger.kernel.org, Michal Hocko , Baoquan He , Linux ACPI , Wei Yang , linux-s390 , linux-nvdimm , Linux Kernel Mailing List , Dave Hansen , virtualization@lists.linux-foundation.org, Linux MM , "Michael S . Tsirkin" , "Eric W. Biederman" , Pankaj Gupta , xen-devel , Andrew Morton , Michal Hocko , linuxppc-dev Errors-To: linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Sender: "Linuxppc-dev" 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.