Re: [PATCH RFCv3 6/9] s390x/diag: subcode to query device memory region

[Cornelia Huck <cohuck@redhat.com>]

On Fri, 24 Jul 2020 16:37:47 +0200
David Hildenbrand <david@redhat.com> wrote:

> 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.

Specification exception on old machines seems reasonable. But maybe
newer machines can use a different return value for "no memory regions"?

> 
> 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.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

Regardless what we end up with, this needs to be specified
somewhere(tm).

>  
>  void handle_diag_500(CPUS390XState *env, uintptr_t ra);
>  #endif /* HW_S390_HYPERCALL_H */