WARNING - OLD ARCHIVES

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/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] INIT ipi under Xen

To: Rafal Wojtczuk <rafal@xxxxxxxxxxxxxxxxxxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxx>
Subject: Re: [Xen-devel] INIT ipi under Xen
From: Keir Fraser <keir@xxxxxxx>
Date: Fri, 14 Jan 2011 15:53:19 +0000
Cc:
Delivery-date: Fri, 14 Jan 2011 07:55:53 -0800
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:user-agent:date:subject:from:to :message-id:thread-topic:thread-index:in-reply-to:mime-version :content-type:content-transfer-encoding; bh=lcnGjR38LC02P2DS82t/DHZTvWW6zoK5nwR0PBEUPGo=; b=LUmXx4dsZvsq/vRF8UTEYL56Ydi9MICvZbLOIozaF6tUk2XvvN6zGH0b+T1QeFoJcP GlrtNdqQunXm/PUTEKWxhNai+jU+m7HgzgkErcaJsLkdWjDLGXQYNCOcMT8VlDlUI3EH CtPhTTPEJFJPwdY2FokzELAW2I8aiz3a5yPI0=
Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:user-agent:date:subject:from:to:message-id:thread-topic :thread-index:in-reply-to:mime-version:content-type :content-transfer-encoding; b=P/+CIhNUWiJd0w9eurd2J/2fRCmTvhn70JAKBYHWkXlHV3asrteJTCpc2NiJmO+6io n87YIRrAty2QtdHjmAdii6uVK7yoq7X+I3tA/wpIc0kwUuwHYxy50uc22KnpW1JXXGoF 5xgxhyWHiOYb2OnUMbHg3BM0/E98FOwLoYhc8=
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <C9561FD3.2A295%keir@xxxxxxx>
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: Acu0Aef4uKxLpsqKDUaGY+naNt8tTgAAUHfE
Thread-topic: [Xen-devel] INIT ipi under Xen
User-agent: Microsoft-Entourage/12.28.0.101117
On 14/01/2011 15:44, "Keir Fraser" <keir@xxxxxxx> wrote:

> On 14/01/2011 14:54, "Rafal Wojtczuk" <rafal@xxxxxxxxxxxxxxxxxxxxxx> wrote:
> 
>> 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 ?
> 
> Intel SDM Vol.3B, 19.8 ("Restrictions on VMX Operation"), final bullet
> point: "The INIT signal is blocked whenever a logical processor is in VMX
> root operation."

However, it might be remembered and acted on when the CPU executes VMXOFF. I
tried a variant on your code, and as expected it had no immediate effect,
but my system hung when trying to offline CPUs for ACPI S5 (power off). I
didn't dig to confirm, but one reason could be that the secondary CPU
processes the INIT as soon as it executes VMXOFF and hence stops executing
before it has ack'ed to the rest of Xen that it is going offline. Hence Xen
would hang waiting for an ack that never comes. Just a theory.

 -- Keir

> Also, your code won't work if the APIC happens to be in x2APIC mode. You
> should write to the ICR with apic_icr_write(), which handles both xAPIC and
> x2APIC modes correctly.
> 
>  -- Keir
> 
>>     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 ?
>> 
>> 
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@xxxxxxxxxxxxxxxxxxx
>> http://lists.xensource.com/xen-devel
> 
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel

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