From mboxrd@z Thu Jan 1 00:00:00 1970 From: Scott Wood Date: Mon, 09 Jan 2012 20:00:36 +0000 Subject: Re: [PATCH v2 2/3] KVM: PPC: epapr: Add idle hcall support for host Message-Id: <4F0B4764.6070801@freescale.com> List-Id: References: <1325754448-30055-1-git-send-email-yu.liu@freescale.com> <9974D2A0-C91D-442E-8972-529E24418A28@suse.de> In-Reply-To: <9974D2A0-C91D-442E-8972-529E24418A28@suse.de> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: Alexander Graf Cc: Liu Yu , kvm-ppc@vger.kernel.org, kvm@vger.kernel.org, galak@kernel.crashing.org, timur@freescale.com, Stuart Yoder On 01/09/2012 08:15 AM, Alexander Graf wrote: > > On 05.01.2012, at 10:07, Liu Yu wrote: > >> diff --git a/arch/powerpc/kvm/powerpc.c b/arch/powerpc/kvm/powerpc.c >> index c33f6a7..1242ee1 100644 >> --- a/arch/powerpc/kvm/powerpc.c >> +++ b/arch/powerpc/kvm/powerpc.c >> @@ -81,6 +81,10 @@ int kvmppc_kvm_pv(struct kvm_vcpu *vcpu) >> >> /* Second return value is in r4 */ >> break; >> + case HC_VENDOR_EPAPR | HC_EV_IDLE: >> + r = HC_EV_SUCCESS; >> + kvm_vcpu_block(vcpu); > > Hrm. This will return on signal. So if the guest sends an idle hcall, > then user space gets a random signal, we'll continue executing the > guest CPU, getting us out of idle even though the guest didn't expect > it, since the guest really wants to get an interrupt after the idle > hcall. The ePAPR description of this hcall is a little vague (Stuart, put on list to fix in next ePAPR revision?), but this is expected. It will also be the case if a guest directly uses the wait instruction. Guests must be able to deal with spurious wakeups. -Scott From mboxrd@z Thu Jan 1 00:00:00 1970 From: Scott Wood Subject: Re: [PATCH v2 2/3] KVM: PPC: epapr: Add idle hcall support for host Date: Mon, 9 Jan 2012 14:00:36 -0600 Message-ID: <4F0B4764.6070801@freescale.com> References: <1325754448-30055-1-git-send-email-yu.liu@freescale.com> <9974D2A0-C91D-442E-8972-529E24418A28@suse.de> Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Cc: Liu Yu , , , , , Stuart Yoder To: Alexander Graf Return-path: In-Reply-To: <9974D2A0-C91D-442E-8972-529E24418A28@suse.de> Sender: kvm-ppc-owner@vger.kernel.org List-Id: kvm.vger.kernel.org On 01/09/2012 08:15 AM, Alexander Graf wrote: > > On 05.01.2012, at 10:07, Liu Yu wrote: > >> diff --git a/arch/powerpc/kvm/powerpc.c b/arch/powerpc/kvm/powerpc.c >> index c33f6a7..1242ee1 100644 >> --- a/arch/powerpc/kvm/powerpc.c >> +++ b/arch/powerpc/kvm/powerpc.c >> @@ -81,6 +81,10 @@ int kvmppc_kvm_pv(struct kvm_vcpu *vcpu) >> >> /* Second return value is in r4 */ >> break; >> + case HC_VENDOR_EPAPR | HC_EV_IDLE: >> + r = HC_EV_SUCCESS; >> + kvm_vcpu_block(vcpu); > > Hrm. This will return on signal. So if the guest sends an idle hcall, > then user space gets a random signal, we'll continue executing the > guest CPU, getting us out of idle even though the guest didn't expect > it, since the guest really wants to get an interrupt after the idle > hcall. The ePAPR description of this hcall is a little vague (Stuart, put on list to fix in next ePAPR revision?), but this is expected. It will also be the case if a guest directly uses the wait instruction. Guests must be able to deal with spurious wakeups. -Scott