On 05.02.20 19:21, Thomas Huth wrote: > On 03/02/2020 14.19, Christian Borntraeger wrote: >> From: Janosch Frank <frankja@xxxxxxxxxxxxx> >> >> If the host initialized the Ultravisor, we can set stfle bit 161 >> (protected virtual IPL enhancements facility), which indicates, that >> the IPL subcodes 8, 9 and are valid. These subcodes are used by a >> normal guest to set/retrieve a IPIB of type 5 and transition into >> protected mode. >> >> Once in protected mode, the Ultravisor will conceal the facility >> bit. Therefore each boot into protected mode has to go through >> non-protected. There is no secure re-ipl with subcode 10 without a >> previous subcode 3. >> >> In protected mode, there is no subcode 4 available, as the VM has no >> more access to its memory from non-protected mode. I.e. each IPL >> clears. >> >> Signed-off-by: Janosch Frank <frankja@xxxxxxxxxxxxx> >> --- >> arch/s390/kvm/diag.c | 6 ++++++ >> arch/s390/kvm/kvm-s390.c | 5 +++++ >> 2 files changed, 11 insertions(+) >> >> diff --git a/arch/s390/kvm/diag.c b/arch/s390/kvm/diag.c >> index 3fb54ec2cf3e..b951dbdcb6a0 100644 >> --- a/arch/s390/kvm/diag.c >> +++ b/arch/s390/kvm/diag.c >> @@ -197,6 +197,12 @@ static int __diag_ipl_functions(struct kvm_vcpu *vcpu) >> case 4: >> vcpu->run->s390_reset_flags = 0; >> break; >> + case 8: >> + case 9: >> + case 10: >> + if (!test_kvm_facility(vcpu->kvm, 161)) >> + return kvm_s390_inject_program_int(vcpu, PGM_SPECIFICATION); >> + /* fall through */ >> default: >> return -EOPNOTSUPP; > > If we don't handle these diags in the kernel anyway, why do you care > about injecting the program interrupt from kernel space? Couldn't that > be done by userspace instead? I.e. could the whole hunk be dropped? Agreed. While this is a fast path we can certainly let QEMU handle the error cases. Will remove and add a comment to the patch description that userspace will handle the error cases.
