qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [Bug 1707297] [NEW] qemu became more picky parsing -m o


From: Markus Armbruster
Subject: Re: [Qemu-devel] [Bug 1707297] [NEW] qemu became more picky parsing -m option
Date: Mon, 31 Jul 2017 15:28:45 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.2 (gnu/linux)

Eric Blake <address@hidden> writes:

> On 07/31/2017 03:34 AM, Markus Armbruster wrote:
>> John Florian <address@hidden> writes:
>> 
>>> Public bug reported:
>>>
>>> With qemu-kvm-2.9.0-3.fc26.x86_64 I am no longer to specify the memory
>>> size using something like "-m 1.00000GiB" but with qemu-
>>> kvm-2.7.1-7.fc25.x86_64 I could without any problem.  I now get an error
>>> message like:
>>>
>>> qemu-system-x86_64: -m 1.00000GiB: Parameter 'size' expects a non-negative 
>>> number below 2^64
>>> Optional suffix k, M, G, T, P or E means kilo-, mega-, giga-, tera-, peta-
>>> and exabytes, respectively.
>>>
>>>
>>> Is this expected or a regression?
>> 
>> We recognize suffix "G".  Before commit 75cdcd1 (v2.9.0), trailing
>> garbage after a recognized suffix was silently ignored.  "1.0G",
>> "1.0GiB", "1.0Garbage-trucks-of-RAM" were all the same to QEMU.  No
>> more.
>> 
>> All clear?
>
> That said, virsh from libvirt manages to recognize 'G' and 'GiB' as
> synonyms (powers of 2), as well as 'GB' (powers of 10); we could justify
> patching qemu's parser to accept more valid suffixes, particularly since
> 'GiB' is a typical suffix that has seen use (in spite of it not being
> documented).

I wouldn't object to such a patch, as long as it doesn't regress
consistency.  Easy if we do "number with suffix" in just one place.  We
might already do it, but I can't say offhand.  Also, the patch probably
shouldn't change qemu_strtosz_metric().



reply via email to

[Prev in Thread] Current Thread [Next in Thread]