On 02/17/2017 05:23 PM, Paolo Bonzini wrote:
>
>
> On 17/02/2017 16:46, Christian Borntraeger wrote:
>> Looks good. The kick does not have to be synchronous and its ok if we
>> reenter the guest as long as we execute the request in a timely manner,
>> correct?
>>
>> e.g.
>> - kick vcpu
>> - vcpu enters SIE
>> - vcpu exits SIE immediately
>> - vcpu handles request
>> - vcpu enters SIE
>>
>> would be perfectly fine?
>
> Yes, it would. There's some parallel with QEMU's qemu_cpu_kick, where
> the signal would be processed immediately after entering KVM_RUN.
Something like
---snip-----
struct kvm_s390_sie_block *scb = READ_ONCE(vcpu->arch.vsie_block);
atomic_or(CPUSTAT_STOP_INT, &vcpu->arch.sie_block->cpuflags);
if (scb)
atomic_or(CPUSTAT_STOP_INT, &scb->cpuflags);
---snip-----
or
---snip-----
atomic_or(CPUSTAT_STOP_INT, &vcpu->arch.sie_block->cpuflags);
kvm_s390_vsie_kick(vcpu);
---snip-----
should be enough then. The code will either delete that stop request when
processing interrupts, but then the requests will be handled afterwards,
or we enter the guest once, exit and process then the requests in the next
loop iteration.
As I am on my way into the weekend this needs double checking.
--
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
