From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jan Kiszka Subject: Re: [uq/master patch 2/5] kvm: add logging count to slots Date: Sun, 25 Apr 2010 16:51:53 +0200 Message-ID: <4BD45709.9070705@web.de> References: <20100423170410.914857113@amt.cnet> <20100423170645.675040544@amt.cnet> <4BD29F22.8020806@web.de> <4BD4367F.5060307@redhat.com> <4BD44A4D.4060008@web.de> <4BD44F13.3070000@redhat.com> <4BD451D9.4090209@web.de> <4BD4547C.5060907@redhat.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigAA51A2EE4048D2F6B505D9BE" Cc: Marcelo Tosatti , kvm@vger.kernel.org, qemu-devel@nongnu.org To: Avi Kivity Return-path: Received: from fmmailgate01.web.de ([217.72.192.221]:43817 "EHLO fmmailgate01.web.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751955Ab0DYOv7 (ORCPT ); Sun, 25 Apr 2010 10:51:59 -0400 In-Reply-To: <4BD4547C.5060907@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigAA51A2EE4048D2F6B505D9BE Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable Avi Kivity wrote: > On 04/25/2010 05:29 PM, Jan Kiszka wrote: >> >>> There isn't. But I don't like hidden breakage. >>> =20 >> It's (so far) an unproblematic API property we can document. I don't >> like changing APIs just for "there might be the case that...". >> =20 >=20 > I guess it's one of those agree to disagree things. I dislike known > broken APIs even if their none of their users are affected. The API is not broken. I intentionally designed it for the single user as I saw no need for more. If I oversaw something, I would really like to learn about these cases. >=20 >>>> - the logging API is consistently converted, not just extended >>>> (IOW, migration_log is converted to logging_count) >>>> >>>> =20 >>> migration_log needs to remain global, since we want hotplug memory to= >>> autostart logging. >>> =20 >> Can't follow yet, what will be the usage pattern of >> kvm_set_migration_log? Or would the hotplug code require a separate >> interface? Is it already the multi-client use case I'm looking for? >> =20 >=20 > kvm_set_migration_log() means, start logging now for all current and > future memory, until disabled. Hmm, you mean plugging memory during ongoing migration is valid and can be handled? I'm a bit skeptical. What makes this different from, say, PCI hotplugging which should be a no-go during migration as well? >=20 > It could be implemented in terms of kvm_log_start() (which would provid= e > a multi-client use case), but it isn't now. >=20 > I guess it is a logical example of how two clients can exist, even > though they don't step on each others toes in practice since their > enable flags are kept separate by the implementation. >=20 Jan --------------enigAA51A2EE4048D2F6B505D9BE Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iEYEARECAAYFAkvUVw0ACgkQitSsb3rl5xQ3iQCdGplogawp6MxN2IqqoUGSrpsL 7VEAoNtX6z5t1MecCAOk9gaCU1f4Mp+f =ym3M -----END PGP SIGNATURE----- --------------enigAA51A2EE4048D2F6B505D9BE--