From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [PATCH 17/23] xen: convert to MemoryListener API Date: Wed, 04 Jan 2012 21:42:08 +0200 Message-ID: <4F04AB90.2090504@redhat.com> References: <1324304024-11220-1-git-send-email-avi@redhat.com> <1324304024-11220-18-git-send-email-avi@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "qemu-devel@nongnu.org" , "Michael S. Tsirkin" , "xen-devel@lists.xensource.com" , "kvm@vger.kernel.org" To: Stefano Stabellini Return-path: Received: from mx1.redhat.com ([209.132.183.28]:14407 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751798Ab2ADTmR (ORCPT ); Wed, 4 Jan 2012 14:42:17 -0500 In-Reply-To: Sender: kvm-owner@vger.kernel.org List-ID: On 01/04/2012 08:06 PM, Stefano Stabellini wrote: > On Mon, 19 Dec 2011, Avi Kivity wrote: > > -static int xen_log_start(CPUPhysMemoryClient *client, target_phys_addr_t phys_addr, ram_addr_t size) > > +static void xen_log_start(MemoryListener *listener, > > + MemoryRegionSection *section) > > { > > - XenIOState *state = container_of(client, XenIOState, client); > > + XenIOState *state = container_of(listener, XenIOState, memory_listener); > > + int r; > > > > - return xen_sync_dirty_bitmap(state, phys_addr, size); > > + r = xen_sync_dirty_bitmap(state, section->offset_within_address_space, > > + section->size); > > + assert(r >= 0); > > } > > I really feel I should thank you for your work because you did a very > good job porting xen to the new api. In fact apart from the dirty bitmap > (Anthony is about to send a patch to fix the issue: > xen_sync_dirty_bitmap can actually fail sometimes), everything else > is done right and works correctly. Thanks. > However I would have appreciated if you could have given us more time to > review the four patches you wrote: considering the time of the year both > Anthony and I were on vacation and didn't have a chance to read them > until today. I realize that I bypassed the normal protocol here, but I had to choose one of several bad choices: - continue developing without merging, and risk large rebases in case the patches (or something else in qemu) had to be changed - stop developing until you returned from your (undoubtedly well deserved) vacations - merge and look away while whistling innocently I chose the third, since I still have quite a lot of work with the memory API. Of course I will help with fixing the fallout if needed, and since you're back online, we can go back to the normal way of reviewing and testing patches before merging. -- I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain.