On 04/21/2017 02:15 PM, David Hildenbrand wrote: > >> diff --git a/arch/s390/kvm/vsie.c b/arch/s390/kvm/vsie.c >> index 025b1f2..4719ecb 100644 >> --- a/arch/s390/kvm/vsie.c >> +++ b/arch/s390/kvm/vsie.c >> @@ -117,6 +117,8 @@ static int prepare_cpuflags(struct kvm_vcpu *vcpu, struct vsie_page *vsie_page) >> newflags |= cpuflags & CPUSTAT_SM; >> if (test_kvm_cpu_feat(vcpu->kvm, KVM_S390_VM_CPU_FEAT_IBS)) >> newflags |= cpuflags & CPUSTAT_IBS; >> + if (test_kvm_cpu_feat(vcpu->kvm, KVM_S390_VM_CPU_FEAT_KSS)) >> + newflags |= cpuflags & CPUSTAT_KSS; >> >> atomic_set(&scb_s->cpuflags, newflags); >> return 0; >> @@ -289,7 +291,9 @@ static int shadow_scb(struct kvm_vcpu *vcpu, struct vsie_page *vsie_page) >> * bits. Therefore we cannot provide interpretation and would later >> * have to provide own emulation handlers. >> */ >> - scb_s->ictl |= ICTL_ISKE | ICTL_SSKE | ICTL_RRBE; >> + if (!(atomic_read(&scb_s->cpuflags) & CPUSTAT_KSS)) >> + scb_s->ictl |= ICTL_ISKE | ICTL_SSKE | ICTL_RRBE; >> + > What would actually happen, if ICTL_ISKE | ICTL_SSKE | ICTL_RRBE remain > set? I assume KSS will dominate? Or are there any validity interceptions > defined for this? While having the same priority, the ICTL would win in this case, which is not what we want. We would need to check for keyless in our storage key emulation and reinject a keyless intercept. By not enabling the ICTL if the nested guest runs keyless we can simply forward the keyless intercept. -- To unsubscribe from this list: send the line "unsubscribe linux-s390" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
