From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([209.51.188.92]:35776) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gwzJG-0003ZM-AE for qemu-devel@nongnu.org; Thu, 21 Feb 2019 20:07:27 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gwzJC-0005xc-Ep for qemu-devel@nongnu.org; Thu, 21 Feb 2019 20:07:23 -0500 Received: from mga17.intel.com ([192.55.52.151]:31791) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1gwzJB-0005W7-UI for qemu-devel@nongnu.org; Thu, 21 Feb 2019 20:07:22 -0500 Message-ID: <5C6F4C5A.40400@intel.com> Date: Fri, 22 Feb 2019 09:11:54 +0800 From: Wei Wang MIME-Version: 1.0 References: <1544516693-5395-1-git-send-email-wei.w.wang@intel.com> <1544516693-5395-8-git-send-email-wei.w.wang@intel.com> <20181213154548.GP2313@work-vm> <5C135017.3070203@intel.com> <20181214095646.GB2454@work-vm> <5C13862B.1010905@intel.com> <20181214111705.GD2454@work-vm> <286AC319A985734F985F78AFA26841F73DF7A436@shsmsx102.ccr.corp.intel.com> <20190220131224.GF2608@work-vm> <5C6E03B6.30309@intel.com> <20190221101839.GD2605@work-vm> In-Reply-To: <20190221101839.GD2605@work-vm> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH v11 7/7] virtio-balloon: VIRTIO_BALLOON_F_FREE_PAGE_HINT List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Dr. David Alan Gilbert" Cc: "qemu-devel@nongnu.org" , "mst@redhat.com" , "quintela@redhat.com" , "peterx@redhat.com" , "pbonzini@redhat.com" , "liliang.opensource@gmail.com" , "nilal@redhat.com" , "riel@redhat.com" On 02/21/2019 06:18 PM, Dr. David Alan Gilbert wrote: > * Wei Wang (wei.w.wang@intel.com) wrote: >> On 02/20/2019 09:12 PM, Dr. David Alan Gilbert wrote: >>> * Wang, Wei W (wei.w.wang@intel.com) wrote: >>>> On Friday, December 14, 2018 7:17 PM, Dr. David Alan Gilbert wrote: >>>>>> On 12/14/2018 05:56 PM, Dr. David Alan Gilbert wrote: >>>>>>> * Wei Wang (wei.w.wang@intel.com) wrote: >>>>>>>> On 12/13/2018 11:45 PM, Dr. David Alan Gilbert wrote: >>>>>>>>> * Wei Wang (wei.w.wang@intel.com) wrote: >>>>>>>>>> The new feature enables the virtio-balloon device to receive >>>>>>>>>> hints of guest free pages from the free page vq. >>>>>>>>>> >>>>>>>>>> A notifier is registered to the migration precopy notifier >>>>>>>>>> chain. The notifier calls free_page_start after the migration >>>>>>>>>> thread syncs the dirty bitmap, so that the free page >>>>>>>>>> optimization starts to clear bits of free pages from the >>>>>>>>>> bitmap. It calls the free_page_stop before the migration >>>>>>>>>> thread syncs the bitmap, which is the end of the current round >>>>>>>>>> of ram save. The free_page_stop is also called to stop the >>>>> optimization in the case when there is an error occurred in the process of >>>>> ram saving. >>>>>>>>>> Note: balloon will report pages which were free at the time of this >>>>> call. >>>>>>>>>> As the reporting happens asynchronously, dirty bit logging >>>>>>>>>> must be enabled before this free_page_start call is made. >>>>>>>>>> Guest reporting must be disabled before the migration dirty bitmap >>>>> is synchronized. >>>>>>>>>> Signed-off-by: Wei Wang >>>>>>>>>> CC: Michael S. Tsirkin >>>>>>>>>> CC: Dr. David Alan Gilbert >>>>>>>>>> CC: Juan Quintela >>>>>>>>>> CC: Peter Xu >>>>>>>>> I think I'm OK for this from the migration side, I'd appreciate >>>>>>>>> someone checking the virtio and aio bits. >>>>>>>>> >>>>>>>>> I'm not too sure how it gets switched on and off - i.e. if we >>>>>>>>> get a nice new qemu on a new kernel, what happens when I try and >>>>>>>>> migrate to the same qemu on an older kernel without these hints? >>>>>>>>> >>>>>>>> This feature doesn't rely on the host kernel. Those hints are >>>>>>>> reported from the guest kernel. >>>>>>>> So migration across different hosts wouldn't affect the use of this >>>>> feature. >>>>>>>> Please correct me if I didn't get your point. >>>>>>> Ah OK, yes; now what about migrating from new->old qemu with a new >>>>>>> guest but old machine type? >>>>>>> >>>>>> I think normally, the source QEMU and destination QEMU should have the >>>>>> same QEMU booting parameter. If the destination QEMU doesn't support >>>>>> "--device virtio-balloon,free-page-hint=true", which the source QEMU >>>>>> has, the destination side QEMU will fail to boot, and migration will >>>>>> not happen then. >>>>> Ah that's OK; as long as free-page-hint is false by default that will work fine. >>>>> >>>>> Dave >>>>> >>>> Hi Dave, >>>> >>>> Could we have this feature in QEMU 4.0 (freeze on Mar 12)? >>> I think so; can you remind me where we're up to: >>> a) It looks like you've already got the kernel changes merged - >>> correct? >> Yes, they were already merged half year ago. >> >>> b) What about the virtio spec changes - where are they upto? >> The spec changes are in progress. v1 were posted out, a v2 is in >> preparation. >> >>> c) Where are the other reviews upto - I think most are reviewed - is >>> it just 7/7 that is missing the review-by? >> 7/7 is about the virtio changes, and Michael has given the reviewed-by: >> http://lists.nongnu.org/archive/html/qemu-devel/2018-12/msg03732.html > OK, I was going to check with mst for (b) because I prefer it after the > spec changes have been merged, but since mst is OK with it, then we can > merge especially with (a) already merged. OK, thanks! Best, Wei