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] INIT ipi under Xen

To: xen-devel@xxxxxxxxxxxxxxxxxxx
Subject: [Xen-devel] INIT ipi under Xen
From: Rafal Wojtczuk <rafal@xxxxxxxxxxxxxxxxxxxxxx>
Date: Fri, 14 Jan 2011 15:54:02 +0100
Delivery-date: Fri, 14 Jan 2011 06:58:13 -0800
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
User-agent: Mutt/1.5.21 (2010-09-15)
    Does anyone know whether Xen-4.0.1, after it has booted and created dom0, 
anything special to prevent interprocessor interrupt with delivery mode INIT 
affecting processors ? Judging by Intel Software Developer Manual there is no 
documented way to do this; but maybe something less official ?

    I use the following piece of code (in hypervisor context) to trigger IPI:
unsigned long send_init_ipi()
        unsigned long ret;
        int i;
        rdmsrl(IA32_APIC_BASE, ret);
        xen_printk("IA32_APIC_BASE=0x%x\n", ret);
        if (ret & (1 << 8)) {   // I am BSP
                *(unsigned int *) (APIC_BASE + 0x300) = 0xc4500; // load ICR1 
                asm("wbinvd"); // just in case APIC_BASE is cached WB
        return ret;

This code does not seem to cause any effect (even when
IA32_APIC_BASE=0xfee00900 is logged) - namely, I can still observe both CPUs
running: subsequent triggering of this code sometimes results in
IA32_APIC_BASE=0xfee00900 logged, sometimes 0xfee00800.

If I try sending "ordinary" interrupts (by
eg writing 0x4169 do ICR1) I can see the interrupt count in /proc/cpuinfo
increase. Moreover, if I run the above code when a HVM is running, then it
is killed with note in the Xen log that unexpected exit_reason=3 (meaning,
EXIT_REASON_INIT) has beed observed. So, everything indicates that indeed
the above code generates INIT, but somehow it is ignored by the destination.
Even writing 0x84500 (send INIT to every CPU) causes no effect.

The similar code run on bare metal Linux behaves more sanely.
Can anyone offer a clue ? This is on Intel Q45 board, E8400 CPU, 64bit


Similarly, sending SIPI causes nothing; but I would expect that SIPI is
reacted upon only in wait-for-SIPI state. However, this is not documented
anywhere - can someone confirm this assumption more authoritatively ?

Xen-devel mailing list

<Prev in Thread] Current Thread [Next in Thread>