On 21.04.2017 14:23, Christian Borntraeger wrote: > 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. > Thanks! Sounds and looks good to me :) -- Thanks, David -- 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
