From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Wei, Gang" Subject: RE: Xen 4.1 rc1 test report Date: Wed, 26 Jan 2011 13:52:46 +0800 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: Content-Language: en-US List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: "Zheng, Shaohui" , "xen-devel@lists.xensource.com" Cc: Keir Fraser , "Wei, Gang" List-Id: xen-devel@lists.xenproject.org Wei, Gang wrote on=A02011-01-25: >> 2. [VT-d]xen panic on function do_IRQ after many times NIC pass-throu >> (Intel) >> http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=3D1706 > There are three points we may need to do: > 1. Figure out the root cause why the pciback could not locate the device. > I suspect the previous 'xl destroy' didn't return the device to > pcistub successfully. >=20 > 2. Figure out the root cause why the guest pirq was not force unbound. > Just found: > Some time because if ( !IS_PRIV_FOR(current->domain, d) ) hit, so > returned with -EINVAL; Sometime if ( !(desc->status & IRQ_GUEST) ) > hit, so do not unbind. >=20 > 3. Think about how we could prevent such cases from panic Xen. Just found sometime while doing domain_destroy the current->domain is IDLE = domain, so the if ( !IS_PRIV_FOR(current->domain, d) ) hit and skip the pir= q forcible unbinding. How could it happen? Jimmy