linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Heiko Carstens <hca@linux.ibm.com>
To: David Hildenbrand <david@redhat.com>
Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org,
	linux-s390@vger.kernel.org, virtualization@lists.linux.dev,
	linux-doc@vger.kernel.org, kvm@vger.kernel.org,
	"Vasily Gorbik" <gor@linux.ibm.com>,
	"Alexander Gordeev" <agordeev@linux.ibm.com>,
	"Christian Borntraeger" <borntraeger@linux.ibm.com>,
	"Sven Schnelle" <svens@linux.ibm.com>,
	"Thomas Huth" <thuth@redhat.com>,
	"Cornelia Huck" <cohuck@redhat.com>,
	"Janosch Frank" <frankja@linux.ibm.com>,
	"Claudio Imbrenda" <imbrenda@linux.ibm.com>,
	"Michael S. Tsirkin" <mst@redhat.com>,
	"Jason Wang" <jasowang@redhat.com>,
	"Xuan Zhuo" <xuanzhuo@linux.alibaba.com>,
	"Eugenio Pérez" <eperezma@redhat.com>,
	"Andrew Morton" <akpm@linux-foundation.org>,
	"Jonathan Corbet" <corbet@lwn.net>,
	"Mario Casquero" <mcasquer@redhat.com>
Subject: Re: [PATCH v2 4/7] s390/physmem_info: query diag500(STORAGE LIMIT) to support QEMU/KVM memory devices
Date: Mon, 14 Oct 2024 20:43:39 +0200	[thread overview]
Message-ID: <20241014184339.10447-E-hca@linux.ibm.com> (raw)
In-Reply-To: <20241014144622.876731-5-david@redhat.com>

On Mon, Oct 14, 2024 at 04:46:16PM +0200, David Hildenbrand wrote:
> To support memory devices under QEMU/KVM, such as virtio-mem,
> we have to prepare our kernel virtual address space accordingly and
> have to know the highest possible physical memory address we might see
> later: the storage limit. The good old SCLP interface is not suitable for
> this use case.
> 
> In particular, memory owned by memory devices has no relationship to
> storage increments, it is always detected using the device driver, and
> unaware OSes (no driver) must never try making use of that memory.
> Consequently this memory is located outside of the "maximum storage
> increment"-indicated memory range.
> 
> Let's use our new diag500 STORAGE_LIMIT subcode to query this storage
> limit that can exceed the "maximum storage increment", and use the
> existing interfaces (i.e., SCLP) to obtain information about the initial
> memory that is not owned+managed by memory devices.
> 
> If a hypervisor does not support such memory devices, the address exposed
> through diag500 STORAGE_LIMIT will correspond to the maximum storage
> increment exposed through SCLP.
> 
> To teach kdump on s390 to include memory owned by memory devices, there
> will be ways to query the relevant memory ranges from the device via a
> driver running in special kdump mode (like virtio-mem already implements
> to filter /proc/vmcore access so we don't end up reading from unplugged
> device blocks).
> 
> Tested-by: Mario Casquero <mcasquer@redhat.com>
> Signed-off-by: David Hildenbrand <david@redhat.com>
> ---
>  arch/s390/boot/physmem_info.c        | 46 ++++++++++++++++++++++++++--
>  arch/s390/include/asm/physmem_info.h |  3 ++
>  2 files changed, 46 insertions(+), 3 deletions(-)

...

