add 18th iteration of classifier

1 files changed, 86 insertions, 0 deletions

diff --git a/results/classifier/118/virtual/1707297 b/results/classifier/118/virtual/1707297
new file mode 100644
index 000000000..83aa0b347
--- /dev/null
+++ b/results/classifier/118/virtual/1707297
@@ -0,0 +1,86 @@
+virtual: 0.851
+performance: 0.824
+user-level: 0.712
+hypervisor: 0.689
+architecture: 0.615
+device: 0.608
+arm: 0.603
+semantic: 0.600
+KVM: 0.591
+ppc: 0.579
+socket: 0.570
+network: 0.569
+kernel: 0.566
+permissions: 0.554
+mistranslation: 0.553
+x86: 0.551
+peripherals: 0.546
+graphic: 0.542
+PID: 0.532
+debug: 0.475
+register: 0.447
+vnc: 0.406
+VMM: 0.400
+boot: 0.399
+risc-v: 0.389
+assembly: 0.322
+TCG: 0.308
+files: 0.236
+i386: 0.229
+
+qemu became more picky parsing -m option
+
+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?
+
+On 07/31/2017 03:34 AM, Markus Armbruster wrote:
+> John Florian <email 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).
+
+-- 
+Eric Blake, Principal Software Engineer
+Red Hat, Inc.           +1-919-301-3266
+Virtualization:  qemu.org | libvirt.org
+
+
+
+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.)
+
+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.
+