From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:35948) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YNSBu-00086b-Fz for qemu-devel@nongnu.org; Mon, 16 Feb 2015 15:22:51 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YNSBq-0000gq-In for qemu-devel@nongnu.org; Mon, 16 Feb 2015 15:22:50 -0500 Received: from mx1.redhat.com ([209.132.183.28]:59778) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YNSBq-0000ga-Bm for qemu-devel@nongnu.org; Mon, 16 Feb 2015 15:22:46 -0500 Message-ID: <54E25194.4060502@redhat.com> Date: Mon, 16 Feb 2015 13:22:44 -0700 From: Eric Blake MIME-Version: 1.0 References: <1423865338-8576-1-git-send-email-jsnow@redhat.com> <1423865338-8576-4-git-send-email-jsnow@redhat.com> In-Reply-To: <1423865338-8576-4-git-send-email-jsnow@redhat.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="welG94AgB3MKpV2TQ5S7naln8tXNN4Fh4" Subject: Re: [Qemu-devel] [PATCH v13 03/17] qmp: Add block-dirty-bitmap-add and block-dirty-bitmap-remove List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: John Snow , qemu-devel@nongnu.org Cc: kwolf@redhat.com, famz@redhat.com, armbru@redhat.com, mreitz@redhat.com, vsementsov@parallels.com, stefanha@redhat.com This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --welG94AgB3MKpV2TQ5S7naln8tXNN4Fh4 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 02/13/2015 03:08 PM, John Snow wrote: > The new command pair is added to manage user created dirty bitmap. The s/manage/manage a/ > dirty bitmap's name is mandatory and must be unique for the same device= , > but different devices can have bitmaps with the same names. >=20 > The granularity is an optional field. If it is not specified, we will > choose a default granularity based on the cluster size if available, > clamped to between 4K and 64K to mirror how the 'mirror' code was > already choosing granularity. If we do not have cluster size info > available, we choose 64K. This code has been factored out into a helper= > shared with block/mirror. The drive-mirror command in block-core.json documents that it supports a granularity between 512 and 64M, not 64k. Is there a bug here? See more below. >=20 > This patch also introduces the 'block_dirty_bitmap_lookup' helper, > which takes a device name and a dirty bitmap name and validates the > lookup, returning NULL and setting errp if there is a problem with > either field. This helper will be re-used in future patches in this > series. >=20 > The types added to block-core.json will be re-used in future patches > in this series, see: > 'qapi: Add transaction support to block-dirty-bitmap-{add, enable, disa= ble}' >=20 > Signed-off-by: John Snow > --- > block.c | 20 ++++++++++ > block/mirror.c | 10 +---- > blockdev.c | 100 ++++++++++++++++++++++++++++++++++++++++++= ++++++++ > include/block/block.h | 1 + > qapi/block-core.json | 55 +++++++++++++++++++++++++++ > qmp-commands.hx | 51 +++++++++++++++++++++++++ > 6 files changed, 228 insertions(+), 9 deletions(-) > =20 > + > + if (has_granularity) { > + if (granularity < 512 || !is_power_of_2(granularity)) { > + error_setg(errp, "Granularity must be power of 2 " > + "and at least 512"); > + goto out; > + } > + } else { > + /* Default to cluster size, if available: */ > + granularity =3D bdrv_get_default_bitmap_granularity(bs); > + } This enforces a minimum granularity, but should we also be enforcing a maximum? That is, if the user does not provide granularity, we default between 4k and 64k based on cluster size, but if the user DOES provide granularity, we allow as small as 512, but as large as the user can pass. Should we enforce a maximum of 64M? --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --welG94AgB3MKpV2TQ5S7naln8tXNN4Fh4 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Public key at http://people.redhat.com/eblake/eblake.gpg Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCAAGBQJU4lGUAAoJEKeha0olJ0NqvtcIAKTl4SPjVbG40jCb6Y/0BnQH JcHYXZcUar3q5vGVfnd7FLM5Yi5wqPpMIO70BcLTtddfOyu/yYVf921tAD9PQJzb /vLH4aRkve7KjwcvDxfVWojO/EBua4zNw3ODVCiiSXSrAkIBjOwrTcrtnKIPxtpL axsRPybJQPKO7tIDlChgVCVrsfJpRUSAifbvTn4pO9czIVrd5HrbnIRp6EoInn/Q 3XBkhu73uMApvCpVUGphAo0r416qO8dOHbdJFbmWcLoUFpYJi3Rv63UKHK/Jg1ij yeerC56uaRJxRGczXzaJG0+DCBfFzTE9maa9Mp6h6nmhTG5bXxDyJoidi8oi5AM= =c2AX -----END PGP SIGNATURE----- --welG94AgB3MKpV2TQ5S7naln8tXNN4Fh4--