> +static int diag500_storage_limit(unsigned long *max_physmem_end)
> +{
> +	register unsigned long __nr asm("1") = 0x4;
> +	register unsigned long __storage_limit asm("2") = 0;
> +	unsigned long reg1, reg2;
> +	psw_t old;

In general we do not allow register asm usage anymore in s390 code,
except for a very few defined places. This is due to all the problems
that we've seen with code instrumentation and register corruption.

The patch below changes your code accordingly, but it is
untested. Please verify that your code still works.

> @@ -157,7 +189,9 @@ unsigned long detect_max_physmem_end(void)
>  {
>  	unsigned long max_physmem_end = 0;
>  
> -	if (!sclp_early_get_memsize(&max_physmem_end)) {
> +	if (!diag500_storage_limit(&max_physmem_end)) {
> +		physmem_info.info_source = MEM_DETECT_DIAG500_STOR_LIMIT;
> +	} else if (!sclp_early_get_memsize(&max_physmem_end)) {
>  		physmem_info.info_source = MEM_DETECT_SCLP_READ_INFO;
>  	} else {
>  		max_physmem_end = search_mem_end();
> @@ -170,11 +204,17 @@ void detect_physmem_online_ranges(unsigned long max_physmem_end)
>  {
>  	if (!sclp_early_read_storage_info()) {
>  		physmem_info.info_source = MEM_DETECT_SCLP_STOR_INFO;
> +		return;
>  	} else if (!diag260()) {
>  		physmem_info.info_source = MEM_DETECT_DIAG260;
> -	} else if (max_physmem_end) {
> -		add_physmem_online_range(0, max_physmem_end);
> +		return;
> +	} else if (physmem_info.info_source == MEM_DETECT_DIAG500_STOR_LIMIT) {
> +		max_physmem_end = 0;
> +		if (!sclp_early_get_memsize(&max_physmem_end))
> +			physmem_info.info_source = MEM_DETECT_SCLP_READ_INFO;
>  	}
> +	if (max_physmem_end)
> +		add_physmem_online_range(0, max_physmem_end);
>  }

In general looks good to me, but I'd like to see that Vasily or
Alexander give an Ack to this patch.

diff --git a/arch/s390/boot/physmem_info.c b/arch/s390/boot/physmem_info.c
index fb4e66e80fd8..975fc478e0e3 100644
--- a/arch/s390/boot/physmem_info.c
+++ b/arch/s390/boot/physmem_info.c
@@ -109,10 +109,11 @@ static int diag260(void)
 	return 0;
 }
 
+#define DIAG500_SC_STOR_LIMIT 4
+
 static int diag500_storage_limit(unsigned long *max_physmem_end)
 {
-	register unsigned long __nr asm("1") = 0x4;
-	register unsigned long __storage_limit asm("2") = 0;
+	unsigned long storage_limit;
 	unsigned long reg1, reg2;
 	psw_t old;
 
@@ -123,21 +124,24 @@ static int diag500_storage_limit(unsigned long *max_physmem_end)
 		"	st	%[reg2],4(%[psw_pgm])\n"
 		"	larl	%[reg1],1f\n"
 		"	stg	%[reg1],8(%[psw_pgm])\n"
+		"	lghi	1,%[subcode]\n"
+		"	lghi	2,0\n"
 		"	diag	2,4,0x500\n"
 		"1:	mvc	0(16,%[psw_pgm]),0(%[psw_old])\n"
+		"	lgr	%[slimit],2\n"
 		: [reg1] "=&d" (reg1),
 		  [reg2] "=&a" (reg2),
-		  "+&d" (__storage_limit),
+		  [slimit] "=d" (storage_limit),
 		  "=Q" (get_lowcore()->program_new_psw),
 		  "=Q" (old)
 		: [psw_old] "a" (&old),
 		  [psw_pgm] "a" (&get_lowcore()->program_new_psw),
-		  "d" (__nr)
-		: "memory");
-	if (!__storage_limit)
-	        return -EINVAL;
-	/* convert inclusive end to exclusive end. */
-	*max_physmem_end = __storage_limit + 1;
+		  [subcode] "i" (DIAG500_SC_STOR_LIMIT)
+		: "memory", "1", "2");
+	if (!storage_limit)
+		return -EINVAL;
+	/* Convert inclusive end to exclusive end */
+	*max_physmem_end = storage_limit + 1;
 	return 0;
 }
 


  reply	other threads:[~2024-10-14 18:43 UTC|newest]

Thread overview: 59+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-10-14 14:46 [PATCH v2 0/7] virtio-mem: s390 support David Hildenbrand
2024-10-14 14:46 ` [PATCH v2 1/7] s390/kdump: implement is_kdump_kernel() David Hildenbrand
2024-10-14 18:20   ` Heiko Carstens
2024-10-14 19:26     ` David Hildenbrand
2024-10-15  8:30       ` Heiko Carstens
2024-10-15  8:41         ` David Hildenbrand
2024-10-15  8:53           ` David Hildenbrand
2024-10-15  8:56             ` David Hildenbrand
2024-10-15 10:08           ` Heiko Carstens
2024-10-15 10:40             ` David Hildenbrand
2024-10-16 13:35               ` Alexander Egorenkov
2024-10-16 15:47                 ` David Hildenbrand
2024-10-16 15:54                   ` David Hildenbrand
2024-10-21 12:46                   ` Alexander Egorenkov
2024-10-21 14:45                     ` David Hildenbrand
2024-10-23  7:42                       ` Heiko Carstens
2024-10-23  7:45                         ` David Hildenbrand
2024-10-23 11:17                       ` Alexander Egorenkov
2024-10-14 14:46 ` [PATCH v2 2/7] Documentation: s390-diag.rst: make diag500 a generic KVM hypercall David Hildenbrand
2024-10-14 18:04   ` Heiko Carstens
2024-10-14 19:35     ` David Hildenbrand
2024-10-15  8:12       ` Heiko Carstens
2024-10-15  8:16         ` David Hildenbrand
2024-10-15  8:21           ` Heiko Carstens
2024-10-15  8:32             ` David Hildenbrand
2024-10-15  8:46               ` Heiko Carstens
2024-10-15  8:48                 ` David Hildenbrand
2024-10-14 14:46 ` [PATCH v2 3/7] Documentation: s390-diag.rst: document diag500(STORAGE LIMIT) subfunction David Hildenbrand
2024-10-14 14:46 ` [PATCH v2 4/7] s390/physmem_info: query diag500(STORAGE LIMIT) to support QEMU/KVM memory devices David Hildenbrand
2024-10-14 18:43   ` Heiko Carstens [this message]
2024-10-14 19:42     ` David Hildenbrand
2024-10-15 15:01     ` Eric Farman
2024-10-15 15:20       ` Heiko Carstens
2024-10-25 10:52         ` David Hildenbrand
2024-10-16 10:37       ` Halil Pasic
2024-10-17  7:36   ` Alexander Gordeev
2024-10-17  8:19     ` David Hildenbrand
2024-10-17  9:53       ` Alexander Gordeev
2024-10-17 10:00         ` David Hildenbrand
2024-10-17 12:07           ` David Hildenbrand
2024-10-17 14:32             ` Alexander Gordeev
2024-10-17 14:36               ` David Hildenbrand
2024-10-30 14:30   ` Alexander Gordeev
2024-10-30 14:33     ` Alexander Gordeev
2024-10-14 14:46 ` [PATCH v2 5/7] virtio-mem: s390 support David Hildenbrand
2024-10-14 18:48   ` Heiko Carstens
2024-10-14 19:16     ` David Hildenbrand
2024-10-15  8:37       ` Heiko Carstens
2024-10-21  6:33         ` Christian Borntraeger
2024-10-21 12:19           ` David Hildenbrand
2024-10-14 14:46 ` [PATCH v2 6/7] lib/Kconfig.debug: default STRICT_DEVMEM to "y" on s390 David Hildenbrand
2024-10-14 18:53   ` Heiko Carstens
2024-10-14 14:46 ` [PATCH v2 7/7] s390/sparsemem: reduce section size to 128 MiB David Hildenbrand
2024-10-14 17:53   ` Heiko Carstens
2024-10-14 19:47     ` David Hildenbrand
2024-10-14 18:56 ` [PATCH v2 0/7] virtio-mem: s390 support Heiko Carstens
2024-10-14 19:17   ` David Hildenbrand
2024-10-15  7:57   ` Claudio Imbrenda
2024-10-25 10:54     ` 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=20241014184339.10447-E-hca@linux.ibm.com \
    --to=hca@linux.ibm.com \
    --cc=agordeev@linux.ibm.com \
    --cc=akpm@linux-foundation.org \
    --cc=borntraeger@linux.ibm.com \
    --cc=cohuck@redhat.com \
    --cc=corbet@lwn.net \
    --cc=david@redhat.com \
    --cc=eperezma@redhat.com \
    --cc=frankja@linux.ibm.com \
    --cc=gor@linux.ibm.com \
    --cc=imbrenda@linux.ibm.com \
    --cc=jasowang@redhat.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linux-s390@vger.kernel.org \
    --cc=mcasquer@redhat.com \
    --cc=mst@redhat.com \
    --cc=svens@linux.ibm.com \
    --cc=thuth@redhat.com \
    --cc=virtualization@lists.linux.dev \
    --cc=xuanzhuo@linux.alibaba.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).