On 1/7/21 6:20 AM, Richard W.M. Jones wrote:
>> Actually that's not the only problem. It appears that we're unable to
>> read or write the last sector of this disk:
>>
>> $ nbdkit memory $(( 2**63 - 2**30 )) --run 'build/qemu-io -r -f raw "$uri"
>> -c "r -v $(( 2**63 - 2**30 - 512 )) 512" '
>> read failed: Input/output error
>>
>> $ nbdkit memory $(( 2**63 - 2**30 )) --run 'build/qemu-io -f raw "$uri" -c
>> "w -P 3 $(( 2**63 - 2**30 - 512 )) 512" '
>> write failed: Input/output error
>>
>> You can play around with the constants. I found it's possible to read
>> and write the non-aligned 512 bytes starting at 2^63-2^30-513. Could
>> be a fencepost error somewhere in qemu?
>
> Actually this is a pre-existing bug in qemu.
>
> What happens is qemu-io calls qemu_strtosz("9223372035781033472")
> which returns 0x7fffffffc0000000 and no error. That answer is plain
> flat out wrong. The reason for that is qemu_strtosz uses floating
> point for the calculation(!) so is limited to 53 bits of precision and
> silently truncates.
I'm working a patch for that soon. It was easy to fix things to parse
with full 64 bits of precision while still allowing a fractional bump
(for things like 1.5M), but harder to chase down all the spots in the
testsuite that are impacted by our parser now being more accurate.
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3226
Virtualization: qemu.org | libvirt.org
