Re: [PATCH 2/2] KVM: s390: Add storage key facility interpretation control

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 27.02.2018 10:40, David Hildenbrand wrote:
> 
>>  	spin_lock_init(&kvm->arch.start_stop_lock);
>> diff --git a/arch/s390/kvm/priv.c b/arch/s390/kvm/priv.c
>> index 76a2380..d9bd147 100644
>> --- a/arch/s390/kvm/priv.c
>> +++ b/arch/s390/kvm/priv.c
>> @@ -208,19 +208,23 @@ int kvm_s390_skey_check_enable(struct kvm_vcpu *vcpu)
>>  	struct kvm_s390_sie_block *sie_block = vcpu->arch.sie_block;
>>  
>>  	trace_kvm_s390_skey_related_inst(vcpu);
>> -	if (!(sie_block->ictl & (ICTL_ISKE | ICTL_SSKE | ICTL_RRBE)) &&
>> +	/* Already enabled? */
>> +	if (vcpu->kvm->arch.use_skf &&
>> +	    !(sie_block->ictl & (ICTL_ISKE | ICTL_SSKE | ICTL_RRBE)) &&
>>  	    !kvm_s390_test_cpuflags(vcpu, CPUSTAT_KSS))
>>  		return rc;
> 
> Wonder if it is nicer to simply remember for each CPU if this function
> has already been called. This way we can avoid calling
> s390_enable_skey() in all configurations.
> 

With the benefit being, that on a per cpu storage we wouldn't have to
lock the call indication, as we are the thread of this vcpu and only we
can alter it? Which would speed up hpage and VSIE cases a tad, as the
down_write is quite heavy. We could also do a down_read, store
enablement status, up_read, if !enabled -> 390_enable_skey().

I'm also wondering, if we have a clean way after migrating a skey using
guest to disable interception right away when we get the skeys from
QEMU. I don't think we do that yet.

Attachment: signature.asc
Description: OpenPGP digital signature


[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]

  Powered by Linux