RE: [Xen-ia64-devel][PATCH] Enable SMP on VTI domain.
From: Isaku Yamahata [mailto:[EMAIL PROTECTED] Sent: 2006?6?21? 17:25 To: Xu, Anthony Cc: xen-ia64-devel@lists.xensource.com Subject: Re: [Xen-ia64-devel][PATCH] Enable SMP on VTI domain. On Thu, Jun 01, 2006 at 12:55:08PM +0800, Xu, Anthony wrote: Or you mean the protection of global purge. When a vcpu get IPI to purge TLB, What it does is to invalid the TLB entry in VHPT, but not remove the TLB entry. There is no race condition. Is there any gurantee that the vcpu which recives IPI isn't touching VHPT? The vcpu which receives IPI can touch VHPT in the same time. Because purge operation only sets the TLB entry invalid, like entry-ti=1. That has the same philosophy with Tristan's direct purge Could you review the two attached patches? Purge function traverses the collision chain when IPI is sent. But there is a window when the assumption of the collision chain is broken. vmx_hpw_miss() has a race. ia64_do_page_fault() had a similar race before. -- Sorry for late response. The second patch is good cleanup and improvement. I don't understand the race condition the first patch fixes. Could you please elaborate this? Thanks, Anthony yamahata ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel][PATCH] Enable SMP on VTI domain.
Hi Anthony. On Thu, Jun 29, 2006 at 02:21:48PM +0800, Xu, Anthony wrote: From: Isaku Yamahata [mailto:[EMAIL PROTECTED] Sent: 2006?6?21? 17:25 To: Xu, Anthony Cc: xen-ia64-devel@lists.xensource.com Subject: Re: [Xen-ia64-devel][PATCH] Enable SMP on VTI domain. On Thu, Jun 01, 2006 at 12:55:08PM +0800, Xu, Anthony wrote: Or you mean the protection of global purge. When a vcpu get IPI to purge TLB, What it does is to invalid the TLB entry in VHPT, but not remove the TLB entry. There is no race condition. Is there any gurantee that the vcpu which recives IPI isn't touching VHPT? The vcpu which receives IPI can touch VHPT in the same time. Because purge operation only sets the TLB entry invalid, like entry-ti=1. That has the same philosophy with Tristan's direct purge Could you review the two attached patches? Purge function traverses the collision chain when IPI is sent. But there is a window when the assumption of the collision chain is broken. vmx_hpw_miss() has a race. ia64_do_page_fault() had a similar race before. -- Sorry for late response. The second patch is good cleanup and improvement. The second patch is also a bug fix patch. I don't understand the race condition the first patch fixes. Could you please elaborate this? The patch fixes two races. - a race in vmx_process() of vmx_process.c The same race was there in ia64_do_page_fault() before. The check, (fault == IA64_USE_TLB !current-arch.dtlb.pte.p), in ia64_do_page_fault() avoids this race. - a race in vtlb.c vmx_vcpu_ptc_l() needs a certain condition on the collision chain to traverse collision chains and purge entries correctly. But there are windows when the condision is broken. The critical areas are surrounded by local_irq_save() and local_irq_restore() with the patch. If a vcpu send a IPI to another vcpu for ptc.ga when another vcpu is in the critical area, things goes bad. Actually the patch assumes that the targeted vcpu is still on the physical cpu which received IPI. It might be reasonable to assume so before credit scheduler was introduced... If the targeted vcpu moved to another physical cpu, the collision chain is traversed on the IPI'ed physical cpu and the collision chain is modified on the physical cpu on which the targeted vcpu runs at the same time. The collision chain modification/traverse code doesn't seem to be lock-free. Something bad would happen. In fact I suspect that there still remains a problem. I haven't checked the generated assembler code and I'm not sure though. - vmx_vcpu_ptc_ga() while (proc != v-processor); v-processor's type is int. However v-processor might be changed asynchronously by vcpu scheduler on another physical cpu. Compiler barrier and memory barrier might be needed somewhere. -- yamahata ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] [PATCH]A typo fix
Fix a typo. Thanks Best Regards -Xiantao OTC,Intel Corporation typo_fix.diff Description: typo_fix.diff ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
RE: [Xen-ia64-devel][PATCH] Enable SMP on VTI domain.
See comments From: Isaku Yamahata [mailto:[EMAIL PROTECTED] Sent: 2006?6?29? 16:03 To: Xu, Anthony Cc: xen-ia64-devel@lists.xensource.com Subject: Re: [Xen-ia64-devel][PATCH] Enable SMP on VTI domain. Hi Anthony. On Thu, Jun 29, 2006 at 02:21:48PM +0800, Xu, Anthony wrote: From: Isaku Yamahata [mailto:[EMAIL PROTECTED] Sent: 2006?6?21? 17:25 To: Xu, Anthony Cc: xen-ia64-devel@lists.xensource.com Subject: Re: [Xen-ia64-devel][PATCH] Enable SMP on VTI domain. On Thu, Jun 01, 2006 at 12:55:08PM +0800, Xu, Anthony wrote: Or you mean the protection of global purge. When a vcpu get IPI to purge TLB, What it does is to invalid the TLB entry in VHPT, but not remove the TLB entry. There is no race condition. Is there any gurantee that the vcpu which recives IPI isn't touching VHPT? The vcpu which receives IPI can touch VHPT in the same time. Because purge operation only sets the TLB entry invalid, like entry-ti=1. That has the same philosophy with Tristan's direct purge Could you review the two attached patches? Purge function traverses the collision chain when IPI is sent. But there is a window when the assumption of the collision chain is broken. vmx_hpw_miss() has a race. ia64_do_page_fault() had a similar race before. -- Sorry for late response. The second patch is good cleanup and improvement. The second patch is also a bug fix patch. I don't understand the race condition the first patch fixes. Could you please elaborate this? The patch fixes two races. - a race in vmx_process() of vmx_process.c The same race was there in ia64_do_page_fault() before. The check, (fault == IA64_USE_TLB !current-arch.dtlb.pte.p), in ia64_do_page_fault() avoids this race. VTI-domain doesn't have this issue, which is introduced by 1-entry TLB - a race in vtlb.c vmx_vcpu_ptc_l() needs a certain condition on the collision chain to traverse collision chains and purge entries correctly. But there are windows when the condision is broken. The critical areas are surrounded by local_irq_save() and local_irq_restore() with the patch. If a vcpu send a IPI to another vcpu for ptc.ga when another vcpu is in the critical area, things goes bad. There seems be some race conditions. But I had used correct operation sequence on VTLB to avoid these race conditions. local_irq_save() and local_irq_restore() are not needed, some mb may be needed to guarantee the memory access order. Actually the patch assumes that the targeted vcpu is still on the physical cpu which received IPI. It might be reasonable to assume so before credit scheduler was introduced... I don't assume the targeted vcpu is running on the physical cpu. If the targeted vcpu moved to another physical cpu, the collision chain is traversed on the IPI'ed physical cpu and the collision chain is modified on the physical cpu on which the targeted vcpu runs at the same time. The collision chain modification/traverse code doesn't seem to be lock-free. Something bad would happen. In fact I suspect that there still remains a problem. I haven't checked the generated assembler code and I'm not sure though. - vmx_vcpu_ptc_ga() while (proc != v-processor); v-processor's type is int. However v-processor might be changed asynchronously by vcpu scheduler on another physical cpu. Compiler barrier and memory barrier might be needed somewhere. I didn't think of vcpu being scheduled to other LP by far. -- yamahata ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel][PATCH] Enable SMP on VTI domain.
On Thu, Jun 29, 2006 at 05:42:27PM +0800, Xu, Anthony wrote: - a race in vmx_process() of vmx_process.c The same race was there in ia64_do_page_fault() before. The check, (fault == IA64_USE_TLB !current-arch.dtlb.pte.p), in ia64_do_page_fault() avoids this race. VTI-domain doesn't have this issue, which is introduced by 1-entry TLB VT-i domain introduced v-arch.vtlb instead of 1-entry TLB. Similar race can occur with v-arch.vtlb. -- yamahata ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] Re: [Xen-devel] [PATCH] fix event channel notification loss on IA64
On 29 Jun 2006, at 06:43, Isaku Yamahata wrote: evtchn_do_upcall() has a micro optimization which is depends on that xchg is a barrier. However xchg of IA64 has acquire semantics so that event channel notification is lost sometimes. This patch fixes it. clear_bit() isn't a barrier either (at least according to Linux bitop semantics). You want 'rmb();'. I suggest just putting it inside ifndef CONFIG_X86, with the comment about XCHG being a barrier on x86 placed just before the ifndef. Leave the zap of pending flag as a plain write. -- Keir ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
RE: [Xen-ia64-devel][PATCH] Enable SMP on VTI domain.
From: Isaku Yamahata [mailto:[EMAIL PROTECTED] Sent: 2006?6?29? 18:36 To: Xu, Anthony Cc: xen-ia64-devel@lists.xensource.com Subject: Re: [Xen-ia64-devel][PATCH] Enable SMP on VTI domain. On Thu, Jun 29, 2006 at 05:42:27PM +0800, Xu, Anthony wrote: - a race in vmx_process() of vmx_process.c The same race was there in ia64_do_page_fault() before. The check, (fault == IA64_USE_TLB !current-arch.dtlb.pte.p), in ia64_do_page_fault() avoids this race. VTI-domain doesn't have this issue, which is introduced by 1-entry TLB VT-i domain introduced v-arch.vtlb instead of 1-entry TLB. Similar race can occur with v-arch.vtlb. The difference is that 1-entry TLB uses pte.p to indicate whether it's valid. While VTLB uses entry-ti to indicate whether it's valid, which is similar with VHPT, there is no issue. Thanks, Anthony -- yamahata ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
RE: [Xen-ia64-devel][PATCH] ptc.g virtualization fix
Done, -Original Message- From: Isaku Yamahata [mailto:[EMAIL PROTECTED] Sent: 2006?6?26? 21:54 To: Xu, Anthony Cc: xen-ia64-devel@lists.xensource.com Subject: Re: [Xen-ia64-devel][PATCH] ptc.g virtualization fix Hi Anthony. vmx_load_rr7_and_pta() and load_region_reg7_and_pta() aren't used anymore with your patche. So they can be removed. Please don't forget to remove theire proto type declarations in the header file. On Mon, Jun 26, 2006 at 05:13:46PM +0800, Xu, Anthony wrote: First, thanks Yamahata and Xiantao for their effort on ptc.g virtualization. This patch is a small fix. VMM only needs to switch rr0 and pta when emulating ptc.g. Because VMM only use rr0 and pta to do global purge on other LPs. VMM doesn't need to switch rr7, it is time consuming operation. Signed-off-by: Anthony Xu [EMAIL PROTECTED] Thanks, Anthony ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel -- yamahata ptc_g_cleanup.patch Description: ptc_g_cleanup.patch ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] Weekly benchmark results [ww26]
Hi, all I will inform this week's benchmark result. The tools used now is as follows. - unixbench4.1.0 - bonnie++-1.03 - ltp-full-20060306 - iozone3_191 - lmbench-3.0-a5 TEST ENVIRONMENT Machine : Tiger4 KERN : 2.6.16.13-xen changeset: 10559:4b51d081378d Dom0 OS : RHEL4 U2 (no SMP) DomU OS : RHEL4 U2 (2P) No. of DomU's: 1 SUMMARY: - issues: - TEST RESULT unixbench4.1.0: Pass bonnie++-1.03 : Pass ltp-full-20060306 : 8/817 FAIL (Please see the attached files) iozone3_191 : Pass lmbench-3.0-a5: Pass Thanks and best regards, Fujita and Fujitsu members ltp-domU-20060629.log 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] Re: [Xen-devel] [PATCH] fix event channelnotification loss on IA64
From: Keir Fraser Sent: 2006年6月29日 21:29 On 29 Jun 2006, at 06:43, Isaku Yamahata wrote: evtchn_do_upcall() has a micro optimization which is depends on that xchg is a barrier. However xchg of IA64 has acquire semantics so that event channel notification is lost sometimes. This patch fixes it. clear_bit() isn't a barrier either (at least according to Linux bitop semantics). You want 'rmb();'. I suggest just putting it inside ifndef CONFIG_X86, with the comment about XCHG being a barrier on x86 placed just before the ifndef. Leave the zap of pending flag as a plain write. -- Keir Yes, the explicit semantic of clear_bit doesn’t contain the barrier, which however implicitly imposes a partial barrier on xen/ia64 due to its memory model. On IA64, a acquire semantic serves to ensure current instruction made visible prior to all subsequent instructions, and clear_bit on IA64 is implemented with cmpxchg.acq which can ensure subsequent event manipulations strictly following event indicator clearance. But, in this special case, seems to use rmb() is preferred, since this clearance doesn't need to be a semaphore operation which should be light. Thanks Kevin ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel][PATCH] Emulate PAL_HALT_LIGHT
Alex, This patch intends to use do_block to emulate Guest PAL_HALT_LIGHT, whenever there is an interrupt for this vcpu, this vcpu is woken up. Signed-off-by: Anthony Xu [EMAIL PROTECTED] And, I noticed domU use do_yield to emulate Guest PAL_HALT_LIGHT, There is no correctness issue, but may impact performance when HT is enabled. If there are a domU vcpu and idle vcpu running on one LP, Then Guest PAL_HALT_LIGHT will become a tight loop,that means this LP will not yield resource to the other LP on the same core even when there is no task running on this LP. This will impact the whole system performance dramatically. VTI-domain had suffered this penalty due to the similar reason. I propose to use do_block to emulate Guest PAL_HALT_LIGHT. Thanks, Anthony emulate_PAL_HALT_LIGHT.patch Description: emulate_PAL_HALT_LIGHT.patch ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
