2017-02-20 12:12+0100, Christian Borntraeger: > On 02/17/2017 06:10 PM, David Hildenbrand wrote: >> >>>> 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----- >> >> I'd go for the latter one. Keep the vsie stuff isolated. Please note > > Yes makes sense. > > Radim, if you go with this patch something like this can be used as the > s390 variant of kvm_arch_cpu_kick: > > ---snip--- > /* > * The stop indication is reset in the interrupt code. As the CPU > * loop handles requests after interrupts, we will > * a: miss the request handler and enter the guest, but then the > * stop request will exit the CPU and handle the request in the next > * round or > * b: handle the request directly before entering the guest > */ > atomic_or(CPUSTAT_STOP_INT, &vcpu->arch.sie_block->cpuflags); > kvm_s390_vsie_kick(vcpu); > > ---snip--- > feel free to add that to your patch. I can also send a fixup patch later > on if you prefer that. I'll probably use it. Just looking at the hunk made me realize that the interface will need to pass the vcpu as well, so I'd be best to have the whole picture. Thanks.
