RE: [Xen-ia64-devel] [Xen-devel] [PATCH]Make VTIdomain boot again

["Xu, Anthony" <anthony.xu@xxxxxxxxx>]

Williamson,

This patch is just a workaround, the essential cause is, the soft_IRQ should be 
done at the path of ia64_leave_kernel which aligned with native linux and 
XEN/X86, instead of being invoking in irq_exit function.

What's your opinion?

Thanks,
-Anthony 

>-----Original Message-----
>From: Alex Williamson [mailto:alex.williamson@xxxxxx]
>Sent: 2006年2月9日 11:32
>To: Xu, Anthony
>Cc: xen-devel@xxxxxxxxxxxxxxxxxxx; xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
>Subject: Re: [Xen-ia64-devel] [Xen-devel] [PATCH]Make VTIdomain boot again
>
>On Thu, 2006-02-09 at 10:31 +0800, Xu, Anthony wrote:
>> Keir,
>>
>> This patch is intended to make VTIdomain boot again, and will not impact
>> domU. Actually VTIdomain and domU can boot simultaneously after applying
>> this patch, Could you please check this patch into xen-unstable.hg? This
>> is a must in 3.0.1.
>
>Hi Anthony,
>
>   Xen 3.0.1 went out on Feb. 1st.  A couple comments
>
>--- a/xen/arch/ia64/linux-xen/irq_ia64.c        Thu Jan 26 10:31:28 2006
>+++ b/xen/arch/ia64/linux-xen/irq_ia64.c        Wed Feb  8 16:28:11 2006
>@@ -169,7 +169,7 @@
>         * handler needs to be able to wait for further keyboard
>interrupts, which can't
>         * come through until ia64_eoi() has been done.
>         */
>-       irq_exit();
>+       xen_irq_exit(regs);
> }
>
>>>> This needs to be in an #ifdef XEN.
>
>-void irq_exit(void)
>+void xen_irq_exit(struct pt_regs *regs)
> {
>        //account_system_vtime(current);
>        sub_preempt_count(IRQ_EXIT_OFFSET);
>-       if (!in_interrupt() && local_softirq_pending()) {
>+    if((((char *)regs) -(char *) current) !=
>(IA64_STK_OFFSET-IA64_PT_REGS_SIZE))
>+        return;
>+
>+       if (!in_interrupt()&&local_softirq_pending()) {
>
>>>> Formatting here is inconsistent with the rest of the file and
>itself.  Could we be setting some flag and adding the test to the
>existing in_interrupt/local_softirq_pending check?  This looks rather
>precarious.  Thanks,
>
>       Alex

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