From: David Hildenbrand <david@redhat.com>
To: Dave Hansen <dave.hansen@intel.com>, linux-kernel@vger.kernel.org
Cc: linux-mm@kvack.org, virtio-dev@lists.oasis-open.org,
virtualization@lists.linux-foundation.org,
linuxppc-dev@lists.ozlabs.org, linux-acpi@vger.kernel.org,
linux-nvdimm@lists.01.org, linux-hyperv@vger.kernel.org,
linux-s390@vger.kernel.org, xen-devel@lists.xenproject.org,
Michal Hocko <mhocko@kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
"Michael S . Tsirkin" <mst@redhat.com>,
Michal Hocko <mhocko@suse.com>,
Pankaj Gupta <pankaj.gupta.linux@gmail.com>,
Wei Yang <richard.weiyang@gmail.com>, Baoquan He <bhe@redhat.com>,
Dave Hansen <dave.hansen@linux.intel.com>,
Eric Biederman <ebiederm@xmission.com>,
Pavel Tatashin <pasha.tatashin@soleen.com>
Subject: Re: [PATCH v2 3/3] device-dax: Add system ram (add_memory()) with MHP_NO_FIRMWARE_MEMMAP
Date: Thu, 30 Apr 2020 17:28:29 +0200 [thread overview]
Message-ID: <0e30697f-a5f7-e272-6aa5-8c7197c15818@redhat.com> (raw)
In-Reply-To: <20b86ced-7c47-02ca-0e0e-1bd5d6cc95c1@intel.com>
On 30.04.20 13:23, Dave Hansen wrote:
> On 4/30/20 3:29 AM, David Hildenbrand wrote:
>> Currently, when adding memory, we create entries in /sys/firmware/memmap/
>> as "System RAM". This does not reflect the reality and will lead to
>> kexec-tools to add that memory to the fixed-up initial memmap for a
>> kexec kernel (loaded via kexec_load()). The memory will be considered
>> initial System RAM by the kexec kernel.
>>
>> We should let the kexec kernel decide how to use that memory - just as
>> we do during an ordinary reboot.
> ...
>> - rc = add_memory(numa_node, new_res->start, resource_size(new_res), 0);
>> + rc = add_memory(numa_node, new_res->start, resource_size(new_res),
>> + MHP_NO_FIRMWARE_MEMMAP);
>
> Looks fine. But, if you send another revision, could you add a comment
> about the actual goal of MHP_NO_FIRMWARE_MEMMAP? Maybe:
>
> /*
> * MHP_NO_FIRMWARE_MEMMAP ensures that future
> * kexec'd kernels will not treat this as RAM.
> */
>
> Not a biggie, though.
Sure, maybe Andrew can fixup when applying (if no resend is necessary).
Thanks Dave!
>
> Acked-by: Dave Hansen <dave.hansen@linux.intel.com>
>
--
Thanks,
David / dhildenb
_______________________________________________
Linux-nvdimm mailing list -- linux-nvdimm@lists.01.org
To unsubscribe send an email to linux-nvdimm-leave@lists.01.org
WARNING: multiple messages have this Message-ID (diff)
From: David Hildenbrand <david@redhat.com>
To: Dave Hansen <dave.hansen@intel.com>, linux-kernel@vger.kernel.org
Cc: linux-mm@kvack.org, virtio-dev@lists.oasis-open.org,
virtualization@lists.linux-foundation.org,
linuxppc-dev@lists.ozlabs.org, linux-acpi@vger.kernel.org,
linux-nvdimm@lists.01.org, linux-hyperv@vger.kernel.org,
linux-s390@vger.kernel.org, xen-devel@lists.xenproject.org,
Michal Hocko <mhocko@kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
"Michael S . Tsirkin" <mst@redhat.com>,
Michal Hocko <mhocko@suse.com>,
Pankaj Gupta <pankaj.gupta.linux@gmail.com>,
Wei Yang <richard.weiyang@gmail.com>, Baoquan He <bhe@redhat.com>,
Dave Hansen <dave.hansen@linux.intel.com>,
Eric Biederman <ebiederm@xmission.com>,
Pavel Tatashin <pasha.tatashin@soleen.com>,
Dan Williams <dan.j.williams@intel.com>
Subject: Re: [PATCH v2 3/3] device-dax: Add system ram (add_memory()) with MHP_NO_FIRMWARE_MEMMAP
Date: Thu, 30 Apr 2020 17:28:29 +0200 [thread overview]
Message-ID: <0e30697f-a5f7-e272-6aa5-8c7197c15818@redhat.com> (raw)
In-Reply-To: <20b86ced-7c47-02ca-0e0e-1bd5d6cc95c1@intel.com>
On 30.04.20 13:23, Dave Hansen wrote:
> On 4/30/20 3:29 AM, David Hildenbrand wrote:
>> Currently, when adding memory, we create entries in /sys/firmware/memmap/
>> as "System RAM". This does not reflect the reality and will lead to
>> kexec-tools to add that memory to the fixed-up initial memmap for a
>> kexec kernel (loaded via kexec_load()). The memory will be considered
>> initial System RAM by the kexec kernel.
>>
>> We should let the kexec kernel decide how to use that memory - just as
>> we do during an ordinary reboot.
> ...
>> - rc = add_memory(numa_node, new_res->start, resource_size(new_res), 0);
>> + rc = add_memory(numa_node, new_res->start, resource_size(new_res),
>> + MHP_NO_FIRMWARE_MEMMAP);
>
> Looks fine. But, if you send another revision, could you add a comment
> about the actual goal of MHP_NO_FIRMWARE_MEMMAP? Maybe:
>
> /*
> * MHP_NO_FIRMWARE_MEMMAP ensures that future
> * kexec'd kernels will not treat this as RAM.
> */
>
> Not a biggie, though.
Sure, maybe Andrew can fixup when applying (if no resend is necessary).
Thanks Dave!
>
> Acked-by: Dave Hansen <dave.hansen@linux.intel.com>
>
--
Thanks,
David / dhildenb
WARNING: multiple messages have this Message-ID (diff)
From: David Hildenbrand <david@redhat.com>
To: Dave Hansen <dave.hansen@intel.com>, linux-kernel@vger.kernel.org
Cc: virtio-dev@lists.oasis-open.org, linux-hyperv@vger.kernel.org,
Michal Hocko <mhocko@suse.com>,
linux-acpi@vger.kernel.org, Baoquan He <bhe@redhat.com>,
linux-nvdimm@lists.01.org, linux-s390@vger.kernel.org,
"Michael S . Tsirkin" <mst@redhat.com>,
Dave Hansen <dave.hansen@linux.intel.com>,
virtualization@lists.linux-foundation.org, linux-mm@kvack.org,
Wei Yang <richard.weiyang@gmail.com>,
Eric Biederman <ebiederm@xmission.com>,
Pankaj Gupta <pankaj.gupta.linux@gmail.com>,
xen-devel@lists.xenproject.org,
Andrew Morton <akpm@linux-foundation.org>,
Michal Hocko <mhocko@kernel.org>,
linuxppc-dev@lists.ozlabs.org,
Dan Williams <dan.j.williams@intel.com>,
Pavel Tatashin <pasha.tatashin@soleen.com>
Subject: Re: [PATCH v2 3/3] device-dax: Add system ram (add_memory()) with MHP_NO_FIRMWARE_MEMMAP
Date: Thu, 30 Apr 2020 17:28:29 +0200 [thread overview]
Message-ID: <0e30697f-a5f7-e272-6aa5-8c7197c15818@redhat.com> (raw)
In-Reply-To: <20b86ced-7c47-02ca-0e0e-1bd5d6cc95c1@intel.com>
On 30.04.20 13:23, Dave Hansen wrote:
> On 4/30/20 3:29 AM, David Hildenbrand wrote:
>> Currently, when adding memory, we create entries in /sys/firmware/memmap/
>> as "System RAM". This does not reflect the reality and will lead to
>> kexec-tools to add that memory to the fixed-up initial memmap for a
>> kexec kernel (loaded via kexec_load()). The memory will be considered
>> initial System RAM by the kexec kernel.
>>
>> We should let the kexec kernel decide how to use that memory - just as
>> we do during an ordinary reboot.
> ...
>> - rc = add_memory(numa_node, new_res->start, resource_size(new_res), 0);
>> + rc = add_memory(numa_node, new_res->start, resource_size(new_res),
>> + MHP_NO_FIRMWARE_MEMMAP);
>
> Looks fine. But, if you send another revision, could you add a comment
> about the actual goal of MHP_NO_FIRMWARE_MEMMAP? Maybe:
>
> /*
> * MHP_NO_FIRMWARE_MEMMAP ensures that future
> * kexec'd kernels will not treat this as RAM.
> */
>
> Not a biggie, though.
Sure, maybe Andrew can fixup when applying (if no resend is necessary).
Thanks Dave!
>
> Acked-by: Dave Hansen <dave.hansen@linux.intel.com>
>
--
Thanks,
David / dhildenb
WARNING: multiple messages have this Message-ID (diff)
From: David Hildenbrand <david@redhat.com>
To: Dave Hansen <dave.hansen@intel.com>, linux-kernel@vger.kernel.org
Cc: linux-mm@kvack.org, virtio-dev@lists.oasis-open.org,
virtualization@lists.linux-foundation.org,
linuxppc-dev@lists.ozlabs.org, linux-acpi@vger.kernel.org,
linux-nvdimm@lists.01.org, linux-hyperv@vger.kernel.org,
linux-s390@vger.kernel.org, xen-devel@lists.xenproject.org,
Michal Hocko <mhocko@kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
"Michael S . Tsirkin" <mst@redhat.com>,
Michal Hocko <mhocko@suse.com>,
Pankaj Gupta <pankaj.gupta.linux@gmail.com>,
Wei Yang <richard.weiyang@gmail.com>, Baoquan He <bhe@redhat.com>,
Dave Hansen <dave.hansen@linux.intel.com>,
Eric Biederman <ebiederm@xmission.com>,
Pavel Tatashin <pasha.tatashin@soleen.com>,
Dan Williams <dan.j.williams@intel.com>
Subject: [virtio-dev] Re: [PATCH v2 3/3] device-dax: Add system ram (add_memory()) with MHP_NO_FIRMWARE_MEMMAP
Date: Thu, 30 Apr 2020 17:28:29 +0200 [thread overview]
Message-ID: <0e30697f-a5f7-e272-6aa5-8c7197c15818@redhat.com> (raw)
In-Reply-To: <20b86ced-7c47-02ca-0e0e-1bd5d6cc95c1@intel.com>
On 30.04.20 13:23, Dave Hansen wrote:
> On 4/30/20 3:29 AM, David Hildenbrand wrote:
>> Currently, when adding memory, we create entries in /sys/firmware/memmap/
>> as "System RAM". This does not reflect the reality and will lead to
>> kexec-tools to add that memory to the fixed-up initial memmap for a
>> kexec kernel (loaded via kexec_load()). The memory will be considered
>> initial System RAM by the kexec kernel.
>>
>> We should let the kexec kernel decide how to use that memory - just as
>> we do during an ordinary reboot.
> ...
>> - rc = add_memory(numa_node, new_res->start, resource_size(new_res), 0);
>> + rc = add_memory(numa_node, new_res->start, resource_size(new_res),
>> + MHP_NO_FIRMWARE_MEMMAP);
>
> Looks fine. But, if you send another revision, could you add a comment
> about the actual goal of MHP_NO_FIRMWARE_MEMMAP? Maybe:
>
> /*
> * MHP_NO_FIRMWARE_MEMMAP ensures that future
> * kexec'd kernels will not treat this as RAM.
> */
>
> Not a biggie, though.
Sure, maybe Andrew can fixup when applying (if no resend is necessary).
Thanks Dave!
>
> Acked-by: Dave Hansen <dave.hansen@linux.intel.com>
>
--
Thanks,
David / dhildenb
---------------------------------------------------------------------
To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org
next prev parent reply other threads:[~2020-04-30 15:28 UTC|newest]
Thread overview: 121+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-30 10:29 [PATCH v2 0/3] mm/memory_hotplug: Allow to not create firmware memmap entries David Hildenbrand
2020-04-30 10:29 ` [virtio-dev] " David Hildenbrand
2020-04-30 10:29 ` David Hildenbrand
2020-04-30 10:29 ` David Hildenbrand
2020-04-30 10:29 ` David Hildenbrand
2020-04-30 10:29 ` David Hildenbrand
2020-04-30 10:29 ` [PATCH v2 1/3] mm/memory_hotplug: Prepare passing flags to add_memory() and friends David Hildenbrand
2020-04-30 10:29 ` [virtio-dev] " David Hildenbrand
2020-04-30 10:29 ` David Hildenbrand
2020-04-30 10:29 ` David Hildenbrand
2020-04-30 10:29 ` David Hildenbrand
2020-04-30 10:29 ` David Hildenbrand
2020-04-30 10:29 ` [PATCH v2 2/3] mm/memory_hotplug: Introduce MHP_NO_FIRMWARE_MEMMAP David Hildenbrand
2020-04-30 10:29 ` [virtio-dev] " David Hildenbrand
2020-04-30 10:29 ` David Hildenbrand
2020-04-30 10:29 ` David Hildenbrand
2020-04-30 15:38 ` Eric W. Biederman
2020-04-30 15:38 ` Eric W. Biederman
2020-04-30 15:38 ` Eric W. Biederman
2020-04-30 15:38 ` Eric W. Biederman
2020-04-30 15:52 ` David Hildenbrand
2020-04-30 15:52 ` [virtio-dev] " David Hildenbrand
2020-04-30 15:52 ` David Hildenbrand
2020-04-30 15:52 ` David Hildenbrand
2020-04-30 16:04 ` Dave Hansen
2020-04-30 16:04 ` Dave Hansen
2020-04-30 16:04 ` Dave Hansen
2020-04-30 16:33 ` Eric W. Biederman
2020-04-30 16:33 ` Eric W. Biederman
2020-04-30 16:33 ` Eric W. Biederman
2020-04-30 16:33 ` Eric W. Biederman
2020-04-30 16:49 ` David Hildenbrand
2020-04-30 16:49 ` [virtio-dev] " David Hildenbrand
2020-04-30 16:49 ` David Hildenbrand
2020-04-30 16:49 ` David Hildenbrand
2020-04-30 18:06 ` Eric W. Biederman
2020-04-30 18:06 ` Eric W. Biederman
2020-04-30 18:06 ` Eric W. Biederman
2020-04-30 18:06 ` Eric W. Biederman
2020-04-30 18:43 ` David Hildenbrand
2020-04-30 18:43 ` [virtio-dev] " David Hildenbrand
2020-04-30 18:43 ` David Hildenbrand
2020-04-30 18:43 ` David Hildenbrand
2020-04-30 18:58 ` Dan Williams
2020-04-30 18:58 ` Dan Williams
2020-04-30 18:58 ` Dan Williams
2020-04-30 18:58 ` Dan Williams
2020-04-30 22:24 ` Andrew Morton
2020-04-30 22:24 ` Andrew Morton
2020-04-30 22:24 ` Andrew Morton
2020-05-01 9:34 ` David Hildenbrand
2020-05-01 9:34 ` [virtio-dev] " David Hildenbrand
2020-05-01 9:34 ` David Hildenbrand
2020-05-01 9:34 ` David Hildenbrand
2020-05-01 16:56 ` Dan Williams
2020-05-01 16:56 ` Dan Williams
2020-05-01 16:56 ` Dan Williams
2020-05-01 16:56 ` Dan Williams
2020-05-01 17:21 ` David Hildenbrand
2020-05-01 17:21 ` [virtio-dev] " David Hildenbrand
2020-05-01 17:21 ` David Hildenbrand
2020-05-01 17:21 ` David Hildenbrand
2020-05-01 17:39 ` Dan Williams
2020-05-01 17:39 ` Dan Williams
2020-05-01 17:39 ` Dan Williams
2020-05-01 17:39 ` Dan Williams
2020-05-01 17:45 ` David Hildenbrand
2020-05-01 17:45 ` [virtio-dev] " David Hildenbrand
2020-05-01 17:45 ` David Hildenbrand
2020-05-01 17:45 ` David Hildenbrand
2020-05-01 17:51 ` David Hildenbrand
2020-05-01 17:51 ` [virtio-dev] " David Hildenbrand
2020-05-01 17:51 ` David Hildenbrand
2020-05-01 17:51 ` David Hildenbrand
2020-05-01 18:03 ` Dan Williams
2020-05-01 18:03 ` Dan Williams
2020-05-01 18:03 ` Dan Williams
2020-05-01 18:03 ` Dan Williams
2020-05-01 18:14 ` David Hildenbrand
2020-05-01 18:14 ` [virtio-dev] " David Hildenbrand
2020-05-01 18:14 ` David Hildenbrand
2020-05-01 18:14 ` David Hildenbrand
2020-05-01 18:43 ` Dan Williams
2020-05-01 18:43 ` Dan Williams
2020-05-01 18:43 ` Dan Williams
2020-05-01 18:43 ` Dan Williams
2020-05-01 19:17 ` David Hildenbrand
2020-05-01 19:17 ` [virtio-dev] " David Hildenbrand
2020-05-01 19:17 ` David Hildenbrand
2020-05-01 19:17 ` David Hildenbrand
2020-05-01 20:12 ` Dan Williams
2020-05-01 20:12 ` Dan Williams
2020-05-01 20:12 ` Dan Williams
2020-05-01 20:12 ` Dan Williams
2020-05-01 21:10 ` David Hildenbrand
2020-05-01 21:10 ` [virtio-dev] " David Hildenbrand
2020-05-01 21:10 ` David Hildenbrand
2020-05-01 21:10 ` David Hildenbrand
2020-05-01 21:52 ` Dan Williams
2020-05-01 21:52 ` Dan Williams
2020-05-01 21:52 ` Dan Williams
2020-05-01 21:52 ` Dan Williams
2020-05-02 9:26 ` David Hildenbrand
2020-05-02 9:26 ` [virtio-dev] " David Hildenbrand
2020-05-02 9:26 ` David Hildenbrand
2020-05-02 9:26 ` David Hildenbrand
2020-05-02 18:03 ` Dan Williams
2020-05-02 18:03 ` Dan Williams
2020-05-02 18:03 ` Dan Williams
2020-05-02 18:03 ` Dan Williams
2020-04-30 10:29 ` [PATCH v2 3/3] device-dax: Add system ram (add_memory()) with MHP_NO_FIRMWARE_MEMMAP David Hildenbrand
2020-04-30 10:29 ` [virtio-dev] " David Hildenbrand
2020-04-30 10:29 ` David Hildenbrand
2020-04-30 10:29 ` David Hildenbrand
2020-04-30 11:23 ` Dave Hansen
2020-04-30 11:23 ` Dave Hansen
2020-04-30 11:23 ` Dave Hansen
2020-04-30 15:28 ` David Hildenbrand [this message]
2020-04-30 15:28 ` [virtio-dev] " David Hildenbrand
2020-04-30 15:28 ` David Hildenbrand
2020-04-30 15:28 ` David Hildenbrand
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=0e30697f-a5f7-e272-6aa5-8c7197c15818@redhat.com \
--to=david@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=bhe@redhat.com \
--cc=dave.hansen@intel.com \
--cc=dave.hansen@linux.intel.com \
--cc=ebiederm@xmission.com \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-hyperv@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-nvdimm@lists.01.org \
--cc=linux-s390@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=mhocko@kernel.org \
--cc=mhocko@suse.com \
--cc=mst@redhat.com \
--cc=pankaj.gupta.linux@gmail.com \
--cc=pasha.tatashin@soleen.com \
--cc=richard.weiyang@gmail.com \
--cc=virtio-dev@lists.oasis-open.org \
--cc=virtualization@lists.linux-foundation.org \
--cc=xen-devel@lists.xenproject.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.