From mboxrd@z Thu Jan 1 00:00:00 1970 From: Rafal Wojtczuk Subject: INIT ipi under Xen Date: Fri, 14 Jan 2011 15:54:02 +0100 Message-ID: <20110114145402.GB2683@email> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-2 Return-path: Content-Disposition: inline List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org Hello, Does anyone know whether Xen-4.0.1, after it has booted and created dom0, does anything special to prevent interprocessor interrupt with delivery mode INIT from 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 Xen-4.0.1. RW PS 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 ?