From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:56536) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1b5Wsr-0004WQ-Mm for qemu-devel@nongnu.org; Wed, 25 May 2016 07:21:54 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1b5Wsq-0007Ft-H9 for qemu-devel@nongnu.org; Wed, 25 May 2016 07:21:53 -0400 References: <1464128732-12667-1-git-send-email-eblake@redhat.com> <1464128732-12667-3-git-send-email-eblake@redhat.com> <20160525103001.GB4815@noname.redhat.com> From: Eric Blake Message-ID: <57458AC7.4090906@redhat.com> Date: Wed, 25 May 2016 05:21:43 -0600 MIME-Version: 1.0 In-Reply-To: <20160525103001.GB4815@noname.redhat.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="ww2iGrS0TfM2lGdXHHLVE517xkXcVtDMG" Subject: Re: [Qemu-devel] [PATCH 02/13] block: Track write zero limits in bytes List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Kevin Wolf Cc: qemu-devel@nongnu.org, qemu-block@nongnu.org, Stefan Hajnoczi , Fam Zheng , Max Reitz , Ronnie Sahlberg , Paolo Bonzini , Peter Lieven This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --ww2iGrS0TfM2lGdXHHLVE517xkXcVtDMG Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 05/25/2016 04:30 AM, Kevin Wolf wrote: > Am 25.05.2016 um 00:25 hat Eric Blake geschrieben: >> Another step towards removing sector-based interfaces: convert >> the maximum write and minimum alignment values from sectorss to >=20 > s/sectorss/sectors/ >=20 >> bytes. Alignment is changed to 'int', since it makes no sense >> to have an alignment larger than the maximum write. Add an >> assert that no one was trying to use sectors to get a write >> zeroes larger than 2G. Rename the variables to let the compiler >> check that all users are converted to the new semantics. >> >> Signed-off-by: Eric Blake >=20 >> --- a/block/iscsi.c >> +++ b/block/iscsi.c >> @@ -1706,12 +1706,10 @@ static void iscsi_refresh_limits(BlockDriverSt= ate *bs, Error **errp) >> } >> >> if (iscsilun->bl.max_ws_len < 0xffffffff) { >> - bs->bl.max_write_zeroes =3D >> - sector_limits_lun2qemu(iscsilun->bl.max_ws_len, iscsilun)= ; >> + bs->bl.max_pwrite_zeroes =3D iscsilun->bl.max_ws_len; >=20 > Wrong unit, I think. You need to multiply by iscsi_lun->block_size. Hmm, I think you're right. What's more, I need to make sure the result doesn't wrap around INT_MAX (a device with 4k block size that supports 8G limits via 2M max blocks should still allow up to 2G transactions from qemu). I'm also thinking that in v2, it may be easier to reason about alignment limits if I convert alignment numbers to uint32_t, although we are still capped by INT_MAX in our various blk_* interfaces (worrying about signed overflow is a pain). >> +++ b/block/qcow2.c >> @@ -1193,7 +1193,7 @@ static void qcow2_refresh_limits(BlockDriverStat= e *bs, Error **errp) >> { >> BDRVQcow2State *s =3D bs->opaque; >> >> - bs->bl.write_zeroes_alignment =3D s->cluster_sectors; >> + bs->bl.pwrite_zeroes_alignment =3D s->cluster_sectors << BDRV_SEC= TOR_BITS; >=20 > This is s->cluster_size. I hope to get rid of s->cluster_sectors > eventually. :-) Should I go ahead and convert ALL of BlockLimits to be byte-based limits, rather than an odd mix of sector vs. byte limits? Should I add any assertions for power-of-2 limits? Do we want to allow 0x80000000 as a valid length limit? [/me Should I be regretting touching this can of worms in the first place? :) ] --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --ww2iGrS0TfM2lGdXHHLVE517xkXcVtDMG 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 Comment: Public key at http://people.redhat.com/eblake/eblake.gpg Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCAAGBQJXRYrHAAoJEKeha0olJ0NqL24IAKwv4cHq5Q5wQ0jPur0AdvjR qCc0jVA6X6HYB9q3od3w4OUGFFCy7NvHJD7W3SThLZJr0NVtfearMLTLZHLve1kM 93imsC5c4HMm1nE16oXN4IfY1A9oWyd7U2Y8BNM0KRueDqzFU2dpee/Dg7qsDJ6g yoHqrPLlnJZjZejaOdyfy1sP0GsBcc9dsw3hjBVg38S1f63HKwwaKK4JAA5Ucita h6AYl5CSfnP7mWuKQCSJ8DRMC3IGxLxP+/g+XU8elEAOwIQ+8AP1bpQHl7uebrXv fFcCTAsBW/ksZl6brHUM19pNqt7BWNeOrIN+EHqjylm52+Hc/wzuJgm2fccClvQ= =vX3o -----END PGP SIGNATURE----- --ww2iGrS0TfM2lGdXHHLVE517xkXcVtDMG--