| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
[Xen-devel] Re: [PATCH] xen: events: do not unmask polled ipis on restor
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?
Ian.
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
| |
|
Home