RE: [Xen-ia64-devel] Xen/IPF Unstable CS#18688, Linux#705, ioemu#629adb3f... Status --- no new issue, report 3 old bugs

2008-10-28 Thread Zhang, Xiantao
Isaku Yamahata wrote:
 On Tue, Oct 28, 2008 at 12:12:45PM +0900, Isaku Yamahata wrote:
 I thought Jingke isn't saying this  topic. What he found maybe he
 failed to create the domain when the domain is created and
 destoryed continuously for more 62 times. Seems the issue is from 
 the the algorithm for deallocating rid blocks doesn't work, when
 destroying the guest.
 
 Oh I see. Thank you for the explanation.
 
 Could you try the following patch?
 
 
 IA64: fix XENMEM_add_to_physmap with XENMAPSPACE_mfn.
 
 page reference count was leaked so that hvm domain wasn't freed.
 This patch fixes it.
 
 Signed-off-by: Isaku Yamahata [EMAIL PROTECTED]
 
 diff --git a/xen/arch/ia64/xen/mm.c b/xen/arch/ia64/xen/mm.c
 --- a/xen/arch/ia64/xen/mm.c
 +++ b/xen/arch/ia64/xen/mm.c
 @@ -3365,7 +3365,6 @@ arch_memory_op(int op, XEN_GUEST_HANDLE(
  /* Map at new location. */
  /* Here page-count_info = PGC_allocated | N where N = 1*/
  __guest_physmap_add_page(d, xatp.gpfn, mfn);
 -page = NULL; /* prevent put_page() */
 
  out:
  domain_unlock(d);

Hi, Isuka
Good catch!  That can explain why deallocation algorithm doesn't work.  
Thanks
Xiantao
___
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel


RE: [Xen-ia64-devel] Xen/IPF Unstable CS#18688, Linux#705, ioemu#629adb3f... Status --- no new issue, report 3 old bugs

2008-10-28 Thread Zhang, Jingke
Isaku Yamahata wrote:
 On Tue, Oct 28, 2008 at 12:12:45PM +0900, Isaku Yamahata wrote:
 I thought Jingke isn't saying this  topic. What he found maybe he
 failed to create the domain when the domain is created and
 destoryed continuously for more 62 times. Seems the issue is from 
 the the algorithm for deallocating rid blocks doesn't work, when
 destroying the guest.
 
 Oh I see. Thank you for the explanation.
 
 Could you try the following patch?
 
 
 IA64: fix XENMEM_add_to_physmap with XENMAPSPACE_mfn.
 
 page reference count was leaked so that hvm domain wasn't freed.
 This patch fixes it.
 
 Signed-off-by: Isaku Yamahata [EMAIL PROTECTED]
 
 diff --git a/xen/arch/ia64/xen/mm.c b/xen/arch/ia64/xen/mm.c
 --- a/xen/arch/ia64/xen/mm.c
 +++ b/xen/arch/ia64/xen/mm.c
 @@ -3365,7 +3365,6 @@ arch_memory_op(int op, XEN_GUEST_HANDLE(
  /* Map at new location. */
  /* Here page-count_info = PGC_allocated | N where N = 1*/
  __guest_physmap_add_page(d, xatp.gpfn, mfn);
 -page = NULL; /* prevent put_page() */
 
  out:
  domain_unlock(d);

Yes, I retest it with your patch. VTI guest can be booted when domain_id is 
62. 

Thanks,
Zhang Jingke

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