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 159F5C83009 for ; Thu, 30 Apr 2020 08:34:14 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id CBFFD20838 for ; Thu, 30 Apr 2020 08:34:13 +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="C7NzSwQe" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org CBFFD20838 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 76BDC8E0005; Thu, 30 Apr 2020 04:34:13 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 6F3968E0001; Thu, 30 Apr 2020 04:34:13 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 594258E0005; Thu, 30 Apr 2020 04:34:13 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0236.hostedemail.com [216.40.44.236]) by kanga.kvack.org (Postfix) with ESMTP id 3B9638E0001 for ; Thu, 30 Apr 2020 04:34:13 -0400 (EDT) Received: from smtpin08.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id DDCF3181AC9CB for ; Thu, 30 Apr 2020 08:34:12 +0000 (UTC) X-FDA: 76763859144.08.ball83_5ef2c1b2c6026 X-HE-Tag: ball83_5ef2c1b2c6026 X-Filterd-Recvd-Size: 5994 Received: from mail-ej1-f67.google.com (mail-ej1-f67.google.com [209.85.218.67]) by imf06.hostedemail.com (Postfix) with ESMTP for ; Thu, 30 Apr 2020 08:34:12 +0000 (UTC) Received: by mail-ej1-f67.google.com with SMTP id nv1so4007421ejb.0 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=cR24z4/1yBPtUXVwGnUCoPxtURzvEuyLFs/tFFOqGmykZhMH11RzF9wf0ZXXnJ8e1R rM/65XZvTQPna/wEAZlPbuo8kLk7IGiEv5aBJp/x3Ezjnpkrq8TNNH1HXajR2t89usaE O1YEgOj7fAEGmAQZPmU+Vv/sUzLh2d2pECZUuHo7SfyfxmXoMXJPJDtCzMzN5dS5A7NI 4Xm+YyLEMIWOpN0k2fDMgxspmR/8rpNMYwas2Qur7mrAtOX6Vpqwk/vfi4yvizJiiDSu KMLi5+zL8NrM4rhJ3njc6RuiqBZNw1pxMwBLuf91gCB9sFJWVuFOQIa9nRJ9x+6UDSWk rCEg== X-Gm-Message-State: AGi0Pub6ti2MZYSRcbfAwBRQjyToCaA09HJ8zTdWezd/X6u3shYbvt4F LpvPsPEn9amARBWc1u9SvyuKp8iJZO/8s9G1upjP+A== 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 Cc: 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 , Andrew Morton , "Michael S . Tsirkin" , Michal Hocko , Pankaj Gupta , Wei Yang , Baoquan He , Eric Biederman , Pavel Tatashin , 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 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.