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. Christian -- 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
