From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:44406) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S8ED9-0000ZH-Np for qemu-devel@nongnu.org; Thu, 15 Mar 2012 13:11:41 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1S8ECl-00063h-FE for qemu-devel@nongnu.org; Thu, 15 Mar 2012 13:11:35 -0400 Received: from mo-p00-ob.rzone.de ([81.169.146.161]:45983) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S8ECl-000635-5L for qemu-devel@nongnu.org; Thu, 15 Mar 2012 13:11:11 -0400 Date: Thu, 15 Mar 2012 18:10:57 +0100 From: Olaf Hering Message-ID: <20120315171056.GA20701@aepfle.de> References: <4F621649.4030702@citrix.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: Subject: Re: [Qemu-devel] [PATCH] xen-mapcache: don't unmap locked entry during mapcache invalidation List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Stefano Stabellini Cc: Julien Grall , "xen-devel@lists.xensource.com" , "qemu-devel@nongnu.org" , Andres Lagar-Cavilla On Thu, Mar 15, Stefano Stabellini wrote: > On Thu, 15 Mar 2012, Julien Grall wrote: > > When an IOREQ_TYPE_INVALIDATE is sent to QEMU, it invalidates all entry > > of the map cache even if it's locked. > > > > QEMU is not able to know that entry was invalidated, so when an IO > > access is requested a segfault occured. > > The problem here is the long term mappings in QEMU that cannot easily be > re-created. > I am not sure whether this can cause any trouble to things like > xenpaging. Yes, I was wondering about this as well. If the request is made, then its expected that all mappings disappear because they can point to ballooned gfns. IF that case is safe, then all is fine. In case of xenpaging its not an issue because xenpaging just asks qemu to release mappings so that the usage count of mfns drops to 1, so that they can be nominated for eviction. If that fails, not a big deal as it just means that no more pages can be evicted. xenpaging will retry. Olaf From mboxrd@z Thu Jan 1 00:00:00 1970 From: Olaf Hering Subject: Re: [PATCH] xen-mapcache: don't unmap locked entry during mapcache invalidation Date: Thu, 15 Mar 2012 18:10:57 +0100 Message-ID: <20120315171056.GA20701@aepfle.de> References: <4F621649.4030702@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Return-path: Content-Disposition: inline In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: qemu-devel-bounces+gceq-qemu-devel=gmane.org@nongnu.org Sender: qemu-devel-bounces+gceq-qemu-devel=gmane.org@nongnu.org To: Stefano Stabellini Cc: Julien Grall , "xen-devel@lists.xensource.com" , "qemu-devel@nongnu.org" , Andres Lagar-Cavilla List-Id: xen-devel@lists.xenproject.org On Thu, Mar 15, Stefano Stabellini wrote: > On Thu, 15 Mar 2012, Julien Grall wrote: > > When an IOREQ_TYPE_INVALIDATE is sent to QEMU, it invalidates all entry > > of the map cache even if it's locked. > > > > QEMU is not able to know that entry was invalidated, so when an IO > > access is requested a segfault occured. > > The problem here is the long term mappings in QEMU that cannot easily be > re-created. > I am not sure whether this can cause any trouble to things like > xenpaging. Yes, I was wondering about this as well. If the request is made, then its expected that all mappings disappear because they can point to ballooned gfns. IF that case is safe, then all is fine. In case of xenpaging its not an issue because xenpaging just asks qemu to release mappings so that the usage count of mfns drops to 1, so that they can be nominated for eviction. If that fails, not a big deal as it just means that no more pages can be evicted. xenpaging will retry. Olaf