On 08/14/2018 04:50 AM, Cornelia Huck wrote:
On Mon, 13 Aug 2018 17:48:02 -0400
Tony Krowiak <akrowiak@xxxxxxxxxxxxxxxxxx> wrote:
From: David Hildenbrand <david@xxxxxxxxxx>
VCPU requests and VCPU blocking right now don't take care of the vSIE
(as it was not necessary until now). But we want to have VCPU requests
that will also be handled before running the vSIE again.
So let's simulate a SIE entry when entering the vSIE loop and check
for PROG_ flags. The existing infrastructure (e.g. exit_sie()) will then
detect that the SIE (in form of the vSIE execution loop) is running and
properly kick the vSIE CPU, resulting in it leaving the vSIE loop and
therefore the vSIE interception handler, allowing it to handle VCPU
requests.
E.g. if we want to modify the crycb of the VCPU and make sure that any
masks also get applied to the VSIE crycb shadow (which uses masks from the
VCPU crycb), we will need a way to hinder the vSIE from running and make
sure to process the updated crycb before reentering the vSIE again.
Signed-off-by: David Hildenbrand <david@xxxxxxxxxx>
Signed-off-by: Tony Krowiak <akrowiak@xxxxxxxxxxxxx>
Reviewed-by: Pierre Morel <pmorel@xxxxxxxxxxxxx>
---
arch/s390/kvm/kvm-s390.c | 9 ++++++++-
arch/s390/kvm/kvm-s390.h | 1 +
arch/s390/kvm/vsie.c | 20 ++++++++++++++++++--
3 files changed, 27 insertions(+), 3 deletions(-)
I think that is the RFC version of David's patch, not the v1? Again,
not really relevant for reviewing, but I hope that you test the final
version.
Will do.
