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 96EBCC83006 for ; Thu, 30 Apr 2020 08:34:29 +0000 (UTC) Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) (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 69377214D8 for ; Thu, 30 Apr 2020 08:34:29 +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="C7NzSwQe" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 69377214D8 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=intel.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=xen-devel-bounces@lists.xenproject.org Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jU4e8-0004js-V9; Thu, 30 Apr 2020 08:34:16 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jU4e8-0004jn-Bu for xen-devel@lists.xenproject.org; Thu, 30 Apr 2020 08:34:16 +0000 X-Inumbo-ID: 5ddc9dd0-8abd-11ea-ae69-bc764e2007e4 Received: from mail-ej1-x641.google.com (unknown [2a00:1450:4864:20::641]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 5ddc9dd0-8abd-11ea-ae69-bc764e2007e4; Thu, 30 Apr 2020 08:34:13 +0000 (UTC) Received: by mail-ej1-x641.google.com with SMTP id n4so3966276ejs.11 for ; Thu, 30 Apr 2020 01:34:12 -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=87dIcS/jrU3IxflLIkdtnvU4qll0iHvEZNuLGZ4o7wI=; b=C7NzSwQeQ8r7hb6zu0mE43nN5BVsWOZy21t9s86oMspwPoqNG+2r9QwYXMI253bkO+ f2NXbqJEZlVUDXw2jKOJXTdMksOMSeCU/1+d1/KW3kPK6bDnIkjaV85ydvslVx7+7VaK H/Wy8s3jtrbog9dFPbt+U8g4F9a/kPxAFzoHfDtTpSCDud/nTiDKxbIHNOx4gDT1cWli scShmtfTOkTf1D6LztaDjOZAMAIUOcl9E1Ehg4s+icpPrmffJn6TfhOtMJuuVZZemCWo u5q8IaOdIkls7C87+V/X7frCMtH72XB/et/faVXvhnFad5uP3/TQ8BbSLNTCllAusarT BwFQ== 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=87dIcS/jrU3IxflLIkdtnvU4qll0iHvEZNuLGZ4o7wI=; b=eBK7HnCm2+L9Ye86kGh2AOY2F3sNS/Z+gbFKxnbgmfAnuhNSSETHX6IqLSwc0Ah27b 1h6VpKIUuDIVpooJDKOlbG7K4CfzE34nYrXvkqRNi+DGwtBFO87WHBZUmUfUL/oo9dVO fxToH3GCwBGRo5CqrySxVoOAZu7kxhCFeAJWElhvEAdA4vpDazEzsRqhZshdP0ZFK47o BBrMA3iuV4ESMm+j8UujRX+m6wrNo0PBCz60axlUDJTA/+IWwrgNOVFSCQWV3Wc+jQLm yaw3l637rmMQ7MlqlgtC5sUyXmSh2mONCfAmtacFF95X2x43eAFpxlfJybdtBMCvJ4sb xjvQ== X-Gm-Message-State: AGi0Pub8WUzp0yGb/xZYONJzKrZ3FlofcgfpoGcMHyuPgfJtqzlQOBQ8 leTLheZJ4KZlMSt3L4zV2KFzNQuPIP3P3AdG7ZO/GA== X-Google-Smtp-Source: APiQypLBVztlIIHfr3wCtEt+MVa/TaJHl/O1nuNqStB0TwAKkS6wTTbCgFJlPXMDG8iI601GTPaB481cRsH+FNdImHY= X-Received: by 2002:a17:906:7750:: with SMTP id o16mr1715515ejn.12.1588235651152; Thu, 30 Apr 2020 01:34:11 -0700 (PDT) MIME-Version: 1.0 References: <20200429160803.109056-1-david@redhat.com> <20200429160803.109056-3-david@redhat.com> In-Reply-To: From: Dan Williams Date: Thu, 30 Apr 2020 01:34:00 -0700 Message-ID: Subject: Re: [PATCH v1 2/3] mm/memory_hotplug: Introduce MHP_DRIVER_MANAGED To: David Hildenbrand Content-Type: text/plain; charset="UTF-8" X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: virtio-dev@lists.oasis-open.org, linux-hyperv@vger.kernel.org, Michal Hocko , Pavel Tatashin , Baoquan He , Linux MM , Wei Yang , linux-s390 , linux-nvdimm , Linux Kernel Mailing List , Dave Hansen , virtualization@lists.linux-foundation.org, Linux ACPI , "Michael S . Tsirkin" , Eric Biederman , Pankaj Gupta , xen-devel , Andrew Morton , Michal Hocko , linuxppc-dev Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Thu, Apr 30, 2020 at 1:21 AM David Hildenbrand wrote: > >> Just because we decided to use some DAX memory in the current kernel as > >> system ram, doesn't mean we should make that decision for the kexec > >> kernel (e.g., using it as initial memory, placing kexec binaries onto > >> it, etc.). This is also not what we would observe during a real reboot. > > > > Agree. > > > >> I can see that the "System RAM" resource will show up as child resource > >> under the device e.g., in /proc/iomem. > >> > >> However, entries in /sys/firmware/memmap/ are created as "System RAM". > > > > True. Do you think this rename should just be limited to what type > > /sys/firmware/memmap/ emits? I have the concern, but no proof > > We could split this patch into > > MHP_NO_FIRMWARE_MEMMAP (create firmware memmap entries) > > and > > MHP_DRIVER_MANAGED (name of the resource) > > See below, the latter might not be needed. > > > currently, that there are /proc/iomem walkers that explicitly look for > > "System RAM", but might be thrown off by "System RAM (driver > > managed)". I was not aware of /sys/firmware/memmap until about 5 > > minutes ago. > > The only two users of /proc/iomem I am aware of are kexec-tools and some > s390x tools. > > kexec-tools on x86-64 uses /sys/firmware/memmap to craft the initial > memmap, but uses /proc/iomem to > a) Find places for kexec images > b) Detect memory regions to dump via kdump > > I am not yet sure if we really need the "System RAM (driver managed)" > part. If we can teach kexec-tools to > a) Don't place kexec images on "System RAM" that has a parent resource > (most likely requires kexec-tools changes) > b) Consider for kdump "System RAM" that has a parent resource > we might be able to avoid renaming that. (I assume that's already done) > > E.g., regarding virtio-mem (patch #3) I am currently also looking into > creating a parent resource instead, like dax/kmem to avoid the rename: > > :/# cat /proc/iomem > 00000000-00000fff : Reserved > [...] > 100000000-13fffffff : System RAM > 140000000-33fffffff : virtio0 > 140000000-147ffffff : System RAM > 148000000-14fffffff : System RAM > 150000000-157ffffff : System RAM > 340000000-303fffffff : virtio1 > 340000000-347ffffff : System RAM > 3280000000-32ffffffff : PCI Bus 0000:00 Looks good to me if it flies with kexec-tools.