qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: David Hildenbrand <david@redhat.com>
To: qemu-devel@nongnu.org
Cc: Thomas Huth <thuth@redhat.com>,
	Janosch Frank <frankja@linux.ibm.com>,
	"Michael S . Tsirkin" <mst@redhat.com>,
	Heiko Carstens <hca@linux.ibm.com>,
	Cornelia Huck <cohuck@redhat.com>,
	David Hildenbrand <david@redhat.com>,
	Halil Pasic <pasic@linux.ibm.com>,
	Christian Borntraeger <borntraeger@de.ibm.com>,
	qemu-s390x@nongnu.org, Claudio Imbrenda <imbrenda@linux.ibm.com>,
	Richard Henderson <rth@twiddle.net>
Subject: [PATCH RFCv3 6/9] s390x/diag: subcode to query device memory region
Date: Fri, 24 Jul 2020 16:37:47 +0200	[thread overview]
Message-ID: <20200724143750.59836-7-david@redhat.com> (raw)
In-Reply-To: <20200724143750.59836-1-david@redhat.com>

A guest OS that is aware of memory devices (placed into the device
memory region located in guest physical address space) has to know at least
the end address of the device memory region during boot, for example, to
prepare the kernel virtual address space accordingly (e.g., select page
table hierarchy). The device memory region is located above the SCLP
maximum storage increment.

Let's provide a new diag500 subcode to query the location of the device
memory region under QEMU/KVM. This way, esp. Linux who's wants to support
virtio-based memory devices can query the location of this region and
derive the maximum possible PFN.

Let's use a specification exception in case no such memory region
exists (e.g., maxmem wasn't specified, or on old QEMU machines). We'll
unlock this with future patches that prepare and instanciate the device
memory region.

Memory managed by memory devices should never be detected and used
without having proper support for them in the guest (IOW, a driver that
detects and handles the devices). It's not exposed via other HW/firmware
interfaces (e.g., SCLP, diag260). In the near future, the focus is on
supporting virtio-based memory devices like vitio-mem. Other memory devices
are imaginable in the future (e.g., expose DIMMs via a KVM-specific
interface to s390x guests).

Note: We don't want to include the device memory region within the
SCLP-defined maximum storage increment, because especially older
guests will will sense (via tprot) accessible memory within this range.
If an unmodified guest would detect and use device memory, it could end
badly. The memory might have different semantics (e.g., a disk provided
via virtio-pmem a.k.a. DAX) and might require a handshake first (e.g.,
unplugged memory part of virtio-mem in some cases), before memory that
might look accessible can actually be used without surprises.

Signed-off-by: David Hildenbrand <david@redhat.com>
---
 hw/s390x/s390-hypercall.c | 18 ++++++++++++++++++
 hw/s390x/s390-hypercall.h |  1 +
 2 files changed, 19 insertions(+)

diff --git a/hw/s390x/s390-hypercall.c b/hw/s390x/s390-hypercall.c
index 20d4f6e159..ac21f4576e 100644
--- a/hw/s390x/s390-hypercall.c
+++ b/hw/s390x/s390-hypercall.c
@@ -11,6 +11,7 @@
 
 #include "qemu/osdep.h"
 #include "cpu.h"
+#include "hw/boards.h"
 #include "hw/s390x/s390-hypercall.h"
 #include "hw/s390x/ioinst.h"
 #include "hw/s390x/css.h"
@@ -44,6 +45,20 @@ static int handle_virtio_ccw_notify(uint64_t subch_id, uint64_t queue)
     return 0;
 }
 
+static void handle_device_memory_region(CPUS390XState *env, uintptr_t ra)
+{
+    MachineState *machine = MACHINE(qdev_get_machine());
+
+    if (!machine->device_memory ||
+        !memory_region_size(&machine->device_memory->mr)) {
+        s390_program_interrupt(env, PGM_SPECIFICATION, ra);
+        return;
+    }
+    env->regs[2] = machine->device_memory->base;
+    env->regs[3] = machine->device_memory->base +
+                   memory_region_size(&machine->device_memory->mr) - 1;
+}
+
 void handle_diag_500(CPUS390XState *env, uintptr_t ra)
 {
      const uint64_t subcode = env->regs[1];
@@ -55,6 +70,9 @@ void handle_diag_500(CPUS390XState *env, uintptr_t ra)
      case DIAG500_VIRTIO_CCW_NOTIFY:
          env->regs[2] = handle_virtio_ccw_notify(env->regs[2], env->regs[3]);
          break;
+     case DIAG500_DEVICE_MEMORY_REGION:
+        handle_device_memory_region(env, ra);
+        break;
      default:
          s390_program_interrupt(env, PGM_SPECIFICATION, ra);
      }
