Re: [PATCH 3/3] kvm-s390: streamline memslot handling

[Christian Ehrhardt <ehrhardt@linux.vnet.ibm.com>]

Christian Ehrhardt wrote:
> Avi Kivity wrote:
>> ehrhardt@linux.vnet.ibm.com wrote:
>>> From: Christian Ehrhardt <ehrhardt@linux.vnet.ibm.com>
>>>
> [...]
>>> -    /* update sie control blocks, and unlock all vcpus */
>>> +    /* request update of sie control block for all available vcpus */
>>>      for (i = 0; i < KVM_MAX_VCPUS; ++i) {
>>>          if (kvm->vcpus[i]) {
>>> -            kvm->vcpus[i]->arch.sie_block->gmsor =
>>> -                kvm->arch.guest_origin;
>>> -            kvm->vcpus[i]->arch.sie_block->gmslm =
>>> -                kvm->arch.guest_memsize +
>>> -                kvm->arch.guest_origin +
>>> -                VIRTIODESCSPACE - 1ul;
>>> -            mutex_unlock(&kvm->vcpus[i]->mutex);
>>> +            set_bit(KVM_REQ_MMU_RELOAD, &kvm->vcpus[i]->requests);
>>> +            kvm_s390_inject_sigp_stop(kvm->vcpus[i],
>>> +                          ACTION_RELOADVCPU_ON_STOP);
>>>          }
>>>      }
>>>   
>>
>> There already exists a loop which does this, see 
>> make_all_cpus_request().  It uses an IPI (Marcelo, can't it use the 
>> reschedule interrupt?).  It has a couple of optimizations -- if the 
>> request is already set, it skips the IPI, and it avoids the IPI for 
>> vcpus out of guest mode.  Maybe it could fit s390 too.
> I assume that the IPI on x86 is a implicit consequence of the 
> smp_call_function_many function, but I think this doesn't work that 
> way for us. The kick implied by that call would be recieved, but not 
> reach the code the checke vcpu->request. I could add that behaviour, 
> but that could make our normal interrupt handling much slower. 
> Therefore I don't want to call that function, but on the other hand I 
> like the "skip if the request is already set" functionality and think 
> about adding that in my loop.
>

For now I added the optimization to skip kicking vcpus out of guest that 
had the request bit already set to the s390 specific loop (sent as v2 in 
a few minutes).

We might one day consider standardizing some generic kickout levels e.g. 
kick to "inner loop", "arch vcpu run", "generic vcpu run", "userspace", 
... whatever levels fit *all* our use cases. And then let that kicks be 
implemented in an kvm_arch_* backend as it might be very different how 
they behave on different architectures. In case an architecture cannot 
achive reaching the specified kickout level it has to kick to the next 
available upper level which eventually will reach the desired step on 
the way to re-run the vcpu.
Alltogether this should lead to a much more reliable and transparent 
interface that finally should be used all across the generic code.


-- 

Grüsse / regards, Christian Ehrhardt
IBM Linux Technology Center, Open Virtualization