<<handle_msi_irq_storm.patch>> Hi, Keir, This patch handles MSI irq storm. Unluckily, I have observed this phenomenon again. This will happen when some kind of MSI-X capable NIC is assigned to an HVM guest. The basic idea is to mask the interrupt on receiving the second interrupt and set a timer to unmask after 1ms. Can you have a look and give some comments on that? Thanks! Best Regards Shan Haitao _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
I thought that there already was storm-avoidance logic included, because of the other storm scenario you used to be able to reproduce? Also this patch looks like it will only avoid storms destined for an HVM guest. A non-HVM irq will have IRQ_INPROGRESS cleared before interrupt delivery is re-enabled. So if a storm does occur, it will look like the previous interrupt was already handled when it in fact wasn''t? In the hvm EOI function you clear IRQ_INPROGRESS but do not ->enable() the irq line. Is that correct? -- Keir On 3/7/08 06:15, "Shan, Haitao" <haitao.shan@intel.com> wrote:> <<handle_msi_irq_storm.patch>> Hi, Keir, > > This patch handles MSI irq storm. Unluckily, I have observed this > phenomenon again. This will happen when some kind of MSI-X capable NIC > is assigned to an HVM guest. The basic idea is to mask the interrupt on > receiving the second interrupt and set a timer to unmask after 1ms. > Can you have a look and give some comments on that? Thanks! > > Best Regards > Shan Haitao_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 3/7/08 09:10, "Keir Fraser" <keir.fraser@eu.citrix.com> wrote:> I thought that there already was storm-avoidance logic included, because of > the other storm scenario you used to be able to reproduce?Oh, actually, do you mean that this is still the same storm you could repro before? And we do not have avoidance logic yet because you stopped being able to repro the issue for a while? Okay if so, but still I think there are some issues to deal with in the patch. The avoidance logic for MSI delivery to a PV guest looks suspicious, as I said in my previous email -- can the patch actually avoid storm delivery to a PV guest? -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Hi, Keir, I will make updates on hvm EOI function. I don''t think that there already was storm-avoidance logic included when the final MSI/MSI-X patch sets were checked in, because at that time I could not reproduce this strange IRQ storm. And I thought I could not add such logic if everything already ran well. But unluckily enough, our QA people are experiencing this storm now. My considerations are in the following description: Level-triggered interrupts are not in the scope of IRQ storm, so I do not touch them at all. For edge-triggered interrupts, I must first be able to tell which the second interrupt is, so I must know when the first interrupt has already been handled. For HVM guest, I assume that when EOI (virtual) is written guest has finished the interrupt handling (or at least, it has started handling). But for non-HVM guest, I have not thought of a good point now. I just assume the interrupt has been services as soon as pirq is sent to guest. Do you have any suggestions on this? Shan Haitao -----Original Message----- From: Keir Fraser [mailto:keir.fraser@eu.citrix.com] Sent: 2008年7月3日 16:11 To: Shan, Haitao Cc: xen-devel@lists.xensource.com Subject: Re: [PATCH] Handle MSI irq storm I thought that there already was storm-avoidance logic included, because of the other storm scenario you used to be able to reproduce? Also this patch looks like it will only avoid storms destined for an HVM guest. A non-HVM irq will have IRQ_INPROGRESS cleared before interrupt delivery is re-enabled. So if a storm does occur, it will look like the previous interrupt was already handled when it in fact wasn''t? In the hvm EOI function you clear IRQ_INPROGRESS but do not ->enable() the irq line. Is that correct? -- Keir On 3/7/08 06:15, "Shan, Haitao" <haitao.shan@intel.com> wrote:> <<handle_msi_irq_storm.patch>> Hi, Keir, > > This patch handles MSI irq storm. Unluckily, I have observed this > phenomenon again. This will happen when some kind of MSI-X capable NIC > is assigned to an HVM guest. The basic idea is to mask the interrupt on > receiving the second interrupt and set a timer to unmask after 1ms. > Can you have a look and give some comments on that? Thanks! > > Best Regards > Shan Haitao_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Oh, I just saw this second mail from you. Yes. That''s the same irq storm as before which was left unhandled at that time. I did not see this IRQ storm to happen when this NIC is assigned to PV guests. So I guess maybe it is because PV guests tend to be more responsive than HVM guests so that there is less time window for IRQ storm? But actually the difficulty with PV guests is I have not thought of a good point to identify the end of interrupt handling, as described in my last mail. Do you have any idea on this? Thanks. Shan Haitao -----Original Message----- From: Keir Fraser [mailto:keir.fraser@eu.citrix.com] Sent: 2008年7月3日 16:18 To: Shan, Haitao Cc: xen-devel@lists.xensource.com Subject: Re: [Xen-devel] Re: [PATCH] Handle MSI irq storm On 3/7/08 09:10, "Keir Fraser" <keir.fraser@eu.citrix.com> wrote:> I thought that there already was storm-avoidance logic included, because of > the other storm scenario you used to be able to reproduce?Oh, actually, do you mean that this is still the same storm you could repro before? And we do not have avoidance logic yet because you stopped being able to repro the issue for a while? Okay if so, but still I think there are some issues to deal with in the patch. The avoidance logic for MSI delivery to a PV guest looks suspicious, as I said in my previous email -- can the patch actually avoid storm delivery to a PV guest? -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 3/7/08 09:56, "Shan, Haitao" <haitao.shan@intel.com> wrote:> For HVM guest, I assume that when EOI (virtual) is written guest has finished > the interrupt handling (or at least, it has started handling). > But for non-HVM guest, I have not thought of a good point now. I just assume > the interrupt has been services as soon as pirq is sent to guest. Do you have > any suggestions on this?Yes, you can check whether send_guest_pirq() found the event-channel-pending flag already set. If so, and the interrupt is ACKTYPE_NONE, then it''s a spurious interrupt. I would arrange the logic something like as follows: 1. Push your INPROGRESS logic inside of hvm_do_IRQ_dpci() (you''ll have to create new flag in place of using IRQ_INPROGRESS, obviously). Have hvm_do_IRQ_dpci() return one of three statuses: not handled, handled, and already pending. Don''t bother clearing the flag in the hvm eoi function. It''s not really a requirement for this scheme to work. 2. Have send_guest_pirq() return a boolean indicating whether the event-channel is already pending. 3. In __do_IRQ_guest() collate already-pending status for each iteration of the for loop. After the loop, if all receivers indicated already-pending then disable_irq(), set IRQ_INPROGRESS, set the timer, etc. Oh, allocate the irq timers outside of irq_desc (i.e., have a separate array allocated statically in irq.c). Dynamically allocating them on the interrupt path is not really very great. And remember to kill_timer() if all guest unbind from the interrupt. Does that all make sense? -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
OK. I write a new patch and send it out later. Thanks for your help! Shan Haitao -----Original Message----- From: Keir Fraser [mailto:keir.fraser@eu.citrix.com] Sent: 2008年7月3日 17:12 To: Shan, Haitao Cc: xen-devel@lists.xensource.com Subject: Re: [PATCH] Handle MSI irq storm On 3/7/08 09:56, "Shan, Haitao" <haitao.shan@intel.com> wrote:> For HVM guest, I assume that when EOI (virtual) is written guest has finished > the interrupt handling (or at least, it has started handling). > But for non-HVM guest, I have not thought of a good point now. I just assume > the interrupt has been services as soon as pirq is sent to guest. Do you have > any suggestions on this?Yes, you can check whether send_guest_pirq() found the event-channel-pending flag already set. If so, and the interrupt is ACKTYPE_NONE, then it''s a spurious interrupt. I would arrange the logic something like as follows: 1. Push your INPROGRESS logic inside of hvm_do_IRQ_dpci() (you''ll have to create new flag in place of using IRQ_INPROGRESS, obviously). Have hvm_do_IRQ_dpci() return one of three statuses: not handled, handled, and already pending. Don''t bother clearing the flag in the hvm eoi function. It''s not really a requirement for this scheme to work. 2. Have send_guest_pirq() return a boolean indicating whether the event-channel is already pending. 3. In __do_IRQ_guest() collate already-pending status for each iteration of the for loop. After the loop, if all receivers indicated already-pending then disable_irq(), set IRQ_INPROGRESS, set the timer, etc. Oh, allocate the irq timers outside of irq_desc (i.e., have a separate array allocated statically in irq.c). Dynamically allocating them on the interrupt path is not really very great. And remember to kill_timer() if all guest unbind from the interrupt. Does that all make sense? -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 3/7/08 10:11, "Keir Fraser" <keir.fraser@eu.citrix.com> wrote:> 1. Push your INPROGRESS logic inside of hvm_do_IRQ_dpci() (you''ll have to > create new flag in place of using IRQ_INPROGRESS, obviously). Have > hvm_do_IRQ_dpci() return one of three statuses: not handled, handled, and > already pending. Don''t bother clearing the flag in the hvm eoi function. > It''s not really a requirement for this scheme to work.Errm, actually it *is* a requirement to clear the flag in the eoi function. That''s the whole point of how you''ll detect spurious interrupts delivered to HVM guests. Ignore my ridiculous last sentence above. :-) -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Also please remember to add a signed-off-by line when you re-submit. -- Keir On 3/7/08 10:17, "Shan, Haitao" <haitao.shan@intel.com> wrote:> OK. I write a new patch and send it out later. > Thanks for your help! > > Shan Haitao > > -----Original Message----- > From: Keir Fraser [mailto:keir.fraser@eu.citrix.com] > Sent: 2008年7月3日 17:12 > To: Shan, Haitao > Cc: xen-devel@lists.xensource.com > Subject: Re: [PATCH] Handle MSI irq storm > > On 3/7/08 09:56, "Shan, Haitao" <haitao.shan@intel.com> wrote: > >> For HVM guest, I assume that when EOI (virtual) is written guest has finished >> the interrupt handling (or at least, it has started handling). >> But for non-HVM guest, I have not thought of a good point now. I just assume >> the interrupt has been services as soon as pirq is sent to guest. Do you have >> any suggestions on this? > > Yes, you can check whether send_guest_pirq() found the event-channel-pending > flag already set. If so, and the interrupt is ACKTYPE_NONE, then it''s a > spurious interrupt. > > I would arrange the logic something like as follows: > 1. Push your INPROGRESS logic inside of hvm_do_IRQ_dpci() (you''ll have to > create new flag in place of using IRQ_INPROGRESS, obviously). Have > hvm_do_IRQ_dpci() return one of three statuses: not handled, handled, and > already pending. Don''t bother clearing the flag in the hvm eoi function. > It''s not really a requirement for this scheme to work. > 2. Have send_guest_pirq() return a boolean indicating whether the > event-channel is already pending. > 3. In __do_IRQ_guest() collate already-pending status for each iteration of > the for loop. After the loop, if all receivers indicated already-pending > then disable_irq(), set IRQ_INPROGRESS, set the timer, etc. > > Oh, allocate the irq timers outside of irq_desc (i.e., have a separate array > allocated statically in irq.c). Dynamically allocating them on the interrupt > path is not really very great. And remember to kill_timer() if all guest > unbind from the interrupt. > > Does that all make sense? > > -- Keir > >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Hi, Keir, As I was writing the new patch, I had some other considerations. Concerning PV guests, we can depend on the event-channel-pending to decide whether we will set timer and rely on the timer to enable this vector some time later. So for HVM guest, can we also rely on the timer to enable this interrupt vector later? (so in hvm_eoi_function, we only unmark the IRQ_INPROGRESS without enable it.) Thus, the handling can be the same for both PV guests and HVM guests. How do you think of this scheme? Shan Haitao -----Original Message----- From: Keir Fraser [mailto:keir.fraser@eu.citrix.com] Sent: 2008年7月3日 17:12 To: Shan, Haitao Cc: xen-devel@lists.xensource.com Subject: Re: [PATCH] Handle MSI irq storm On 3/7/08 09:56, "Shan, Haitao" <haitao.shan@intel.com> wrote:> For HVM guest, I assume that when EOI (virtual) is written guest has finished > the interrupt handling (or at least, it has started handling). > But for non-HVM guest, I have not thought of a good point now. I just assume > the interrupt has been services as soon as pirq is sent to guest. Do you have > any suggestions on this?Yes, you can check whether send_guest_pirq() found the event-channel-pending flag already set. If so, and the interrupt is ACKTYPE_NONE, then it''s a spurious interrupt. I would arrange the logic something like as follows: 1. Push your INPROGRESS logic inside of hvm_do_IRQ_dpci() (you''ll have to create new flag in place of using IRQ_INPROGRESS, obviously). Have hvm_do_IRQ_dpci() return one of three statuses: not handled, handled, and already pending. Don''t bother clearing the flag in the hvm eoi function. It''s not really a requirement for this scheme to work. 2. Have send_guest_pirq() return a boolean indicating whether the event-channel is already pending. 3. In __do_IRQ_guest() collate already-pending status for each iteration of the for loop. After the loop, if all receivers indicated already-pending then disable_irq(), set IRQ_INPROGRESS, set the timer, etc. Oh, allocate the irq timers outside of irq_desc (i.e., have a separate array allocated statically in irq.c). Dynamically allocating them on the interrupt path is not really very great. And remember to kill_timer() if all guest unbind from the interrupt. Does that all make sense? -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 3/7/08 14:12, "Shan, Haitao" <haitao.shan@intel.com> wrote:> As I was writing the new patch, I had some other considerations. > Concerning PV guests, we can depend on the event-channel-pending to decide > whether we will set timer and rely on the timer to enable this vector some > time later. > So for HVM guest, can we also rely on the timer to enable this interrupt > vector later? (so in hvm_eoi_function, we only unmark the IRQ_INPROGRESS > without enable it.) Thus, the handling can be the same for both PV guests and > HVM guests. > How do you think of this scheme?Yes, that''s exactly what I was thinking. -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Hi, Keir, This is updated patch. Please help review it. Thanks! Best Regards Haitao Shan -----Original Message----- From: Keir Fraser [mailto:keir.fraser@eu.citrix.com] Sent: 2008年7月3日 21:18 To: Shan, Haitao Cc: xen-devel@lists.xensource.com Subject: Re: [PATCH] Handle MSI irq storm On 3/7/08 14:12, "Shan, Haitao" <haitao.shan@intel.com> wrote:> As I was writing the new patch, I had some other considerations. > Concerning PV guests, we can depend on the event-channel-pending to decide > whether we will set timer and rely on the timer to enable this vector some > time later. > So for HVM guest, can we also rely on the timer to enable this interrupt > vector later? (so in hvm_eoi_function, we only unmark the IRQ_INPROGRESS > without enable it.) Thus, the handling can be the same for both PV guests and > HVM guests. > How do you think of this scheme?Yes, that''s exactly what I was thinking. -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Please ignore my last mail. I forgot to add signed-off line. Signed-off-by: Shan Haitao <Haitao.shan@intel.com> Best Regards Haitao Shan -----Original Message----- From: xen-devel-bounces@lists.xensource.com [mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Shan, Haitao Sent: 2008年7月4日 15:22 To: Keir Fraser Cc: xen-devel@lists.xensource.com Subject: [Xen-devel] RE: [PATCH] Handle MSI irq storm Hi, Keir, This is updated patch. Please help review it. Thanks! Best Regards Haitao Shan -----Original Message----- From: Keir Fraser [mailto:keir.fraser@eu.citrix.com] Sent: 2008年7月3日 21:18 To: Shan, Haitao Cc: xen-devel@lists.xensource.com Subject: Re: [PATCH] Handle MSI irq storm On 3/7/08 14:12, "Shan, Haitao" <haitao.shan@intel.com> wrote:> As I was writing the new patch, I had some other considerations. > Concerning PV guests, we can depend on the event-channel-pending to decide > whether we will set timer and rely on the timer to enable this vector some > time later. > So for HVM guest, can we also rely on the timer to enable this interrupt > vector later? (so in hvm_eoi_function, we only unmark the IRQ_INPROGRESS > without enable it.) Thus, the handling can be the same for both PV guests and > HVM guests. > How do you think of this scheme?Yes, that''s exactly what I was thinking. -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
This changeset causes my test box to stop with:
(XEN) *** LOADING DOMAIN 0 ***
(XEN) elf_init: not an ELF binary
(XEN)
(XEN) ****************************************
(XEN) Panic on CPU 0:
(XEN) Could not set up DOM0 guest OS
(XEN) ****************************************
(XEN)
(XEN) Manual reset required (''noreboot'' specified)
I haven''t yet looked into why.
Ian.
(XEN) Xen version 3.3-unstable (ianc@localdomain) (gcc version 3.4.4 20050314
(prerelease) (Debian 3.4.3-13sarge1)) Thu Jul 10 17:56:58 BST 2008
(XEN) Latest ChangeSet: Thu Jul 10 14:20:15 2008 +0100 18019:26714991f242
(XEN) Command line: loglvl=all guest_loglvl=all dom0_max_vcpus=1 com1=115200,8n1
console=com1 noreboot dom0_mem=512M crashkernel=64M@32M
(XEN) Video information:
(XEN) VGA is text mode 80x25, font 8x16
(XEN) VBE/DDC methods: none; EDID transfer time: 2 seconds
(XEN) EDID info not retrieved because no DDC retrieval method detected
(XEN) Disc information:
(XEN) Found 1 MBR signatures
(XEN) Found 1 EDD information structures
(XEN) Xen-e820 RAM map:
(XEN) 0000000000000000 - 000000000009fc00 (usable)
(XEN) 000000000009fc00 - 00000000000a0000 (reserved)
(XEN) 00000000000e0000 - 0000000000100000 (reserved)
(XEN) 0000000000100000 - 00000000def7f000 (usable)
(XEN) 00000000def7f000 - 00000000df023000 (ACPI NVS)
(XEN) 00000000df023000 - 00000000dfdc5000 (usable)
(XEN) 00000000dfdc5000 - 00000000dfde6000 (ACPI NVS)
(XEN) 00000000dfde6000 - 00000000dfec9000 (usable)
(XEN) 00000000dfec9000 - 00000000dfee9000 (ACPI NVS)
(XEN) 00000000dfee9000 - 00000000dfeed000 (usable)
(XEN) 00000000dfeed000 - 00000000dfeff000 (ACPI data)
(XEN) 00000000dfeff000 - 00000000dff00000 (usable)
(XEN) 0000000100000000 - 0000000120000000 (usable)
(XEN) Kdump: 64MB (65536kB) at 0x2000000
(XEN) System RAM: 4093MB (4191904kB)
(XEN) ACPI: RSDP 000FE020, 0014 (r0 INTEL )
(XEN) ACPI: RSDT DFEFDE48, 004C (r1 INTEL D955XBK 7DA MSFT 1000013)
(XEN) ACPI: FACP DFEFCF10, 0074 (r1 INTEL D955XBK 7DA MSFT 1000013)
(XEN) ACPI: DSDT DFEF8010, 3D07 (r1 INTEL D955XBK 7DA MSFT 1000013)
(XEN) ACPI: FACS DFEE5C40, 0040
(XEN) ACPI: APIC DFEFCE10, 0078 (r1 INTEL D955XBK 7DA MSFT 1000013)
(XEN) ACPI: WDDT DFEF7F90, 0040 (r1 INTEL D955XBK 7DA MSFT 1000013)
(XEN) ACPI: MCFG DFEF7F10, 003C (r1 INTEL D955XBK 7DA MSFT 1000013)
(XEN) ACPI: ASF! DFEFCD10, 00A6 (r32 INTEL D955XBK 7DA MSFT 1000013)
(XEN) ACPI: SSDT DFEFDC10, 01BC (r1 INTEL CpuPm 7DA MSFT 1000013)
(XEN) ACPI: SSDT DFEFDA10, 0175 (r1 INTEL Cpu0Ist 7DA MSFT 1000013)
(XEN) ACPI: SSDT DFEFD810, 0175 (r1 INTEL Cpu1Ist 7DA MSFT 1000013)
(XEN) ACPI: SSDT DFEFD610, 0175 (r1 INTEL Cpu2Ist 7DA MSFT 1000013)
(XEN) ACPI: SSDT DFEFD410, 0175 (r1 INTEL Cpu3Ist 7DA MSFT 1000013)
(XEN) NUMA turned off
(XEN) Faking a node at 0000000000000000-0000000120000000
(XEN) Xen heap: 14MB (14412kB)
(XEN) Domain heap initialised: DMA width 32 bits
(XEN) found SMP MP-table at 000fe200
(XEN) DMI 2.3 present.
(XEN) Using APIC driver default
(XEN) ACPI: PM-Timer IO Port: 0x408
(XEN) ACPI: ACPI SLEEP INFO: pm1x_cnt[404,0], pm1x_evt[400,0]
(XEN) ACPI: wakeup_vec[dfee5c4c], vec_size[20]
(XEN) ACPI: Local APIC address 0xfee00000
(XEN) ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled)
(XEN) Processor #0 15:4 APIC version 20
(XEN) ACPI: LAPIC (acpi_id[0x02] lapic_id[0x01] enabled)
(XEN) Processor #1 15:4 APIC version 20
(XEN) ACPI: LAPIC (acpi_id[0x03] lapic_id[0x82] disabled)
(XEN) ACPI: LAPIC (acpi_id[0x04] lapic_id[0x83] disabled)
(XEN) ACPI: LAPIC_NMI (acpi_id[0x01] dfl dfl lint[0x1])
(XEN) ACPI: LAPIC_NMI (acpi_id[0x02] dfl dfl lint[0x1])
(XEN) ACPI: IOAPIC (id[0x02] address[0xfec00000] gsi_base[0])
(XEN) IOAPIC[0]: apic_id 2, version 32, address 0xfec00000, GSI 0-23
(XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
(XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
(XEN) ACPI: IRQ0 used by override.
(XEN) ACPI: IRQ2 used by override.
(XEN) ACPI: IRQ9 used by override.
(XEN) Enabling APIC mode: Flat. Using 1 I/O APICs
(XEN) Using ACPI (MADT) for SMP configuration information
(XEN) Using scheduler: SMP Credit Scheduler (credit)
(XEN) Initializing CPU#0
(XEN) Detected 3000.279 MHz processor.
(XEN) CPU: Trace cache: 12K uops, L1 D cache: 16K
(XEN) CPU: L2 cache: 1024K
(XEN) CPU: Physical Processor ID: 0
(XEN) CPU: Processor Core ID: 0
(XEN) Intel machine check architecture supported.
(XEN) Intel machine check reporting enabled on CPU#0.
(XEN) CPU0: Intel P4/Xeon Extended MCE MSRs (24) available
(XEN) CPU0: Thermal monitoring enabled
(XEN) CPU0: Intel(R) Pentium(R) D CPU 3.00GHz stepping 04
(XEN) Booting processor 1/1 eip 8c000
(XEN) Initializing CPU#1
(XEN) CPU: Trace cache: 12K uops, L1 D cache: 16K
(XEN) CPU: L2 cache: 1024K
(XEN) CPU: Physical Processor ID: 0
(XEN) CPU: Processor Core ID: 1
(XEN) Intel machine check architecture supported.
(XEN) Intel machine check reporting enabled on CPU#1.
(XEN) CPU1: Intel P4/Xeon Extended MCE MSRs (24) available
(XEN) CPU1: Thermal monitoring enabled
(XEN) CPU1: Intel(R) Pentium(R) D CPU 3.00GHz stepping 04
(XEN) Total of 2 processors activated.
(XEN) ENABLING IO-APIC IRQs
(XEN) -> Using new ACK method
(XEN) ..TIMER: vector=0xF0 apic1=0 pin1=2 apic2=-1 pin2=-1
(XEN) checking TSC synchronization across 2 CPUs: passed.
(XEN) Platform timer is 3.579MHz ACPI PM Timer
(XEN) Brought up 2 CPUs
(XEN) I/O virtualisation disabled
(XEN) ACPI sleep modes: S3
(XEN) MCA: Machine check polling timer started.
(XEN) *** LOADING DOMAIN 0 ***
(XEN) elf_init: not an ELF binary
(XEN)
(XEN) ****************************************
(XEN) Panic on CPU 0:
(XEN) Could not set up DOM0 guest OS
(XEN) ****************************************
XEN)
(XEN) Manual reset required (''noreboot'' specified)
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel