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 1EE9FC8300A for ; Thu, 30 Apr 2020 08:34:14 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id F03D12186A 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" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726701AbgD3IeN (ORCPT ); Thu, 30 Apr 2020 04:34:13 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:33346 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-FAIL-OK-FAIL) by vger.kernel.org with ESMTP id S1726412AbgD3IeM (ORCPT ); Thu, 30 Apr 2020 04:34:12 -0400 Received: from mail-ej1-x644.google.com (mail-ej1-x644.google.com [IPv6:2a00:1450:4864:20::644]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 83289C035494 for ; Thu, 30 Apr 2020 01:34:12 -0700 (PDT) Received: by mail-ej1-x644.google.com with SMTP id re23so3993706ejb.4 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=ithyq2qQKDpob3XTQDbB/6taukFLC+2nTW09zJQ5oeQwJgVaUdts/f2EVpIfawH90f 220OxM/zmyA27s9zMKqEaF8EwEMjaPQPzzlQKqfDyhbsPm6ctji6OPi9lQKallYkpfD6 Q9qLyD3Ups6/iT2XqTxz545XAs4HoxTbolpObxR6QTGyR9tpLzX3dIpSOCjs7zQLC3TY VrmZ9+jNhLx+xi56ce9qnsEXhUKyJHlP+seUxTbtw0943SrHG7XuiKWDD4Hd0+qzVVCJ ugythfguJHo1PUCZ4eiBZxuIa9qRDMS8tOOMfyvn7/N+N3dsJEfKBUCt630aQsDYrzP1 yi0g== X-Gm-Message-State: AGi0PuaI/CwJ1GPcdl1F+Wh3VJdu8pYh4eyaAYz9m8FfYuQNAkCLx+eS kgkPmTCAprHTE27xX1FTm01VcxmkBAwyzRVNJd86Jg== 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" Sender: linux-acpi-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-acpi@vger.kernel.org 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.