Re: [GIT PULL 4/4] KVM: s390: Support keyless subset guest mode

David Hildenbrand
2017-04-21T12:29:38Z

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