Re: [Xen-ia64-devel] [Patch] Remove panic_domain()

2007-03-27 Thread Akio Takebe
Hi, Alex

On Fri, 2007-03-23 at 15:00 +0900, Akio Takebe wrote:
 Hi,
 
 I found the bug of panic_domain().
 When we compile xen with crash_debug=y, debugger_trap_immediate() and 
 debugger_trap_fatal() is not nop.
 So if xen call panic_domain() to crash guest,
 xen call debugger routine, then hangup system.
 
 domain_crash_synchronous() has __FILE__, __LINE__ macros.
 So I remove panic_domain() and replace it with printk() and
 domain_crash_synchronous() as x86 do.

   Wouldn't it work just as well to convert panic_domain() to a macro
and remove the debugger_trap_immediate() and debugger_trap_fatal()
calls?  The abstraction of panic_domain() is easier to use than
requiring someone to call all the relevant functions manually.  Thanks,

Yes, I used also show_registers() if panic_domain has regs arguments.
(e.g. the following part.)

diff -r 2216a45bf058 xen/arch/ia64/vmx/vlsapic.c
--- a/xen/arch/ia64/vmx/vlsapic.c   Tue Mar 20 15:19:38 2007 -0600
+++ b/xen/arch/ia64/vmx/vlsapic.c   Fri Mar 23 14:41:48 2007 +0900
@@ -480,8 +480,11 @@ int vmx_check_pending_irq(VCPU *vcpu)
 mask = irq_masked(vcpu, h_pending, h_inservice);
 if (  vpsr.i  IRQ_NO_MASKED == mask ) {
 isr = vpsr.val  IA64_PSR_RI;
-if ( !vpsr.ic )
-panic_domain(regs,Interrupt when IC=0\n);
+if ( !vpsr.ic ){
+printk(Interrupt when IC=0\n);
+show_registers(regs);
+domain_crash_synchronous();
+}
 update_vhpi(vcpu, h_pending);
 vmx_reflect_interruption(0, isr, 0, 12, regs); // EXT IRQ
 } else if (mask == IRQ_MASKED_BY_INSVC) {

I think panic_domain() don't need debugger_trap_immediate() 
and debugger_trap_fatal().
So what I really want to do is removing them.

BTW, as you said, panic_domain() is easier to use than 
domain_crash_synchronous() macro.
I make new patch.
We can know the caller function by CallTrace (without __FILE__, __LINE__),
so I only remove the debug routines.
Is the attached new patch better?

Best Regards,

Akio Takebe

remove_debugger_function.patch
Description: Binary data
___
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel

Re: [Xen-ia64-devel] [Patch] Remove panic_domain()

2007-03-27 Thread Akio Takebe
Hi,

I forgot signed-off-by

Signed-off-by: Akio Takebe [EMAIL PROTECTED]

Best Regards,

Akio Takebe

Hi, Alex

On Fri, 2007-03-23 at 15:00 +0900, Akio Takebe wrote:
 Hi,
 
 I found the bug of panic_domain().
 When we compile xen with crash_debug=y, debugger_trap_immediate() and 
 debugger_trap_fatal() is not nop.
 So if xen call panic_domain() to crash guest,
 xen call debugger routine, then hangup system.
 
 domain_crash_synchronous() has __FILE__, __LINE__ macros.
 So I remove panic_domain() and replace it with printk() and
 domain_crash_synchronous() as x86 do.

   Wouldn't it work just as well to convert panic_domain() to a macro
and remove the debugger_trap_immediate() and debugger_trap_fatal()
calls?  The abstraction of panic_domain() is easier to use than
requiring someone to call all the relevant functions manually.  Thanks,

Yes, I used also show_registers() if panic_domain has regs arguments.
(e.g. the following part.)

diff -r 2216a45bf058 xen/arch/ia64/vmx/vlsapic.c
--- a/xen/arch/ia64/vmx/vlsapic.c  Tue Mar 20 15:19:38 2007 -0600
+++ b/xen/arch/ia64/vmx/vlsapic.c  Fri Mar 23 14:41:48 2007 +0900
@@ -480,8 +480,11 @@ int vmx_check_pending_irq(VCPU *vcpu)
 mask = irq_masked(vcpu, h_pending, h_inservice);
 if (  vpsr.i  IRQ_NO_MASKED == mask ) {
 isr = vpsr.val  IA64_PSR_RI;
-if ( !vpsr.ic )
-panic_domain(regs,Interrupt when IC=0\n);
+if ( !vpsr.ic ){
+printk(Interrupt when IC=0\n);
+show_registers(regs);
+domain_crash_synchronous();
+}
 update_vhpi(vcpu, h_pending);
 vmx_reflect_interruption(0, isr, 0, 12, regs); // EXT IRQ
 } else if (mask == IRQ_MASKED_BY_INSVC) {

I think panic_domain() don't need debugger_trap_immediate() 
and debugger_trap_fatal().
So what I really want to do is removing them.

BTW, as you said, panic_domain() is easier to use than 
domain_crash_synchronous() macro.
I make new patch.
We can know the caller function by CallTrace (without __FILE__, __LINE__),
so I only remove the debug routines.
Is the attached new patch better?

Best Regards,

Akio Takebe


___
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel


Re: [Xen-ia64-devel][Patch]Add two PAL calls which fix SMP windows installation crashing bug

2007-03-27 Thread Alex Williamson
On Tue, 2007-03-27 at 09:18 +0800, Zhang, Xing Z wrote:
 Add two PAL calls -- PAL_LOGICAL_TO_PHYSICAL and PAL_FIXED_ADDR.
 
 These PAL calls are invoked by SMP windows installation code.
 
 The patch fix SMP windows installation crashing bug.

   This seems incomplete.  Doesn't a PAL_LOGICAL_TO_PHYSICAL
implementation imply we also need a working SAL_PHYSICAL_ID_INFO?  I
also get error messages about unimplemented PAL call #43
(PAL_CACHE_SHARED_INFO) when I try this.  According to the spec, this
call is required for any system reporting more than one logical
processor on a physical processor package.

   I think we should implement these calls, but why would we represent a
vCPU as anything more than a single processor per socket?  If we pretend
everything is a dual core processor with threads disabled, we get into
issues of reporting the correct socket number and thread number.  It
feels like it's just adding complication for no benefit.  Thanks,

Alex

-- 
Alex Williamson HP Open Source  Linux Org.


___
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel


RE: [Xen-ia64-devel][Patch]Add two PAL calls which fix SMP windowsinstallation crashing bug

2007-03-27 Thread Alex Williamson
Hi Wing,

On Wed, 2007-03-28 at 10:00 +0800, Zhang, Xing Z wrote:

 Actually, we also represent a vcpu as single core single thread at
 beginning. But it's very strange that windows still crash during SMP
 installation. So we implement it as native Montecito which has dual
 core. Maybe more investigations need.

   But there is a single core 9010 Montecito processor.  Does that imply
Windows fails to install on that processor?  Thanks,

Alex

-- 
Alex Williamson HP Open Source  Linux Org.


___
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel


[Xen-ia64-devel] Re: [Xen-devel] Please pull xen-ia64-unstable.hg

2007-03-27 Thread Isaku Yamahata
On Tue, Mar 27, 2007 at 03:21:57PM -0600, Alex Williamson wrote:
 Hi Keir,
 
   Please pull:
 
 http://xenbits.xensource.com/ext/xen-ia64-unstable.hg
 
 This is a small pull that mainly includes changes to our P2M semantics
 to match x86.  Once this is merged, we can clean out the
 page_is_removable hook we added previously as a work around.  Thanks,

The patch to remove the hook is attached.
Please apply it after the pull.

thanks,

-- 
yamahata
# HG changeset patch
# User [EMAIL PROTECTED]
# Date 1174616721 -32400
# Node ID 0135c4856cd32212b3c4ec43a067b9dba9bf59d8
# Parent  eaeeefd8cddb55016ccd10e4d8b56db71963e67c
remove page_is_removable arch hook. Now the ia64 p2m semantic becomes
same as the x86 p2m table so that the hook is unnecessary any more.
PATCHNAME: remove_page_is_removebale_arch_hook

Signed-off-by: Isaku Yamahata [EMAIL PROTECTED]

diff -r eaeeefd8cddb -r 0135c4856cd3 xen/common/memory.c
--- a/xen/common/memory.c	Thu Mar 22 21:55:14 2007 +0900
+++ b/xen/common/memory.c	Fri Mar 23 11:25:21 2007 +0900
@@ -173,11 +173,11 @@ int guest_remove_page(struct domain *d, 
 if ( test_and_clear_bit(_PGC_allocated, page-count_info) )
 put_page(page);
 
-if ( unlikely(!page_is_removable(page)) )
+if ( unlikely((page-count_info  PGC_count_mask) != 1) )
 {
 shadow_drop_references(d, page);
 /* We'll make this a guest-visible error in future, so take heed! */
-if ( !page_is_removable(page) )
+if ( (page-count_info  PGC_count_mask) != 1 )
 gdprintk(XENLOG_INFO, Dom%d freeing in-use page %lx 
  (pseudophys %lx): count=%lx type=%lx\n,
  d-domain_id, mfn, get_gpfn_from_mfn(mfn),
diff -r eaeeefd8cddb -r 0135c4856cd3 xen/include/asm-ia64/mm.h
--- a/xen/include/asm-ia64/mm.h	Thu Mar 22 21:55:14 2007 +0900
+++ b/xen/include/asm-ia64/mm.h	Fri Mar 23 11:25:21 2007 +0900
@@ -208,11 +208,6 @@ static inline int get_page_and_type(stru
 }
 
 return rc;
-}
-
-static inline int page_is_removable(struct page_info *page)
-{
-return ((page-count_info  PGC_count_mask) == 1);
 }
 
 #define	set_machinetophys(_mfn, _pfn) do { } while(0);
diff -r eaeeefd8cddb -r 0135c4856cd3 xen/include/asm-powerpc/mm.h
--- a/xen/include/asm-powerpc/mm.h	Thu Mar 22 21:55:14 2007 +0900
+++ b/xen/include/asm-powerpc/mm.h	Fri Mar 23 11:25:21 2007 +0900
@@ -204,11 +204,6 @@ static inline int get_page_and_type(stru
 return rc;
 }
 
-static inline int page_is_removable(struct page_info *page)
-{
-return ((page-count_info  PGC_count_mask) == 1);
-}
-
 extern void synchronise_pagetables(unsigned long cpu_mask);
 
 /* XXX don't know what this is for */
diff -r eaeeefd8cddb -r 0135c4856cd3 xen/include/asm-x86/mm.h
--- a/xen/include/asm-x86/mm.h	Thu Mar 22 21:55:14 2007 +0900
+++ b/xen/include/asm-x86/mm.h	Fri Mar 23 11:25:21 2007 +0900
@@ -222,11 +222,6 @@ static inline int get_page_and_type(stru
 return rc;
 }
 
-static inline int page_is_removable(struct page_info *page)
-{
-return ((page-count_info  PGC_count_mask) == 1);
-}
-
 #define ASSERT_PAGE_IS_TYPE(_p, _t)\
 ASSERT(((_p)-u.inuse.type_info  PGT_type_mask) == (_t)); \
 ASSERT(((_p)-u.inuse.type_info  PGT_count_mask) != 0)
___
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel

RE: [Xen-ia64-devel][Patch]Add two PAL calls which fix SMPwindowsinstallation crashing bug

2007-03-27 Thread Zhang, Xing Z
We did same guess ever but we don't have single core processor now,
so I can't confirm it on native.

Good good study,day day up ! ^_^
-Wing(zhang xin)
 
OTC,Intel Corporation

-Original Message-
From: Alex Williamson [mailto:[EMAIL PROTECTED]
Sent: 2007年3月28日 10:27
To: Zhang, Xing Z
Cc: xen-ia64-devel
Subject: RE: [Xen-ia64-devel][Patch]Add two PAL calls which fix
SMPwindowsinstallation crashing bug

Hi Wing,

On Wed, 2007-03-28 at 10:00 +0800, Zhang, Xing Z wrote:

 Actually, we also represent a vcpu as single core single thread at
 beginning. But it's very strange that windows still crash during SMP
 installation. So we implement it as native Montecito which has dual
 core. Maybe more investigations need.

   But there is a single core 9010 Montecito processor.  Does that imply
Windows fails to install on that processor?  Thanks,

   Alex

--
Alex Williamson HP Open Source  Linux Org.

___
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel