* [Qemu-devel] [Bug 1707297] [NEW] qemu became more picky parsing -m option
@ 2017-07-28 20:34 John Florian
2017-07-31 8:34 ` Markus Armbruster
` (2 more replies)
0 siblings, 3 replies; 6+ messages in thread
From: John Florian @ 2017-07-28 20:34 UTC (permalink / raw)
To: qemu-devel
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?
** Affects: qemu
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1707297
Title:
qemu became more picky parsing -m option
Status in QEMU:
New
Bug description:
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?
To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1707297/+subscriptions
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Qemu-devel] [Bug 1707297] [NEW] qemu became more picky parsing -m option
2017-07-28 20:34 [Qemu-devel] [Bug 1707297] [NEW] qemu became more picky parsing -m option John Florian
@ 2017-07-31 8:34 ` Markus Armbruster
2017-07-31 12:39 ` Eric Blake
2017-07-31 13:09 ` [Qemu-devel] [Bug 1707297] " John Florian
2020-09-26 17:04 ` Thomas Huth
2 siblings, 1 reply; 6+ messages in thread
From: Markus Armbruster @ 2017-07-31 8:34 UTC (permalink / raw)
To: John Florian; +Cc: qemu-devel
John Florian <1707297@bugs.launchpad.net> 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?
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Qemu-devel] [Bug 1707297] [NEW] qemu became more picky parsing -m option
2017-07-31 8:34 ` Markus Armbruster
@ 2017-07-31 12:39 ` Eric Blake
2017-07-31 13:28 ` Markus Armbruster
0 siblings, 1 reply; 6+ messages in thread
From: Eric Blake @ 2017-07-31 12:39 UTC (permalink / raw)
To: Markus Armbruster, John Florian; +Cc: qemu-devel
[-- Attachment #1: Type: text/plain, Size: 1301 bytes --]
On 07/31/2017 03:34 AM, Markus Armbruster wrote:
> John Florian <1707297@bugs.launchpad.net> 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).
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3266
Virtualization: qemu.org | libvirt.org
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 619 bytes --]
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Qemu-devel] [Bug 1707297] Re: qemu became more picky parsing -m option
2017-07-28 20:34 [Qemu-devel] [Bug 1707297] [NEW] qemu became more picky parsing -m option John Florian
2017-07-31 8:34 ` Markus Armbruster
@ 2017-07-31 13:09 ` John Florian
2020-09-26 17:04 ` Thomas Huth
2 siblings, 0 replies; 6+ messages in thread
From: John Florian @ 2017-07-31 13:09 UTC (permalink / raw)
To: qemu-devel
Not sure why I can only see Markus' comment here as part of Eric's but
anyway... the behavior change *is* expected.
Can qemu behave more like virsh then? That would be ideal IMHO. I
prefer to specify my RAM in powers of 2 and disk in powers of 10 so that
when I test virtually using qemu I more closely match the exact
constraints of real hardware. For the embedded work I do fitting in
tight confines, it can make a significant difference.
(I actually to this with a wrapper I have around qemu, which is why you
see a floating point value for GiB in my example above. My wrapper
behaves like virsh and takes any *B, *iB format and regurgitates it into
something qemu accepts.)
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1707297
Title:
qemu became more picky parsing -m option
Status in QEMU:
New
Bug description:
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?
To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1707297/+subscriptions
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Qemu-devel] [Bug 1707297] [NEW] qemu became more picky parsing -m option
2017-07-31 12:39 ` Eric Blake
@ 2017-07-31 13:28 ` Markus Armbruster
0 siblings, 0 replies; 6+ messages in thread
From: Markus Armbruster @ 2017-07-31 13:28 UTC (permalink / raw)
To: Eric Blake; +Cc: John Florian, qemu-devel
Eric Blake <eblake@redhat.com> writes:
> On 07/31/2017 03:34 AM, Markus Armbruster wrote:
>> John Florian <1707297@bugs.launchpad.net> 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().
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Bug 1707297] Re: qemu became more picky parsing -m option
2017-07-28 20:34 [Qemu-devel] [Bug 1707297] [NEW] qemu became more picky parsing -m option John Florian
2017-07-31 8:34 ` Markus Armbruster
2017-07-31 13:09 ` [Qemu-devel] [Bug 1707297] " John Florian
@ 2020-09-26 17:04 ` Thomas Huth
2 siblings, 0 replies; 6+ messages in thread
From: Thomas Huth @ 2020-09-26 17:04 UTC (permalink / raw)
To: qemu-devel
Looks like nobody cared to implement this within 3 years ... and IMHO
it's maybe even better to not overload the CLI syntax too much ... so
I'm closing this ticket now.
** Changed in: qemu
Status: New => Won't Fix
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1707297
Title:
qemu became more picky parsing -m option
Status in QEMU:
Won't Fix
Bug description:
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?
To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1707297/+subscriptions
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2020-09-26 17:11 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-07-28 20:34 [Qemu-devel] [Bug 1707297] [NEW] qemu became more picky parsing -m option John Florian
2017-07-31 8:34 ` Markus Armbruster
2017-07-31 12:39 ` Eric Blake
2017-07-31 13:28 ` Markus Armbruster
2017-07-31 13:09 ` [Qemu-devel] [Bug 1707297] " John Florian
2020-09-26 17:04 ` Thomas Huth
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.