From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Ling, Xiaofeng" Subject: Re: [PATCH]fix xen0 hang when start seconds vmx guest Date: Thu, 10 Nov 2005 15:46:27 +0800 Message-ID: <4372FAD3.50405@intel.com> References: <4372EB0B.5080001@intel.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="------------050601040807000105060007" Return-path: In-Reply-To: <4372EB0B.5080001@intel.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: "Ling, Xiaofeng" Cc: xen-devel List-Id: xen-devel@lists.xenproject.org This is a multi-part message in MIME format. --------------050601040807000105060007 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Attach patch can satisfy the audit. For vmx domain, we also call get_type. Ling, Xiaofeng wrote: > For vmx domain, because shadow_mode_reference is set later in > vmx_final_setup_guest, so in arch_set_info_guest, the phys_basetab > is not do get_page, while when destroying, put_page is called, > so there is one page, the count=-1, and when a new domain allocate > this page, it will take it as cpumask 0xffffffff, this cause > flash_tlb_mask goes into dead loop.(How new bios/microcode can deal with > it? maybe some differnet in sending IPI?) > The warning: > (XEN) Audit 1: type count went below zero mfn=1e03d t=f0000000 ot=3654b > is also caused by this, for vmx domain, the page is net get_type. > > I think bug 128, 131, 351 are all caused by this issue. > > diff -r 07070a351156 -r 833b086cc0e8 xen/arch/x86/domain.c > --- a/xen/arch/x86/domain.c Thu Nov 10 12:18:23 2005 +0800 > +++ b/xen/arch/x86/domain.c Thu Nov 10 14:05:11 2005 +0800 > @@ -389,7 +389,12 @@ > if ( !get_page(&frame_table[phys_basetab>>PAGE_SHIFT], d) ) > return -EINVAL; > } > - else if ( !(c->flags & VGCF_VMX_GUEST) ) > + else if ( (c->flags & VGCF_VMX_GUEST) ) > + { > + if ( !get_page(&frame_table[phys_basetab>>PAGE_SHIFT], d) ) > + return -EINVAL; > + } > + else > { > if ( !get_page_and_type(&frame_table[phys_basetab>>PAGE_SHIFT], d, > PGT_base_page_table) ) > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel --------------050601040807000105060007 Content-Type: text/x-patch; name="vmxgetpagefix.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="vmxgetpagefix.patch" # HG changeset patch # User Xiaofeng Ling # Node ID 833b086cc0e82af98fb5149cebfce08e5e65b4b1 # Parent 07070a3511560287314082abf5f3514d4bfdd0dd For vmx domain, because shadow_mode_reference is set later in vmx_final_setup_guest, so in arch_set_info_guest, the phys_basetab is not do get_page, while when destroying, put_page is called, so there is one page, the count=-1, and when a new domain allocate this page, it will take it as cpumask 0xffffffff, this cause flash_tlb_mask goes into dead loop. This patch also eliminate the warning when creating vmx guest: (XEN) Audit 1: type count went below zero mfn=1e03d t=f0000000 ot=3654b Signed-off-by: Xiaofeng Ling diff -r 07070a351156 xen/arch/x86/domain.c --- a/xen/arch/x86/domain.c Thu Nov 10 12:18:23 2005 +0800 +++ b/xen/arch/x86/domain.c Thu Nov 10 15:36:29 2005 +0800 @@ -389,7 +389,7 @@ if ( !get_page(&frame_table[phys_basetab>>PAGE_SHIFT], d) ) return -EINVAL; } - else if ( !(c->flags & VGCF_VMX_GUEST) ) + else { if ( !get_page_and_type(&frame_table[phys_basetab>>PAGE_SHIFT], d, PGT_base_page_table) ) @@ -962,7 +962,7 @@ { if ( (pfn = pagetable_get_pfn(v->arch.guest_table)) != 0 ) { - if ( !shadow_mode_refcounts(d) ) + if ( !shadow_mode_refcounts(d) || shadow_mode_external(d) ) put_page_type(pfn_to_page(pfn)); put_page(pfn_to_page(pfn)); --------------050601040807000105060007 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel --------------050601040807000105060007--