linux-kernel - Re: [Qemu-devel] [RFC kernel 0/2]A PV solution for KVM live migration optimization

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Thu, 10 Mar 2016 13:00:00 +0530
From:	Amit Shah <amit.shah@...hat.com>
To:	Jitendra Kolhe <jitendra.kolhe@....com>
Cc:	liang.z.li@...el.com, dgilbert@...hat.com, ehabkost@...hat.com,
	kvm@...r.kernel.org, mst@...hat.com, quintela@...hat.com,
	linux-kernel@...r.kernel.org, qemu-devel@...gnu.org,
	linux-mm@...ck.org, pbonzini@...hat.com, akpm@...ux-foundation.org,
	virtualization@...ts.linux-foundation.org, rth@...ddle.net,
	mohan_parthasarathy@....com, simhan@....com
Subject: Re: [Qemu-devel] [RFC kernel 0/2]A PV solution for KVM live
 migration optimization

On (Thu) 10 Mar 2016 [12:31:32], Jitendra Kolhe wrote:
> On 3/8/2016 4:44 PM, Amit Shah wrote:
> >>>> Hi,
> >>>>   An interesting solution; I know a few different people have been looking at
> >>>> how to speed up ballooned VM migration.
> >>>>
> >>>
> >>> Ooh, different solutions for the same purpose, and both based on the balloon.
> >>
> >> We were also tying to address similar problem, without actually needing to modify
> >> the guest driver. Please find patch details under mail with subject.
> >> migration: skip sending ram pages released by virtio-balloon driver
> >
> > The scope of this patch series seems to be wider: don't send free
> > pages to a dest at all, vs. don't send pages that are ballooned out.
> 
> Hi,
> 
> Thanks for your response. The scope of this patch series doesn’t seem to take care 
> of ballooned out pages. To balloon out a guest ram page the guest balloon driver does 
> a alloc_page() and then return the guest pfn to Qemu, so ballooned out pages will not 
> be seen as free ram pages by the guest.
> Thus we will still end up scanning (for zero page) for ballooned out pages during 
> migration. It would be ideal if we could have both solutions.

Yes, of course it would be nice to have both solutions.  My response was to the line:

> >>> Ooh, different solutions for the same purpose, and both based on the balloon.

which sounded misleading to me for a couple of reasons: 1, as you
describe, pages being considered by this patchset and yours are
different; and 2, as I mentioned in the other mail, this patchset
doesn't really depend on the balloon, and I believe it should not.


		Amit