From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:49664) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UaSk7-00046n-KX for qemu-devel@nongnu.org; Thu, 09 May 2013 11:26:55 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UaSk4-0004HD-SN for qemu-devel@nongnu.org; Thu, 09 May 2013 11:26:51 -0400 Received: from mx1.redhat.com ([209.132.183.28]:16829) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UaSk4-0004H1-GN for qemu-devel@nongnu.org; Thu, 09 May 2013 11:26:48 -0400 Date: Thu, 9 May 2013 17:26:42 +0200 From: Stefan Hajnoczi Message-ID: <20130509152642.GC26728@stefanha-thinkpad.redhat.com> References: <1368060022-16911-1-git-send-email-qemulist@gmail.com> <20130509083017.GH1074@stefanha-thinkpad.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Subject: Re: [Qemu-devel] [PATCH 1/2] Vring: vring's listener's priority should higher than kvm List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: liu ping fan Cc: Peter Maydell , "Michael S. Tsirkin" , Stefan Hajnoczi , qemu-devel@nongnu.org, Anthony Liguori , Jan Kiszka , Paolo Bonzini On Thu, May 09, 2013 at 05:00:20PM +0800, liu ping fan wrote: > On Thu, May 9, 2013 at 4:30 PM, Stefan Hajnoczi wrote: > > On Thu, May 09, 2013 at 08:40:21AM +0800, Liu Ping Fan wrote: > >> From: Liu Ping Fan > >> > >> Hosts threads which handle vring should have high MemoryListener priority > >> than kvm. For currently code, take the following scenario: > >> kvm_region_add() run earlier before vhost_region_add(), then in guest, > >> vring's desc[i] can refer to addressX in the new region known by guest. > >> But vhost does not know this new region yet, and the vring handler will > >> fail. > > > > Is there a concrete scenario where this happens? > > > > I can think of situations like the ioeventfd being readable before > > vhost/hostmem is populated. But I don't see how that's related to the > > priority of kvm_region_add(). > > > For kvm, ie, In guest, vring_desc.addr can point to a chunk of data in > the new added memory, and kick vhost. The vhost has not added this new > region, so its local lookup table can not translate this new address, > and vring handler will fail. If vhost priority is higher than kvm, > then, it will know this new address earlier than kvm. Isn't the real solution to ensure that the memory API is up-to-date before we notify the guest of memory hotplug? I still don't see a kvm vs vhost race. I see a guest vs vhost race which priority doesn't fix. Stefan