From: David Hildenbrand <david@redhat.com>
To: Dan Williams <dan.j.williams@intel.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
"Eric W. Biederman" <ebiederm@xmission.com>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Linux MM <linux-mm@kvack.org>,
virtio-dev@lists.oasis-open.org,
virtualization@lists.linux-foundation.org,
linuxppc-dev <linuxppc-dev@lists.ozlabs.org>,
Linux ACPI <linux-acpi@vger.kernel.org>,
linux-nvdimm <linux-nvdimm@lists.01.org>,
linux-hyperv@vger.kernel.org,
linux-s390 <linux-s390@vger.kernel.org>,
xen-devel <xen-devel@lists.xenproject.org>,
Michal Hocko <mhocko@kernel.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>
Subject: Re: [PATCH v2 2/3] mm/memory_hotplug: Introduce MHP_NO_FIRMWARE_MEMMAP
Date: Sat, 2 May 2020 11:26:41 +0200 [thread overview]
Message-ID: <467ccba3-80ac-085c-3127-d5618d77d3e0@redhat.com> (raw)
In-Reply-To: <CAPcyv4h1nWjszkVJQgeXkUc=-nPv5=Me25BOGFQCpihUyFsD6w@mail.gmail.com>
>> 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?
--
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: Dan Williams <dan.j.williams@intel.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
"Eric W. Biederman" <ebiederm@xmission.com>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Linux MM <linux-mm@kvack.org>,
virtio-dev@lists.oasis-open.org,
virtualization@lists.linux-foundation.org,
linuxppc-dev <linuxppc-dev@lists.ozlabs.org>,
Linux ACPI <linux-acpi@vger.kernel.org>,
linux-nvdimm <linux-nvdimm@lists.01.org>,
linux-hyperv@vger.kernel.org,
linux-s390 <linux-s390@vger.kernel.org>,
xen-devel <xen-devel@lists.xenproject.org>,
Michal Hocko <mhocko@kernel.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>
Subject: Re: [PATCH v2 2/3] mm/memory_hotplug: Introduce MHP_NO_FIRMWARE_MEMMAP
Date: Sat, 2 May 2020 11:26:41 +0200 [thread overview]
Message-ID: <467ccba3-80ac-085c-3127-d5618d77d3e0@redhat.com> (raw)
In-Reply-To: <CAPcyv4h1nWjszkVJQgeXkUc=-nPv5=Me25BOGFQCpihUyFsD6w@mail.gmail.com>
>> 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?
--
Thanks,
David / dhildenb
WARNING: multiple messages have this Message-ID (diff)
From: David Hildenbrand <david@redhat.com>
To: Dan Williams <dan.j.williams@intel.com>
Cc: virtio-dev@lists.oasis-open.org, linux-hyperv@vger.kernel.org,
Michal Hocko <mhocko@suse.com>, Baoquan He <bhe@redhat.com>,
Linux ACPI <linux-acpi@vger.kernel.org>,
Wei Yang <richard.weiyang@gmail.com>,
linux-s390 <linux-s390@vger.kernel.org>,
linux-nvdimm <linux-nvdimm@lists.01.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Dave Hansen <dave.hansen@linux.intel.com>,
virtualization@lists.linux-foundation.org,
Linux MM <linux-mm@kvack.org>,
"Michael S . Tsirkin" <mst@redhat.com>,
"Eric W. Biederman" <ebiederm@xmission.com>,
Pankaj Gupta <pankaj.gupta.linux@gmail.com>,
xen-devel <xen-devel@lists.xenproject.org>,
Andrew Morton <akpm@linux-foundation.org>,
Michal Hocko <mhocko@kernel.org>,
linuxppc-dev <linuxppc-dev@lists.ozlabs.org>
Subject: Re: [PATCH v2 2/3] mm/memory_hotplug: Introduce MHP_NO_FIRMWARE_MEMMAP
Date: Sat, 2 May 2020 11:26:41 +0200 [thread overview]
Message-ID: <467ccba3-80ac-085c-3127-d5618d77d3e0@redhat.com> (raw)
In-Reply-To: <CAPcyv4h1nWjszkVJQgeXkUc=-nPv5=Me25BOGFQCpihUyFsD6w@mail.gmail.com>
>> 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?
--
Thanks,
David / dhildenb
WARNING: multiple messages have this Message-ID (diff)
From: David Hildenbrand <david@redhat.com>
To: Dan Williams <dan.j.williams@intel.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
"Eric W. Biederman" <ebiederm@xmission.com>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Linux MM <linux-mm@kvack.org>,
virtio-dev@lists.oasis-open.org,
virtualization@lists.linux-foundation.org,
linuxppc-dev <linuxppc-dev@lists.ozlabs.org>,
Linux ACPI <linux-acpi@vger.kernel.org>,
linux-nvdimm <linux-nvdimm@lists.01.org>,
linux-hyperv@vger.kernel.org,
linux-s390 <linux-s390@vger.kernel.org>,
xen-devel <xen-devel@lists.xenproject.org>,
Michal Hocko <mhocko@kernel.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>
Subject: [virtio-dev] Re: [PATCH v2 2/3] mm/memory_hotplug: Introduce MHP_NO_FIRMWARE_MEMMAP
Date: Sat, 2 May 2020 11:26:41 +0200 [thread overview]
Message-ID: <467ccba3-80ac-085c-3127-d5618d77d3e0@redhat.com> (raw)
In-Reply-To: <CAPcyv4h1nWjszkVJQgeXkUc=-nPv5=Me25BOGFQCpihUyFsD6w@mail.gmail.com>
>> 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?
--
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-05-02 9:27 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 [this message]
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
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=467ccba3-80ac-085c-3127-d5618d77d3e0@redhat.com \
--to=david@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=bhe@redhat.com \
--cc=dan.j.williams@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=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.