qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Janosch Frank <frankja@linux.ibm.com>
To: David Hildenbrand <david@redhat.com>, qemu-devel@nongnu.org
Cc: thuth@redhat.com, cohuck@redhat.com, walling@linux.ibm.com,
	pasic@linux.ibm.com, borntraeger@de.ibm.com,
	qemu-s390x@nongnu.org, mhartmay@linux.ibm.com
Subject: Re: [PATCH 2/2] s390x: pv: Fix diag318 PV fencing
Date: Wed, 21 Oct 2020 16:19:19 +0200	[thread overview]
Message-ID: <ea3dcaba-8d3a-958f-7c6b-f340187f7ba5@linux.ibm.com> (raw)
In-Reply-To: <fa050bc9-db4e-8800-d7d5-a2931bebce78@redhat.com>


[-- Attachment #1.1: Type: text/plain, Size: 2148 bytes --]

On 10/21/20 4:14 PM, David Hildenbrand wrote:
> On 21.10.20 15:43, Janosch Frank wrote:
>> Diag318 fencing needs to be determined on the current VM PV state and
>> not on the state that the VM has when we create the CPU model.
>>
>> Signed-off-by: Janosch Frank <frankja@linux.ibm.com>
>> Reported-by: Marc Hartmayer <mhartmay@linux.ibm.com>
>> Reviewed-by: Christian Borntraeger <borntraeger@de.ibm.com>
>> Fixes: fabdada935 ("s390: guest support for diagnose 0x318")
>> Tested-by: Marc Hartmayer <mhartmay@linux.ibm.com>
>> ---
>>  hw/s390x/sclp.c    | 10 ++++++++++
>>  target/s390x/kvm.c |  3 +--
>>  2 files changed, 11 insertions(+), 2 deletions(-)
>>
>> diff --git a/hw/s390x/sclp.c b/hw/s390x/sclp.c
>> index 0cf2290826..69aba402d3 100644
>> --- a/hw/s390x/sclp.c
>> +++ b/hw/s390x/sclp.c
>> @@ -22,6 +22,7 @@
>>  #include "hw/s390x/event-facility.h"
>>  #include "hw/s390x/s390-pci-bus.h"
>>  #include "hw/s390x/ipl.h"
>> +#include "hw/s390x/pv.h"
>>  
>>  static inline SCLPDevice *get_sclp_device(void)
>>  {
>> @@ -142,6 +143,15 @@ static void read_SCP_info(SCLPDevice *sclp, SCCB *sccb)
>>      if (s390_has_feat(S390_FEAT_EXTENDED_LENGTH_SCCB)) {
>>          s390_get_feat_block(S390_FEAT_TYPE_SCLP_FAC134,
>>                              &read_info->fac134);
>> +        /*
>> +         * Diag318 is not available in protected mode and will result
>> +         * in an operation exception. As we can dynamically move in
>> +         * and out of protected mode, we need to fence the feature
>> +         * here rather than when creating the CPU model.
>> +         */
>> +        if (s390_is_pv()) {
>> +            read_info->fac134 &= ~0x80;
>> +        }
> 
> Hmm, I thought firmware would handle exposing cpu features and similar,
> so we can't temper with it ....

STFLE data is indeed provided by the Ultravisor, but SCLP is still done
by QEMU as that data is often not machine specific as visible in this case

> 
> Can we move that into s390_get_feat_block instead and check against the
> feature bit instead?
> 
You mean fence inside the s390_get_feat_block() function?


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

  parent reply	other threads:[~2020-10-21 14:21 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-10-21 13:43 [PATCH 0/2] s390x: pv: Diag318 fixes Janosch Frank
2020-10-21 13:43 ` [PATCH 1/2] s390x: pv: Remove sclp boundary checks Janosch Frank
2020-10-21 14:12   ` David Hildenbrand
2020-10-21 15:48   ` Halil Pasic
2020-10-22  8:26   ` Thomas Huth
2020-10-21 13:43 ` [PATCH 2/2] s390x: pv: Fix diag318 PV fencing Janosch Frank
2020-10-21 14:14   ` David Hildenbrand
2020-10-21 14:18     ` Christian Borntraeger
2020-10-21 14:29       ` David Hildenbrand
2020-10-21 14:19     ` Janosch Frank [this message]
2020-10-21 14:21       ` David Hildenbrand
2020-10-22  8:23         ` [PATCH] " Janosch Frank
2020-10-22  8:32           ` David Hildenbrand
2020-10-22  8:39             ` Janosch Frank
2020-10-22  8:47               ` David Hildenbrand
2020-10-22  9:54           ` Halil Pasic
2020-10-22  9:55             ` 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=ea3dcaba-8d3a-958f-7c6b-f340187f7ba5@linux.ibm.com \
    --to=frankja@linux.ibm.com \
    --cc=borntraeger@de.ibm.com \
    --cc=cohuck@redhat.com \
    --cc=david@redhat.com \
    --cc=mhartmay@linux.ibm.com \
    --cc=pasic@linux.ibm.com \
    --cc=qemu-devel@nongnu.org \
    --cc=qemu-s390x@nongnu.org \
    --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 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).