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
