From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Hildenbrand Subject: Re: [PATCH] KVM: add kvm_arch_cpu_kick Date: Fri, 17 Feb 2017 18:10:12 +0100 Message-ID: <71af37f1-c465-f2aa-ad78-ed0acf103c13@redhat.com> References: <1487337007-91063-1-git-send-email-borntraeger@de.ibm.com> <1487337007-91063-2-git-send-email-borntraeger@de.ibm.com> <20170217151227.GA27770@potion> <6f3d1415-b337-ecff-e56a-02017ea44658@de.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <6f3d1415-b337-ecff-e56a-02017ea44658@de.ibm.com> Sender: kvm-owner@vger.kernel.org List-Archive: List-Post: To: Christian Borntraeger , Paolo Bonzini , =?UTF-8?B?UmFkaW0gS3LEjW3DocWZ?= Cc: KVM , Cornelia Huck , linux-s390 List-ID: >> 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