All of lore.kernel.org
 help / color / mirror / Atom feed
From: Cornelia Huck <cohuck@redhat.com>
To: Christian Borntraeger <borntraeger@de.ibm.com>
Cc: KVM <kvm@vger.kernel.org>,
	linux-s390 <linux-s390@vger.kernel.org>,
	Thomas Huth <thuth@redhat.com>,
	Halil Pasic <pasic@linux.vnet.ibm.com>,
	Janosch Frank <frankja@linux.vnet.ibm.com>
Subject: Re: [PATCH 4/4] KVM: s390: Fix skey emulation permission check
Date: Tue, 5 Dec 2017 10:51:47 +0100	[thread overview]
Message-ID: <20171205105147.7efcf684.cohuck@redhat.com> (raw)
In-Reply-To: <0657b07a-cb1c-506b-eba3-1c0c9ea1e564@de.ibm.com>

On Tue, 5 Dec 2017 10:39:26 +0100
Christian Borntraeger <borntraeger@de.ibm.com> wrote:

> On 12/05/2017 10:13 AM, Cornelia Huck wrote:

> > This reminds me of something I stumbled upon the other day:
> > 
> > handle_ri() and handle_gs() (both implemented in priv.c) don't seem to
> > have a check for PSTATE, yet they enable ri/gs before retrying the
> > instruction. Is that correct?  
> 
> The guarded storage ops (e3 49 and e3 4d) are problem state.
> Most of the ri instruction are as well, so problem state can enable RI
> interpretion.
> 
> We could do some optimization to only enable RI if the
> instruction would enable in for the guest (e.g. an inspection of the
> control block could leave RI disabled). On the other hand that would
> require to implement these instruction in KVM, which I would like
> to avoid. Right now we enable RI and re-drive the instruction.

It's probably not worth it, I think.

  reply	other threads:[~2017-12-05  9:51 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-12-05  8:33 [PATCH 0/4] KVM: s390: Fixes for 4.15 Christian Borntraeger
2017-12-05  8:33 ` [PATCH 1/4] KVM: s390: add SPDX identifiers to the remaining files Christian Borntraeger
2017-12-05  8:33 ` [PATCH 2/4] KVM: s390: Remove redundant license text Christian Borntraeger
2017-12-05 16:22   ` Paul E. McKenney
2017-12-05  8:33 ` [PATCH 3/4] KVM: s390: mark irq_state.flags as non-usable Christian Borntraeger
2017-12-05  8:33 ` [PATCH 4/4] KVM: s390: Fix skey emulation permission check Christian Borntraeger
2017-12-05  8:57   ` Thomas Huth
2017-12-05  9:13   ` Cornelia Huck
2017-12-05  9:32     ` Janosch Frank
2017-12-05  9:45       ` Cornelia Huck
2017-12-05  9:39     ` Christian Borntraeger
2017-12-05  9:51       ` Cornelia Huck [this message]
2017-12-05 16:53   ` David Hildenbrand
2017-12-05 18:19     ` Christian Borntraeger
  -- strict thread matches above, loose matches on Subject: below --
2017-12-06  8:37 [PATCH 0/4] KVM: s390: Fixes for 4.15 (via kvm/master) Christian Borntraeger
2017-12-06  8:37 ` [PATCH 4/4] KVM: s390: Fix skey emulation permission check Christian Borntraeger

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=20171205105147.7efcf684.cohuck@redhat.com \
    --to=cohuck@redhat.com \
    --cc=borntraeger@de.ibm.com \
    --cc=frankja@linux.vnet.ibm.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-s390@vger.kernel.org \
    --cc=pasic@linux.vnet.ibm.com \
    --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 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.