>> 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 that the vsie loop currently doesn't look for vcpu->requests yet. (I left it out because its just racy either way and all current requests don't require to be processes immediately - and it doesn't harm). > > 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. -- Thanks, David -- 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
