From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755585Ab2HVLUq (ORCPT ); Wed, 22 Aug 2012 07:20:46 -0400 Received: from smtp.eu.citrix.com ([62.200.22.115]:11465 "EHLO SMTP.EU.CITRIX.COM" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752563Ab2HVLUc (ORCPT ); Wed, 22 Aug 2012 07:20:32 -0400 X-IronPort-AV: E=Sophos;i="4.77,808,1336348800"; d="scan'208";a="14123572" Date: Wed, 22 Aug 2012 12:20:09 +0100 From: Stefano Stabellini X-X-Sender: sstabellini@kaball.uk.xensource.com To: Stefano Stabellini CC: Konrad Rzeszutek Wilk , "linux-kernel@vger.kernel.org" , "xen-devel@lists.xensource.com" Subject: Re: [Xen-devel] [PATCH] xen/events: fix unmask_evtchn for PV on HVM guests In-Reply-To: Message-ID: References: <1340381685-22529-1-git-send-email-stefano.stabellini@eu.citrix.com> <20120709141915.GB9580@phenom.dumpdata.com> <20120716151441.GD552@phenom.dumpdata.com> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Konrad, I cannot see this patch anywhere in your trees. Did I miss it? Or maybe it just fell through the cracks? Let me know if you want me to do anything more. Cheers, Stefano On Wed, 18 Jul 2012, Stefano Stabellini wrote: > xen/events: fix unmask_evtchn for PV on HVM guests > > When unmask_evtchn is called, if we already have an event pending, we > just set evtchn_pending_sel waiting for local_irq_enable to be called. > That is because PV guests set the irq_enable pvops to > xen_irq_enable_direct in xen_setup_vcpu_info_placement: > xen_irq_enable_direct is implemented in assembly in > arch/x86/xen/xen-asm.S and call xen_force_evtchn_callback if > XEN_vcpu_info_pending is set. > > However HVM guests (and ARM guests) do not change or do not have the > irq_enable pvop, so evtchn_unmask cannot work properly for them. > > Considering that having the pending_irq bit set when unmask_evtchn is > called is not very common, and it is simpler to keep the > native_irq_enable implementation for HVM guests (and ARM guests), the > best thing to do is just use the EVTCHNOP_unmask hypercall (Xen > re-injects pending events in response). > > Signed-off-by: Stefano Stabellini > --- > drivers/xen/events.c | 17 ++++++++++++++--- > 1 files changed, 14 insertions(+), 3 deletions(-) > > diff --git a/drivers/xen/events.c b/drivers/xen/events.c > index 0a8a17c..d75cc39 100644 > --- a/drivers/xen/events.c > +++ b/drivers/xen/events.c > @@ -373,11 +373,22 @@ static void unmask_evtchn(int port) > { > struct shared_info *s = HYPERVISOR_shared_info; > unsigned int cpu = get_cpu(); > + int do_hypercall = 0, evtchn_pending = 0; > > BUG_ON(!irqs_disabled()); > > - /* Slow path (hypercall) if this is a non-local port. */ > - if (unlikely(cpu != cpu_from_evtchn(port))) { > + if (unlikely((cpu != cpu_from_evtchn(port)))) > + do_hypercall = 1; > + else > + evtchn_pending = sync_test_bit(port, &s->evtchn_pending[0]); > + > + if (unlikely(evtchn_pending && xen_hvm_domain())) > + do_hypercall = 1; > + > + /* Slow path (hypercall) if this is a non-local port or if this is > + * an hvm domain and an event is pending (hvm domains don't have > + * their own implementation of irq_enable). */ > + if (do_hypercall) { > struct evtchn_unmask unmask = { .port = port }; > (void)HYPERVISOR_event_channel_op(EVTCHNOP_unmask, &unmask); > } else { > @@ -390,7 +401,7 @@ static void unmask_evtchn(int port) > * 'hw_resend_irq'. Just like a real IO-APIC we 'lose > * the interrupt edge' if the channel is masked. > */ > - if (sync_test_bit(port, &s->evtchn_pending[0]) && > + if (evtchn_pending && > !sync_test_and_set_bit(port / BITS_PER_LONG, > &vcpu_info->evtchn_pending_sel)) > vcpu_info->evtchn_upcall_pending = 1; > -- > 1.7.2.5 >