From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:50361) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RdiDa-0005p5-Uw for qemu-devel@nongnu.org; Thu, 22 Dec 2011 07:57:58 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RdiDZ-0007A4-HV for qemu-devel@nongnu.org; Thu, 22 Dec 2011 07:57:54 -0500 Received: from mx1.redhat.com ([209.132.183.28]:51832) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RdiDZ-00079x-5K for qemu-devel@nongnu.org; Thu, 22 Dec 2011 07:57:53 -0500 Message-ID: <4EF3294A.5050505@redhat.com> Date: Thu, 22 Dec 2011 14:57:46 +0200 From: Avi Kivity MIME-Version: 1.0 References: <1324304024-11220-1-git-send-email-avi@redhat.com> <1324304024-11220-15-git-send-email-avi@redhat.com> <20111222125016.GB25538@redhat.com> <4EF32793.30108@redhat.com> <20111222125734.GC25538@redhat.com> In-Reply-To: <20111222125734.GC25538@redhat.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 14/23] vhost: convert to MemoryListener API List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Michael S. Tsirkin" Cc: xen-devel@lists.xensource.com, qemu-devel@nongnu.org, kvm@vger.kernel.org, Stefano Stabellini On 12/22/2011 02:57 PM, Michael S. Tsirkin wrote: > On Thu, Dec 22, 2011 at 02:50:27PM +0200, Avi Kivity wrote: > > On 12/22/2011 02:50 PM, Michael S. Tsirkin wrote: > > > On Mon, Dec 19, 2011 at 04:13:35PM +0200, Avi Kivity wrote: > > > > +static void vhost_log_start(MemoryListener *listener, > > > > + MemoryRegionSection *section) > > > > +{ > > > > + /* FIXME: implement */ > > > > +} > > > > + > > > > +static void vhost_log_stop(MemoryListener *listener, > > > > + MemoryRegionSection *section) > > > > +{ > > > > + /* FIXME: implement */ > > > > +} > > > > + > > > > > > What exactly do we need to fix here? > > > > Tell vhost to start tracking those regions? > > > > I guess you don't often read packets into the framebuffer, or we'd have > > a lot of bug reports. > > Yes, we currently simply don't pass these regions to vhost. > It currently signals an error if such is > observed, so we could handle framebuffer in userspace > if we wanted to. I see, thanks. -- error compiling committee.c: too many arguments to function