Re: [Qemu-block] [Qemu-devel] [PATCH for-2.11] iotests: Fix 176 on 32-bit host
On 11/17/2017 04:59 PM, John Snow wrote: >>> So for this test, the easiest solution is to filter out the >>> actual hash value. Broken in commit 4096974e. >> >> Of course, if Kevin sends a v2 pull, it's probably better to just squash >> this in to my original testsuite change (since a v2 would probably >> invalidate that commit id). >> > > Whichever way you go, Commit 4096974e has already landed in master, so this commit message is correct as-is and belongs in the next pull request (whether for -rc2 or -rc3 depends on timing). > > Reviewed-by: John Snow> > I don't know how important it is to nail this down, but the purpose of > this command is primarily for sanity testing and not necessarily between > architectures, so this might just be a limitation to document. > > Also, don't use this for anything except testing. Indeed, the name of x-debug-block-dirty-bitmap-sha256 already implies its limited portability; but it also gives us free reign to change it's behavior if we find something we like better for the same ease of bitmap testing/debugging. -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3266 Virtualization: qemu.org | libvirt.org signature.asc Description: OpenPGP digital signature
Re: [Qemu-block] [Qemu-devel] [PATCH for-2.11] iotests: Fix 176 on 32-bit host
On 11/17/2017 02:10 PM, Eric Blake wrote: > On 11/17/2017 01:04 PM, Eric Blake wrote: >> The contents of a qcow2 bitmap are rounded up to a size that >> matches the number of bits available for the granularity, but >> that granularity differs for 32-bit hosts (our default 64k >> cluster allows for 2M bitmap coverage per 'long') and 64-bit >> hosts (4M bitmap per 'long'). If the image is a multiple of >> 2M but not 4M, then the number of bytes occupied by the array >> of longs in memory differs between architecture, thus >> resulting in different SHA256 hashes. >> >> Furthermore (but untested by me), if our computation of the >> SHA256 hash is at all endian-dependent because of how we store >> data in memory, that's another variable we'd have to account >> for (ideally, we specified the bitmap stored in qcow2 as >> fixed-endian on disk, because the same qcow2 file must be >> usable across any architecture; but that says nothing about >> how we represent things in memory). But we already have test >> 165 to validate that bitmaps are stored correctly on disk, >> while this test is merely testing that the bitmap exists. >> >> So for this test, the easiest solution is to filter out the >> actual hash value. Broken in commit 4096974e. > > Of course, if Kevin sends a v2 pull, it's probably better to just squash > this in to my original testsuite change (since a v2 would probably > invalidate that commit id). > Whichever way you go, Reviewed-by: John SnowI don't know how important it is to nail this down, but the purpose of this command is primarily for sanity testing and not necessarily between architectures, so this might just be a limitation to document. Also, don't use this for anything except testing. :(
Re: [Qemu-block] [Qemu-devel] [PATCH for-2.11] iotests: Fix 176 on 32-bit host
On 11/17/2017 01:04 PM, Eric Blake wrote: > The contents of a qcow2 bitmap are rounded up to a size that > matches the number of bits available for the granularity, but > that granularity differs for 32-bit hosts (our default 64k > cluster allows for 2M bitmap coverage per 'long') and 64-bit > hosts (4M bitmap per 'long'). If the image is a multiple of > 2M but not 4M, then the number of bytes occupied by the array > of longs in memory differs between architecture, thus > resulting in different SHA256 hashes. > > Furthermore (but untested by me), if our computation of the > SHA256 hash is at all endian-dependent because of how we store > data in memory, that's another variable we'd have to account > for (ideally, we specified the bitmap stored in qcow2 as > fixed-endian on disk, because the same qcow2 file must be > usable across any architecture; but that says nothing about > how we represent things in memory). But we already have test > 165 to validate that bitmaps are stored correctly on disk, > while this test is merely testing that the bitmap exists. > > So for this test, the easiest solution is to filter out the > actual hash value. Broken in commit 4096974e. Of course, if Kevin sends a v2 pull, it's probably better to just squash this in to my original testsuite change (since a v2 would probably invalidate that commit id). -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3266 Virtualization: qemu.org | libvirt.org signature.asc Description: OpenPGP digital signature