RE: [Xen-ia64-devel] Xen/IPF Unstable CS#18688, Linux#705, ioemu#629adb3f... Status --- no new issue, report 3 old bugs
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
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
RE: [Xen-ia64-devel] Xen/IPF Unstable CS#18688, Linux#705, ioemu#629adb3f... Status --- no new issue, report 3 old bugs
Isaku Yamahata wrote: On Fri, Oct 24, 2008 at 09:59:58AM +0800, Zhang, Jingke wrote: 3. IPF-Xen can not boot up domain with dom_id 62 (not regression, should be there for a long time) Long ago, I posted the patch to address this issue. Probably there are two ways. (Is there other better way?) a.) abandon the rid partitioning, and flush mTLB every time vcpu context switch. Current kvm adopts this method, we didn't find any performance regression through benchmark. But sine the architecture difference between xen and kvm, so maybe should investigate more through enough benchmark data. (some bits of rid space needs to be reserved for real mode emulation.) b.) keep the rid partitioning and allow rid collision. When vcpu context switch, check the rid collision and flush mTLB if necessary. Benchmark would be necessary to decide which one is better and to estimate performance degradation. I implemented b). However no one has implemented a). So no further step was taken. 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. Xiantao thanks, ___ 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
On Mon, Oct 27, 2008 at 04:36:38PM +0800, Zhang, Xiantao wrote: Isaku Yamahata wrote: On Fri, Oct 24, 2008 at 09:59:58AM +0800, Zhang, Jingke wrote: 3. IPF-Xen can not boot up domain with dom_id 62 (not regression, should be there for a long time) Long ago, I posted the patch to address this issue. Probably there are two ways. (Is there other better way?) a.) abandon the rid partitioning, and flush mTLB every time vcpu context switch. Current kvm adopts this method, we didn't find any performance regression through benchmark. But sine the architecture difference between xen and kvm, so maybe should investigate more through enough benchmark data. Sounds interesting. (some bits of rid space needs to be reserved for real mode emulation.) b.) keep the rid partitioning and allow rid collision. When vcpu context switch, check the rid collision and flush mTLB if necessary. Benchmark would be necessary to decide which one is better and to estimate performance degradation. I implemented b). However no one has implemented a). So no further step was taken. 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. -- yamahata ___ 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
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); -- yamahata ___ 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
On Fri, Oct 24, 2008 at 09:59:58AM +0800, Zhang, Jingke wrote: 3. IPF-Xen can not boot up domain with dom_id 62 (not regression, should be there for a long time) Long ago, I posted the patch to address this issue. Probably there are two ways. (Is there other better way?) a.) abandon the rid partitioning, and flush mTLB every time vcpu context switch. (some bits of rid space needs to be reserved for real mode emulation.) b.) keep the rid partitioning and allow rid collision. When vcpu context switch, check the rid collision and flush mTLB if necessary. Benchmark would be necessary to decide which one is better and to estimate performance degradation. I implemented b). However no one has implemented a). So no further step was taken. thanks, -- yamahata ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] Xen/IPF Unstable CS#18688, Linux#705, ioemu#629adb3f... Status --- no new issue, report 3 old bugs
Hi all, There is no regression in Cset#18688. All the case can pass! But, we tried many manual testing on IPF and found some old bugs. See detail below: === 1. SMP Windows2008 boots much slower with other VTI guest togather (Win2k8 needs 7 minutes) If booting win2k8 singlely, it can be booted within 200 seconds. (win2k8's Memory=1024, vcpus=2) 2. On RHEL5u2 with IRQBALANCE service start, dom0 will crash 3. IPF-Xen can not boot up domain with dom_id 62 (not regression, should be there for a long time) Detail Xen/IA64 Unstable Cset #18688 Status Report Test Result Summary: # total case: 17 # passed case: 17 # failed case: 0 Testing Environment: platform: Tiger4 xen ia64 unstable tree: 18688 dom0 Cset:705 ioemu commit: 629adb3f5244169731ff18b16ae919641d81ad76 processor: Itanium 2 Processor logic Processors number: 8 (2 processors with Dual Core) pal version: 9.68 service os: RHEL5u2 IA64 SMP with 2 VCPUs vti guest os: RHEL5u2 RHEL4u3 xenU guest os: RHEL4u4 xen schedule: credit gfw: open guest firmware Cset#131 Detailed Test Results: Passed case Summary Description Two_UP_VTI_Co UP_VTI (mem=256) One_UP_VTI 1 UP_VTI (mem=256) One_UP_XenU 1 UP_xenU(mem=256) One_SMPVTI_4096M1 VTI (vcpus=2, mem=4096M) SMPVTI_LTP VTI (vcpus=4, mem=512) run LTP SaveRestoreSaveRestore VTI_Live-migration Linux VTI live-migration SMPVTI_and_SMPXenU 1 VTI + 1 xenU (mem=256 vcpus=2) Two_SMPXenU_Coexist 2 xenU (mem=256, vcpus=2) SMPVTI_Network 1 VTI (mem=256,vcpu=2) and'ping' SMPXenU_Network 1 XenU (vcpus=2) and 'ping' One_SMP_XenU1 SMP xenU (vcpus=2) One_SMP_VTI 1 SMP VTI (vcpus=2) SMPVTI_Kernel_Build VTI (vcpus=4) and do KernelBuild UPVTI_Kernel_Build 1 UP VTI and do kernel build SMPVTI_Windows SMPVTI windows(vcpu=2) SMPWin_SMPVTI_SMPxenU SMPVTI Linux/Windows XenU Thanks, Zhang Jingke ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
