>>> +void kvm_s390_set_cpc(struct kvm *kvm, u64 cpc)
>>> +{
>>> + struct kvm_vcpu *vcpu;
>>> + int i;
>>> +
>>> + mutex_lock(&kvm->lock);
>>> + kvm->arch.cpnc = cpc >> 56;
>>> + kvm->arch.cpvc = cpc & 0x00ffffffffffffffUL;
>>> +
>>> + VM_EVENT(kvm, 3, "SET: CPNC: 0x%x CPVC: 0x%llx",
>>> + kvm->arch.cpnc, kvm->arch.cpvc);
>>> +
>>> + kvm_for_each_vcpu(i, vcpu, kvm) {
>>> + vcpu->arch.sie_block->cpnc = kvm->arch.cpnc;
>>> + }
>>
>> I guess the right thing to do is a synchronous all-VCPU request. Let
>> them then update it themselves when handling the request. (this can
>> effectively be called while other VCPUs are already executing)
>>
>> As an alternative, block/unblock all VCPUs, but I guess a request is the
>> easiest and cleanest way.
>>
>
> My apologies, but I found the above rather confusing. You mention a "synchronous all-VCPU
> request" that each VCPU can handle and update the cpnc? I am unfamiliar with such a request...
>
> The latter suggestion with blocking/unblocking sounds easier to implement, and is what
> other get/set functions do (TOD-Clock, crypto). Please enlighten me on the former.
The reason I dislike blocking/unblocking is the following:
blocking/unblocking really only guarantees that the target VCPU is not
currently in the SIE. But it could execute any other code (e.g.
interception handlers, until now even the vSIE), potentially reading a
value we modify from the triggering thread.
requests in return, are executed from the target VCPU directly.
In general this does not make a lot of difference, but still I consider
requests to be cleaner.
Anyhow, use what you prefer, maybe we should convert other
blocking/unblocking users one day also to use requests if it makes sense.
--
Thanks,
David / dhildenb
