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] a possible chance to lost pending interrupt in latest pv tip

To: "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>, Ian Campbell <Ian.Campbell@xxxxxxxxxx>, "jeremy@xxxxxxxx" <jeremy@xxxxxxxx>
Subject: [Xen-devel] a possible chance to lost pending interrupt in latest pv tip
From: "Tian, Kevin" <kevin.tian@xxxxxxxxx>
Date: Thu, 5 May 2011 15:15:29 +0800
Accept-language: en-US
Acceptlanguage: en-US
Delivery-date: Thu, 05 May 2011 00:19:42 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
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>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcwK9CP6nG7XtcvcQ8aAYMRMaXQm+g==
Thread-topic: a possible chance to lost pending interrupt in latest pv tip
Just found that enable_irq/mdelay/disable_irq has been removed from fixup_irqs
in latest tip, which is the key path to migrate irqs to other cpus when current 
is being hot removed. The new logic tries to poll local APIC IRR for pending 
interrupt check, which is not desired to Xen. My gut-feeling is that we'll lose
pending events on local vcpu since apic_read is a dummy ops. Or do I overlook 

commit 5231a68614b94f60e8f6c56bc6e3d75955b9e75e
Author: Suresh Siddha <suresh.b.siddha@xxxxxxxxx>
Date:   Mon Oct 26 14:24:36 2009 -0800

    x86: Remove local_irq_enable()/local_irq_disable() in fixup_irqs()
    To ensure that we handle all the pending interrupts (destined
    for this cpu that is going down) in the interrupt subsystem
    before the cpu goes offline, fixup_irqs() does:
    Enabling interrupts is not a good thing as this cpu is already
    offline. So this patch replaces that logic with,
        check APIC_IRR bits
        Retrigger the irq at the new destination if any interrupt has arrived
        via IPI.
    For IO-APIC level triggered interrupts, this retrigger IPI will
    appear as an edge interrupt. ack_apic_level() will detect this
    condition and IO-APIC RTE's remoteIRR is cleared using directed
    EOI(using IO-APIC EOI register) on Intel platforms and for
    others it uses the existing mask+edge logic followed by
    We can also remove mdelay() and then send spuriuous interrupts
    to new cpu targets for all the irqs that were handled previously
    by this cpu that is going offline. While it works, I have seen
    spurious interrupt messages (nothing wrong but still annoying
    messages during cpu offline, which can be seen during
    suspend/resume etc)

    Signed-off-by: Suresh Siddha <suresh.b.siddha@xxxxxxxxx>
    Acked-by: Gary Hade <garyhade@xxxxxxxxxx>
    Cc: Eric W. Biederman <ebiederm@xxxxxxxxxxxx>
    LKML-Reference: <20091026230002.043281924@xxxxxxxxxxxxxxxxxxxx>
    Signed-off-by: Ingo Molnar <mingo@xxxxxxx>

Xen-devel mailing list

<Prev in Thread] Current Thread [Next in Thread>
  • [Xen-devel] a possible chance to lost pending interrupt in latest pv tip, Tian, Kevin <=