All of lore.kernel.org
 help / color / mirror / Atom feed
From: ebiederm@xmission.com (Eric W. Biederman)
To: David Hildenbrand <david@redhat.com>
Cc: linux-kernel@vger.kernel.org, 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>
Subject: Re: [PATCH v2 2/3] mm/memory_hotplug: Introduce MHP_NO_FIRMWARE_MEMMAP
Date: Thu, 30 Apr 2020 10:38:04 -0500	[thread overview]
Message-ID: <87pnbp2dcz.fsf@x220.int.ebiederm.org> (raw)
In-Reply-To: <20200430102908.10107-3-david@redhat.com> (David Hildenbrand's message of "Thu, 30 Apr 2020 12:29:07 +0200")

David Hildenbrand <david@redhat.com> writes:

> Some devices/drivers that add memory via add_memory() and friends (e.g.,
> dax/kmem, but also virtio-mem in the future) don't want to create entries
> in /sys/firmware/memmap/ - primarily to hinder kexec from adding this
> memory to the boot memmap of the kexec kernel.
>
> In fact, such memory is never exposed via the firmware memmap as System
> RAM (e.g., e820), so exposing this memory via /sys/firmware/memmap/ is
> wrong:
>  "kexec needs the raw firmware-provided memory map to setup the
>   parameter segment of the kernel that should be booted with
>   kexec. Also, the raw memory map is useful for debugging. For
>   that reason, /sys/firmware/memmap is an interface that provides
>   the raw memory map to userspace." [1]
>
> We don't have to worry about firmware_map_remove() on the removal path.
> If there is no entry, it will simply return with -EINVAL.
>
> [1]
> https://www.kernel.org/doc/Documentation/ABI/testing/sysfs-firmware-memmap


You know what this justification is rubbish, and I have previously
explained why it is rubbish.

Nacked-by: "Eric W. Biederman" <ebiederm@xmission.com>

This needs to be based on weather the added memory is ultimately normal
ram or is something special.

At least when we are talking memory resources.  Keeping it out of the
firmware map that is fine.

If the hotplugged memory is the result of plugging a stick of ram
into the kernel and can and should used be like any other memory
it should be treated like any normal memory.

If the hotplugged memory is something special it should be treated as
something special.

Justifying behavior by documentation that does not consider memory
hotplug is bad thinking.








> Cc: Andrew Morton <akpm@linux-foundation.org>
> Cc: Michal Hocko <mhocko@suse.com>
> Cc: Pankaj Gupta <pankaj.gupta.linux@gmail.com>
> Cc: Wei Yang <richard.weiyang@gmail.com>
> Cc: Baoquan He <bhe@redhat.com>
> Cc: Eric Biederman <ebiederm@xmission.com>
> Signed-off-by: David Hildenbrand <david@redhat.com>
> ---
>  include/linux/memory_hotplug.h | 8 ++++++++
>  mm/memory_hotplug.c            | 3 ++-
>  2 files changed, 10 insertions(+), 1 deletion(-)
>
> diff --git a/include/linux/memory_hotplug.h b/include/linux/memory_hotplug.h
> index 0151fb935c09..4ca418a731eb 100644
> --- a/include/linux/memory_hotplug.h
> +++ b/include/linux/memory_hotplug.h
> @@ -68,6 +68,14 @@ struct mhp_params {
>  	pgprot_t pgprot;
>  };
>  
> +/* Flags used for add_memory() and friends. */
> +
> +/*
> + * Don't create entries in /sys/firmware/memmap/. The memory is detected and
> + * added via a device driver, not via the initial (firmware) memmap.
> + */
> +#define MHP_NO_FIRMWARE_MEMMAP		1
> +
>  /*
>   * Zone resizing functions
>   *
> diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
> index c01be92693e3..e94ede9cad00 100644
> --- a/mm/memory_hotplug.c
> +++ b/mm/memory_hotplug.c
> @@ -1062,7 +1062,8 @@ int __ref add_memory_resource(int nid, struct resource *res,
>  	BUG_ON(ret);
>  
>  	/* create new memmap entry */
> -	firmware_map_add_hotplug(start, start + size, "System RAM");
> +	if (!(flags & MHP_NO_FIRMWARE_MEMMAP))
> +		firmware_map_add_hotplug(start, start + size, "System RAM");
>  
>  	/* device_online() will take the lock when calling online_pages() */
>  	mem_hotplug_done();
_______________________________________________
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: ebiederm@xmission.com (Eric W. Biederman)
To: David Hildenbrand <david@redhat.com>
Cc: linux-kernel@vger.kernel.org, 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>
Subject: Re: [PATCH v2 2/3] mm/memory_hotplug: Introduce MHP_NO_FIRMWARE_MEMMAP
Date: Thu, 30 Apr 2020 10:38:04 -0500	[thread overview]
Message-ID: <87pnbp2dcz.fsf@x220.int.ebiederm.org> (raw)
In-Reply-To: <20200430102908.10107-3-david@redhat.com> (David Hildenbrand's message of "Thu, 30 Apr 2020 12:29:07 +0200")

David Hildenbrand <david@redhat.com> writes:

> Some devices/drivers that add memory via add_memory() and friends (e.g.,
> dax/kmem, but also virtio-mem in the future) don't want to create entries
> in /sys/firmware/memmap/ - primarily to hinder kexec from adding this
> memory to the boot memmap of the kexec kernel.
>
> In fact, such memory is never exposed via the firmware memmap as System
> RAM (e.g., e820), so exposing this memory via /sys/firmware/memmap/ is
> wrong:
>  "kexec needs the raw firmware-provided memory map to setup the
>   parameter segment of the kernel that should be booted with
>   kexec. Also, the raw memory map is useful for debugging. For
>   that reason, /sys/firmware/memmap is an interface that provides
>   the raw memory map to userspace." [1]
>
> We don't have to worry about firmware_map_remove() on the removal path.
> If there is no entry, it will simply return with -EINVAL.
>
> [1]
> https://www.kernel.org/doc/Documentation/ABI/testing/sysfs-firmware-memmap


You know what this justification is rubbish, and I have previously
explained why it is rubbish.

Nacked-by: "Eric W. Biederman" <ebiederm@xmission.com>

This needs to be based on weather the added memory is ultimately normal
ram or is something special.

At least when we are talking memory resources.  Keeping it out of the
firmware map that is fine.

If the hotplugged memory is the result of plugging a stick of ram
into the kernel and can and should used be like any other memory
it should be treated like any normal memory.

If the hotplugged memory is something special it should be treated as
something special.

Justifying behavior by documentation that does not consider memory
hotplug is bad thinking.








> Cc: Andrew Morton <akpm@linux-foundation.org>
> Cc: Michal Hocko <mhocko@suse.com>
> Cc: Pankaj Gupta <pankaj.gupta.linux@gmail.com>
> Cc: Wei Yang <richard.weiyang@gmail.com>
> Cc: Baoquan He <bhe@redhat.com>
> Cc: Eric Biederman <ebiederm@xmission.com>
> Signed-off-by: David Hildenbrand <david@redhat.com>
> ---
>  include/linux/memory_hotplug.h | 8 ++++++++
>  mm/memory_hotplug.c            | 3 ++-
>  2 files changed, 10 insertions(+), 1 deletion(-)
>
> diff --git a/include/linux/memory_hotplug.h b/include/linux/memory_hotplug.h
> index 0151fb935c09..4ca418a731eb 100644
> --- a/include/linux/memory_hotplug.h
> +++ b/include/linux/memory_hotplug.h
> @@ -68,6 +68,14 @@ struct mhp_params {
>  	pgprot_t pgprot;
>  };
>  
> +/* Flags used for add_memory() and friends. */
> +
> +/*
> + * Don't create entries in /sys/firmware/memmap/. The memory is detected and
> + * added via a device driver, not via the initial (firmware) memmap.
> + */
> +#define MHP_NO_FIRMWARE_MEMMAP		1
> +
>  /*
>   * Zone resizing functions
>   *
> diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
> index c01be92693e3..e94ede9cad00 100644
> --- a/mm/memory_hotplug.c
> +++ b/mm/memory_hotplug.c
> @@ -1062,7 +1062,8 @@ int __ref add_memory_resource(int nid, struct resource *res,
>  	BUG_ON(ret);
>  
>  	/* create new memmap entry */
> -	firmware_map_add_hotplug(start, start + size, "System RAM");
> +	if (!(flags & MHP_NO_FIRMWARE_MEMMAP))
> +		firmware_map_add_hotplug(start, start + size, "System RAM");
>  
>  	/* device_online() will take the lock when calling online_pages() */
>  	mem_hotplug_done();

WARNING: multiple messages have this Message-ID (diff)
From: ebiederm@xmission.com (Eric W. Biederman)
To: David Hildenbrand <david@redhat.com>
Cc: linux-kernel@vger.kernel.org,  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>
Subject: Re: [PATCH v2 2/3] mm/memory_hotplug: Introduce MHP_NO_FIRMWARE_MEMMAP
Date: Thu, 30 Apr 2020 10:38:04 -0500	[thread overview]
Message-ID: <87pnbp2dcz.fsf@x220.int.ebiederm.org> (raw)
In-Reply-To: <20200430102908.10107-3-david@redhat.com> (David Hildenbrand's message of "Thu, 30 Apr 2020 12:29:07 +0200")

David Hildenbrand <david@redhat.com> writes:

> Some devices/drivers that add memory via add_memory() and friends (e.g.,
> dax/kmem, but also virtio-mem in the future) don't want to create entries
> in /sys/firmware/memmap/ - primarily to hinder kexec from adding this
> memory to the boot memmap of the kexec kernel.
>
> In fact, such memory is never exposed via the firmware memmap as System
> RAM (e.g., e820), so exposing this memory via /sys/firmware/memmap/ is
> wrong:
>  "kexec needs the raw firmware-provided memory map to setup the
>   parameter segment of the kernel that should be booted with
>   kexec. Also, the raw memory map is useful for debugging. For
>   that reason, /sys/firmware/memmap is an interface that provides
>   the raw memory map to userspace." [1]
>
> We don't have to worry about firmware_map_remove() on the removal path.
> If there is no entry, it will simply return with -EINVAL.
>
> [1]
> https://www.kernel.org/doc/Documentation/ABI/testing/sysfs-firmware-memmap


You know what this justification is rubbish, and I have previously
explained why it is rubbish.

Nacked-by: "Eric W. Biederman" <ebiederm@xmission.com>

This needs to be based on weather the added memory is ultimately normal
ram or is something special.

At least when we are talking memory resources.  Keeping it out of the
firmware map that is fine.

If the hotplugged memory is the result of plugging a stick of ram
into the kernel and can and should used be like any other memory
it should be treated like any normal memory.

If the hotplugged memory is something special it should be treated as
something special.

Justifying behavior by documentation that does not consider memory
hotplug is bad thinking.








> Cc: Andrew Morton <akpm@linux-foundation.org>
> Cc: Michal Hocko <mhocko@suse.com>
> Cc: Pankaj Gupta <pankaj.gupta.linux@gmail.com>
> Cc: Wei Yang <richard.weiyang@gmail.com>
> Cc: Baoquan He <bhe@redhat.com>
> Cc: Eric Biederman <ebiederm@xmission.com>
> Signed-off-by: David Hildenbrand <david@redhat.com>
> ---
>  include/linux/memory_hotplug.h | 8 ++++++++
>  mm/memory_hotplug.c            | 3 ++-
>  2 files changed, 10 insertions(+), 1 deletion(-)
>
> diff --git a/include/linux/memory_hotplug.h b/include/linux/memory_hotplug.h
> index 0151fb935c09..4ca418a731eb 100644
> --- a/include/linux/memory_hotplug.h
> +++ b/include/linux/memory_hotplug.h
> @@ -68,6 +68,14 @@ struct mhp_params {
>  	pgprot_t pgprot;
>  };
>  
> +/* Flags used for add_memory() and friends. */
> +
> +/*
> + * Don't create entries in /sys/firmware/memmap/. The memory is detected and
> + * added via a device driver, not via the initial (firmware) memmap.
> + */
> +#define MHP_NO_FIRMWARE_MEMMAP		1
> +
>  /*
>   * Zone resizing functions
>   *
> diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
> index c01be92693e3..e94ede9cad00 100644
> --- a/mm/memory_hotplug.c
> +++ b/mm/memory_hotplug.c
> @@ -1062,7 +1062,8 @@ int __ref add_memory_resource(int nid, struct resource *res,
>  	BUG_ON(ret);
>  
>  	/* create new memmap entry */
> -	firmware_map_add_hotplug(start, start + size, "System RAM");
> +	if (!(flags & MHP_NO_FIRMWARE_MEMMAP))
> +		firmware_map_add_hotplug(start, start + size, "System RAM");
>  
>  	/* device_online() will take the lock when calling online_pages() */
>  	mem_hotplug_done();


WARNING: multiple messages have this Message-ID (diff)
From: ebiederm@xmission.com (Eric W. Biederman)
To: David Hildenbrand <david@redhat.com>
Cc: virtio-dev@lists.oasis-open.org, linux-hyperv@vger.kernel.org,
	Michal Hocko <mhocko@suse.com>, Baoquan He <bhe@redhat.com>,
	linux-mm@kvack.org, Wei Yang <richard.weiyang@gmail.com>,
	linux-s390@vger.kernel.org, linux-nvdimm@lists.01.org,
	linux-kernel@vger.kernel.org,
	virtualization@lists.linux-foundation.org,
	linux-acpi@vger.kernel.org,
	"Michael S . Tsirkin" <mst@redhat.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
Subject: Re: [PATCH v2 2/3] mm/memory_hotplug: Introduce MHP_NO_FIRMWARE_MEMMAP
Date: Thu, 30 Apr 2020 10:38:04 -0500	[thread overview]
Message-ID: <87pnbp2dcz.fsf@x220.int.ebiederm.org> (raw)
In-Reply-To: <20200430102908.10107-3-david@redhat.com> (David Hildenbrand's message of "Thu, 30 Apr 2020 12:29:07 +0200")

David Hildenbrand <david@redhat.com> writes:

> Some devices/drivers that add memory via add_memory() and friends (e.g.,
> dax/kmem, but also virtio-mem in the future) don't want to create entries
> in /sys/firmware/memmap/ - primarily to hinder kexec from adding this
> memory to the boot memmap of the kexec kernel.
>
> In fact, such memory is never exposed via the firmware memmap as System
> RAM (e.g., e820), so exposing this memory via /sys/firmware/memmap/ is
> wrong:
>  "kexec needs the raw firmware-provided memory map to setup the
>   parameter segment of the kernel that should be booted with
>   kexec. Also, the raw memory map is useful for debugging. For
>   that reason, /sys/firmware/memmap is an interface that provides
>   the raw memory map to userspace." [1]
>
> We don't have to worry about firmware_map_remove() on the removal path.
> If there is no entry, it will simply return with -EINVAL.
>
> [1]
> https://www.kernel.org/doc/Documentation/ABI/testing/sysfs-firmware-memmap


You know what this justification is rubbish, and I have previously
explained why it is rubbish.

Nacked-by: "Eric W. Biederman" <ebiederm@xmission.com>

This needs to be based on weather the added memory is ultimately normal
ram or is something special.

At least when we are talking memory resources.  Keeping it out of the
firmware map that is fine.

If the hotplugged memory is the result of plugging a stick of ram
into the kernel and can and should used be like any other memory
it should be treated like any normal memory.

If the hotplugged memory is something special it should be treated as
something special.

Justifying behavior by documentation that does not consider memory
hotplug is bad thinking.








> Cc: Andrew Morton <akpm@linux-foundation.org>
> Cc: Michal Hocko <mhocko@suse.com>
> Cc: Pankaj Gupta <pankaj.gupta.linux@gmail.com>
> Cc: Wei Yang <richard.weiyang@gmail.com>
> Cc: Baoquan He <bhe@redhat.com>
> Cc: Eric Biederman <ebiederm@xmission.com>
> Signed-off-by: David Hildenbrand <david@redhat.com>
> ---
>  include/linux/memory_hotplug.h | 8 ++++++++
>  mm/memory_hotplug.c            | 3 ++-
>  2 files changed, 10 insertions(+), 1 deletion(-)
>
> diff --git a/include/linux/memory_hotplug.h b/include/linux/memory_hotplug.h
> index 0151fb935c09..4ca418a731eb 100644
> --- a/include/linux/memory_hotplug.h
> +++ b/include/linux/memory_hotplug.h
> @@ -68,6 +68,14 @@ struct mhp_params {
>  	pgprot_t pgprot;
>  };
>  
> +/* Flags used for add_memory() and friends. */
> +
> +/*
> + * Don't create entries in /sys/firmware/memmap/. The memory is detected and
> + * added via a device driver, not via the initial (firmware) memmap.
> + */
> +#define MHP_NO_FIRMWARE_MEMMAP		1
> +
>  /*
>   * Zone resizing functions
>   *
> diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
> index c01be92693e3..e94ede9cad00 100644
> --- a/mm/memory_hotplug.c
> +++ b/mm/memory_hotplug.c
> @@ -1062,7 +1062,8 @@ int __ref add_memory_resource(int nid, struct resource *res,
>  	BUG_ON(ret);
>  
>  	/* create new memmap entry */
> -	firmware_map_add_hotplug(start, start + size, "System RAM");
> +	if (!(flags & MHP_NO_FIRMWARE_MEMMAP))
> +		firmware_map_add_hotplug(start, start + size, "System RAM");
>  
>  	/* device_online() will take the lock when calling online_pages() */
>  	mem_hotplug_done();

  reply	other threads:[~2020-04-30 15:41 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 [this message]
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
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=87pnbp2dcz.fsf@x220.int.ebiederm.org \
    --to=ebiederm@xmission.com \
    --cc=akpm@linux-foundation.org \
    --cc=bhe@redhat.com \
    --cc=david@redhat.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.