From: Cornelia Huck <cohuck@redhat.com>
To: Collin Walling <walling@linux.ibm.com>
Cc: thuth@redhat.com, frankja@linux.ibm.com, mst@redhat.com,
david@redhat.com, qemu-devel@nongnu.org, pasic@linux.ibm.com,
borntraeger@de.ibm.com, qemu-s390x@nongnu.org,
svens@linux.ibm.com, pbonzini@redhat.com, mihajlov@linux.ibm.com,
rth@twiddle.net
Subject: Re: [PATCH v4 8/8] s390: guest support for diagnose 0x318
Date: Fri, 26 Jun 2020 12:03:08 +0200 [thread overview]
Message-ID: <20200626120308.7aae13ec.cohuck@redhat.com> (raw)
In-Reply-To: <20200624202312.28349-9-walling@linux.ibm.com>
On Wed, 24 Jun 2020 16:23:12 -0400
Collin Walling <walling@linux.ibm.com> wrote:
> DIAGNOSE 0x318 (diag318) is an s390 instruction that allows the storage
> of diagnostic information that is collected by the firmware in the case
> of hardware/firmware service events.
>
> QEMU handles the instruction by storing the info in the CPU state. A
> subsequent register sync will communicate the data to the hypervisor.
>
> QEMU handles the migration via a VM State Description.
>
> This feature depends on the Extended-Length SCCB (els) feature. If
> els is not present, then a warning will be printed and the SCLP bit
> that allows the Linux kernel to execute the instruction will not be
> set.
>
> Availability of this instruction is determined by byte 134 (aka fac134)
> bit 0 of the SCLP Read Info block. This coincidentally expands into the
> space used for CPU entries, which means VMs running with the diag318
> capability may not be able to read information regarding all CPUs
> unless the guest kernel supports an extended-length SCCB.
>
> This feature is not supported in protected virtualization mode.
>
> Signed-off-by: Collin Walling <walling@linux.ibm.com>
> Acked-by: Janosch Frank <frankja@linux.ibm.com>
> ---
> hw/s390x/sclp.c | 5 +++++
> include/hw/s390x/sclp.h | 3 +++
> target/s390x/cpu.h | 2 ++
> target/s390x/cpu_features.h | 1 +
> target/s390x/cpu_features_def.inc.h | 3 +++
> target/s390x/cpu_models.c | 1 +
> target/s390x/gen-features.c | 1 +
> target/s390x/kvm.c | 31 +++++++++++++++++++++++++++++
> target/s390x/machine.c | 17 ++++++++++++++++
> 9 files changed, 64 insertions(+)
Acked-by: Cornelia Huck <cohuck@redhat.com>
next prev parent reply other threads:[~2020-06-26 10:04 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-06-24 20:23 [PATCH v4 0/8] s390: Extended-Length SCCB & DIAGNOSE 0x318 Collin Walling
2020-06-24 20:23 ` [PATCH v4 1/8] s390/sclp: get machine once during read scp/cpu info Collin Walling
2020-06-24 20:23 ` [PATCH v4 2/8] s390/sclp: check sccb len before filling in data Collin Walling
2020-06-24 20:23 ` [PATCH v4 3/8] s390/sclp: rework sclp boundary and length checks Collin Walling
2020-06-25 6:29 ` Thomas Huth
2020-07-20 8:17 ` David Hildenbrand
2020-07-20 20:06 ` Collin Walling
2020-07-21 8:41 ` David Hildenbrand
2020-07-21 18:40 ` Collin Walling
2020-07-23 6:26 ` Cornelia Huck
2020-07-24 15:06 ` Collin Walling
2020-06-24 20:23 ` [PATCH v4 4/8] s390/sclp: read sccb from mem based on sccb length Collin Walling
2020-07-20 8:19 ` David Hildenbrand
2020-07-20 20:06 ` Collin Walling
2020-06-24 20:23 ` [PATCH v4 5/8] s390/sclp: use cpu offset to locate cpu entries Collin Walling
2020-06-24 20:23 ` [PATCH v4 6/8] s390/sclp: add extended-length sccb support for kvm guest Collin Walling
2020-06-26 10:01 ` Cornelia Huck
2020-07-15 15:35 ` Collin Walling
2020-07-15 16:05 ` Cornelia Huck
2020-06-24 20:23 ` [PATCH v4 7/8] s390/kvm: header sync for diag318 Collin Walling
2020-06-24 20:23 ` [PATCH v4 8/8] s390: guest support for diagnose 0x318 Collin Walling
2020-06-26 10:03 ` Cornelia Huck [this message]
2020-07-15 15:36 ` [PATCH v4 0/8] s390: Extended-Length SCCB & DIAGNOSE 0x318 Collin Walling
2020-07-15 16:04 ` Cornelia Huck
2020-07-15 16:26 ` Collin Walling
2020-07-16 12:02 ` Cornelia Huck
2020-09-09 7:54 ` Christian Borntraeger
2020-09-09 8:46 ` Cornelia Huck
2020-09-09 9:43 ` Cornelia Huck
2020-09-09 18:13 ` Collin Walling
2020-09-10 6:38 ` Cornelia Huck
2020-09-10 6:49 ` Collin Walling
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=20200626120308.7aae13ec.cohuck@redhat.com \
--to=cohuck@redhat.com \
--cc=borntraeger@de.ibm.com \
--cc=david@redhat.com \
--cc=frankja@linux.ibm.com \
--cc=mihajlov@linux.ibm.com \
--cc=mst@redhat.com \
--cc=pasic@linux.ibm.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=qemu-s390x@nongnu.org \
--cc=rth@twiddle.net \
--cc=svens@linux.ibm.com \
--cc=thuth@redhat.com \
--cc=walling@linux.ibm.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 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.