This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


[Xen-devel] Re: [PATCH] xen: events: do not unmask polled ipis on restor

To: Jeremy Fitzhardinge <jeremy@xxxxxxxx>
Subject: [Xen-devel] Re: [PATCH] xen: events: do not unmask polled ipis on restore.
From: Ian Campbell <Ian.Campbell@xxxxxxxxxxxxx>
Date: Fri, 29 Oct 2010 18:52:13 +0100
Cc: "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Fri, 29 Oct 2010 10:54:49 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <4CCAF9E1.70902@xxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Organization: Citrix Systems, Inc.
References: <1288341238-3059-1-git-send-email-ian.campbell@xxxxxxxxxx> <4CCAF9E1.70902@xxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
On Fri, 2010-10-29 at 17:44 +0100, Jeremy Fitzhardinge wrote:
> On 10/29/2010 01:33 AM, Ian Campbell wrote:

> > Add a new bind function which explicitly binds a polled-only IPI and
> > track this state in the event channel core so that we can do the right
> > thing on restore.
> This doesn't seem to be the right fix though.  What if an IPI happens to
> be blocked at suspend time?

Not just IPIs but other types of IRQ too? I guess in the majority of
cases a spurious evtchn firing doesn't do any real harm. IIRC the VCPU
placement stuff (which gets redone on resume IIRC) causes all evtchns to
retrigger so we must be getting away with it pretty regularly...

> I wonder if this shouldn't be done at the irq layer, based on the desc's
> irq state?

It looks like suspend_device_irqs/resume_device_irqs takes care of the
mask/unmask element of restore for us (including unmasking irqs marked
with IRQF_NO_SUSPEND when appropriate). So we know the evtchn will be
masked on save and Xen brings us back up with all evtchns masked so all
restore_cpu_ipis needs to do is the rebinding of ipi to evtchn?


Xen-devel mailing list