From mboxrd@z Thu Jan 1 00:00:00 1970 From: Christian Borntraeger Subject: Re: [PATCH] KVM: add kvm_arch_cpu_kick Date: Mon, 20 Feb 2017 12:12:53 +0100 Message-ID: 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> <71af37f1-c465-f2aa-ad78-ed0acf103c13@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Cc: KVM , Cornelia Huck , linux-s390 To: David Hildenbrand , Paolo Bonzini , =?UTF-8?B?UmFkaW0gS3LEjW3DocWZ?= Return-path: Received: from mx0a-001b2d01.pphosted.com ([148.163.156.1]:51427 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752195AbdBTLNB (ORCPT ); Mon, 20 Feb 2017 06:13:01 -0500 Received: from pps.filterd (m0098404.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.20/8.16.0.20) with SMTP id v1KB95I6067117 for ; Mon, 20 Feb 2017 06:13:00 -0500 Received: from e35.co.us.ibm.com (e35.co.us.ibm.com [32.97.110.153]) by mx0a-001b2d01.pphosted.com with ESMTP id 28qvby7juy-1 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=NOT) for ; Mon, 20 Feb 2017 06:13:00 -0500 Received: from localhost by e35.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Mon, 20 Feb 2017 04:12:58 -0700 In-Reply-To: <71af37f1-c465-f2aa-ad78-ed0acf103c13@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: 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