diff --git a/hw/s390x/s390-hypercall.h b/hw/s390x/s390-hypercall.h
index e6b958db41..1b179d7d99 100644
--- a/hw/s390x/s390-hypercall.h
+++ b/hw/s390x/s390-hypercall.h
@@ -16,6 +16,7 @@
 #define DIAG500_VIRTIO_RESET           1 /* legacy */
 #define DIAG500_VIRTIO_SET_STATUS      2 /* legacy */
 #define DIAG500_VIRTIO_CCW_NOTIFY      3 /* KVM_S390_VIRTIO_CCW_NOTIFY */
+#define DIAG500_DEVICE_MEMORY_REGION   4
 
 void handle_diag_500(CPUS390XState *env, uintptr_t ra);
 #endif /* HW_S390_HYPERCALL_H */
-- 
2.26.2



  parent reply	other threads:[~2020-07-24 14:45 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-24 14:37 [PATCH RFCv3 0/9] s390x: initial support for virtio-mem David Hildenbrand
2020-07-24 14:37 ` [PATCH RFCv3 1/9] s390x: move setting of maximum ram size to machine init David Hildenbrand
2020-07-27  9:13   ` Cornelia Huck
2020-07-24 14:37 ` [PATCH RFCv3 2/9] s390x/diag: no need to check for PGM_PRIVILEGED in diag308 David Hildenbrand
2020-07-27  9:14   ` Cornelia Huck
2020-07-24 14:37 ` [PATCH RFCv3 3/9] s390x: remove hypercall registration mechanism David Hildenbrand
2020-07-27  9:24   ` Cornelia Huck
2020-07-27  9:29     ` David Hildenbrand
2020-07-27  9:48     ` Christian Borntraeger
2020-07-24 14:37 ` [PATCH RFCv3 4/9] s390x: prepare for more diag500 hypercalls David Hildenbrand
2020-07-27  9:42   ` Cornelia Huck
2020-07-27 10:45     ` Christian Borntraeger
2020-07-24 14:37 ` [PATCH RFCv3 5/9] s390x: rename s390-virtio-hcall* to s390-hypercall* David Hildenbrand
2020-07-24 14:37 ` David Hildenbrand [this message]
2020-07-27  9:48   ` [PATCH RFCv3 6/9] s390x/diag: subcode to query device memory region Cornelia Huck
2020-07-27  9:52     ` David Hildenbrand
2020-07-27 10:09       ` Cornelia Huck
2020-07-27 10:12         ` David Hildenbrand
2020-07-27 11:15           ` Heiko Carstens
2020-07-27 12:02             ` David Hildenbrand
2020-07-28  7:10               ` Cornelia Huck
2020-07-29  8:57                 ` David Hildenbrand
2020-07-29  9:37                   ` Cornelia Huck
2020-07-29  9:57                     ` David Hildenbrand
2020-07-29 10:13                       ` Cornelia Huck
2020-07-24 14:37 ` [PATCH RFCv3 7/9] s390x: prepare device memory address space David Hildenbrand
2020-07-27  9:56   ` Cornelia Huck
2020-07-27  9:57     ` David Hildenbrand
2020-07-24 14:37 ` [PATCH RFCv3 8/9] s390x: implement virtio-mem-ccw David Hildenbrand
2020-07-27  9:58   ` Cornelia Huck
2020-07-27 10:02     ` David Hildenbrand
2020-07-27 10:11       ` Cornelia Huck
2020-07-24 14:37 ` [PATCH RFCv3 9/9] s390x: initial support for virtio-mem David Hildenbrand
2020-07-27 10:03   ` Cornelia Huck
2020-07-27 10:04     ` 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=20200724143750.59836-7-david@redhat.com \
    --to=david@redhat.com \
    --cc=borntraeger@de.ibm.com \
    --cc=cohuck@redhat.com \
    --cc=frankja@linux.ibm.com \
    --cc=hca@linux.ibm.com \
    --cc=imbrenda@linux.ibm.com \
    --cc=mst@redhat.com \
    --cc=pasic@linux.ibm.com \
    --cc=qemu-devel@nongnu.org \
    --cc=qemu-s390x@nongnu.org \
    --cc=rth@twiddle.net \
    --cc=thuth@redhat.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).