restructure results

2 files changed, 0 insertions, 332 deletions

diff --git a/results/classifier/015/virtual/22219210 b/results/classifier/015/virtual/22219210
deleted file mode 100644
index ba6ca50aa..000000000
--- a/results/classifier/015/virtual/22219210
+++ /dev/null
@@ -1,70 +0,0 @@
-virtual: 0.877
-x86: 0.860
-architecture: 0.818
-graphic: 0.701
-operating system: 0.532
-performance: 0.498
-hypervisor: 0.491
-device: 0.489
-mistranslation: 0.472
-semantic: 0.387
-VMM: 0.364
-network: 0.323
-ppc: 0.297
-TCG: 0.285
-user-level: 0.273
-socket: 0.244
-debug: 0.225
-PID: 0.214
-vnc: 0.204
-files: 0.202
-peripherals: 0.201
-kernel: 0.166
-register: 0.150
-permissions: 0.141
-risc-v: 0.123
-i386: 0.120
-KVM: 0.099
-alpha: 0.096
-arm: 0.093
-assembly: 0.078
-boot: 0.070
-
-[BUG][CPU hot-plug]CPU hot-plugs cause the qemu process to coredump
-
-Hello,Recently, when I was developing CPU hot-plugs under the loongarch
-architecture,
-I found that there was a problem with qemu cpu hot-plugs under x86
-architecture,
-which caused the qemu process coredump when repeatedly inserting and
-unplugging
-the CPU when the TCG was accelerated.
-
-
-The specific operation process is as follows:
-
-1.Use the following command to start the virtual machine
-
-qemu-system-x86_64 \
--machine q35  \
--cpu Broadwell-IBRS \
--smp 1,maxcpus=4,sockets=4,cores=1,threads=1 \
--m 4G \
--drive file=~/anolis-8.8.qcow2  \
--serial stdio   \
--monitor telnet:localhost:4498,server,nowait
-
-
-2.Enter QEMU Monitor via telnet for repeated CPU insertion and unplugging
-
-telnet 127.0.0.1 4498
-(qemu) device_add
-Broadwell-IBRS-x86_64-cpu,socket-id=1,core-id=0,thread-id=0,id=cpu1
-(qemu) device_del cpu1
-(qemu) device_add
-Broadwell-IBRS-x86_64-cpu,socket-id=1,core-id=0,thread-id=0,id=cpu1
-3.You will notice that the QEMU process has a coredump
-
-# malloc(): unsorted double linked list corrupted
-Aborted (core dumped)
-
diff --git a/results/classifier/015/virtual/81775929 b/results/classifier/015/virtual/81775929
deleted file mode 100644
index b2a4f81d9..000000000
--- a/results/classifier/015/virtual/81775929
+++ /dev/null
@@ -1,262 +0,0 @@
-virtual: 0.864
-assembly: 0.849
-permissions: 0.849
-PID: 0.847
-performance: 0.831
-operating system: 0.830
-vnc: 0.825
-semantic: 0.825
-architecture: 0.823
-arm: 0.819
-graphic: 0.818
-register: 0.817
-KVM: 0.815
-ppc: 0.815
-user-level: 0.813
-mistranslation: 0.811
-socket: 0.810
-hypervisor: 0.802
-debug: 0.799
-x86: 0.793
-files: 0.788
-VMM: 0.781
-device: 0.777
-risc-v: 0.774
-alpha: 0.773
-network: 0.759
-peripherals: 0.757
-boot: 0.742
-TCG: 0.742
-kernel: 0.740
-i386: 0.613
-
-[Qemu-devel] [BUG] Monitor QMP is broken ?
-
-Hello!
-
- I have updated my qemu to the recent version and it seems to have lost 
-compatibility with
-libvirt. The error message is:
---- cut ---
-internal error: unable to execute QEMU command 'qmp_capabilities': QMP input 
-object member
-'id' is unexpected
---- cut ---
- What does it mean? Is it intentional or not?
-
-Kind regards,
-Pavel Fedin
-Expert Engineer
-Samsung Electronics Research center Russia
-
-Hello! 
-
->
-I have updated my qemu to the recent version and it seems to have lost
->
-compatibility
-with
->
-libvirt. The error message is:
->
---- cut ---
->
-internal error: unable to execute QEMU command 'qmp_capabilities': QMP input
->
-object
->
-member
->
-'id' is unexpected
->
---- cut ---
->
-What does it mean? Is it intentional or not?
-I have found the problem. It is caused by commit
-65207c59d99f2260c5f1d3b9c491146616a522aa. libvirt does not seem to use the 
-removed
-asynchronous interface but it still feeds in JSONs with 'id' field set to 
-something. So i
-think the related fragment in qmp_check_input_obj() function should be brought 
-back
-
-Kind regards,
-Pavel Fedin
-Expert Engineer
-Samsung Electronics Research center Russia
-
-On Fri, Jun 05, 2015 at 04:58:46PM +0300, Pavel Fedin wrote:
->
-Hello!
->
->
->  I have updated my qemu to the recent version and it seems to have lost
->
-> compatibility
->
-with
->
-> libvirt. The error message is:
->
-> --- cut ---
->
-> internal error: unable to execute QEMU command 'qmp_capabilities': QMP
->
-> input object
->
-> member
->
-> 'id' is unexpected
->
-> --- cut ---
->
->  What does it mean? Is it intentional or not?
->
->
-I have found the problem. It is caused by commit
->
-65207c59d99f2260c5f1d3b9c491146616a522aa. libvirt does not seem to use the
->
-removed
->
-asynchronous interface but it still feeds in JSONs with 'id' field set to
->
-something. So i
->
-think the related fragment in qmp_check_input_obj() function should be
->
-brought back
-If QMP is rejecting the 'id' parameter that is a regression bug.
-
-[quote]
-The QMP spec says
-
-2.3 Issuing Commands
---------------------
-
-The format for command execution is:
-
-{ "execute": json-string, "arguments": json-object, "id": json-value }
-
- Where,
-
-- The "execute" member identifies the command to be executed by the Server
-- The "arguments" member is used to pass any arguments required for the
-  execution of the command, it is optional when no arguments are
-  required. Each command documents what contents will be considered
-  valid when handling the json-argument
-- The "id" member is a transaction identification associated with the
-  command execution, it is optional and will be part of the response if
-  provided. The "id" member can be any json-value, although most
-  clients merely use a json-number incremented for each successive
-  command
-
-
-2.4 Commands Responses
-----------------------
-
-There are two possible responses which the Server will issue as the result
-of a command execution: success or error.
-
-2.4.1 success
--------------
-
-The format of a success response is:
-
-{ "return": json-value, "id": json-value }
-
- Where,
-
-- The "return" member contains the data returned by the command, which
-  is defined on a per-command basis (usually a json-object or
-  json-array of json-objects, but sometimes a json-number, json-string,
-  or json-array of json-strings); it is an empty json-object if the
-  command does not return data
-- The "id" member contains the transaction identification associated
-  with the command execution if issued by the Client
-
-[/quote]
-
-And as such, libvirt chose to /always/ send an 'id' parameter in all
-commands it issues.
-
-We don't however validate the id in the reply, though arguably we
-should have done so.
-
-Regards,
-Daniel
--- 
-|:
-http://berrange.com
--o-
-http://www.flickr.com/photos/dberrange/
-:|
-|:
-http://libvirt.org
--o-
-http://virt-manager.org
-:|
-|:
-http://autobuild.org
--o-
-http://search.cpan.org/~danberr/
-:|
-|:
-http://entangle-photo.org
--o-
-http://live.gnome.org/gtk-vnc
-:|
-
-"Daniel P. Berrange" <address@hidden> writes:
-
->
-On Fri, Jun 05, 2015 at 04:58:46PM +0300, Pavel Fedin wrote:
->
->  Hello!
->
->
->
-> >  I have updated my qemu to the recent version and it seems to have
->
-> > lost compatibility
->
-> with
->
-> > libvirt. The error message is:
->
-> > --- cut ---
->
-> > internal error: unable to execute QEMU command 'qmp_capabilities':
->
-> > QMP input object
->
-> > member
->
-> > 'id' is unexpected
->
-> > --- cut ---
->
-> >  What does it mean? Is it intentional or not?
->
->
->
->  I have found the problem. It is caused by commit
->
-> 65207c59d99f2260c5f1d3b9c491146616a522aa. libvirt does not seem to
->
-> use the removed
->
-> asynchronous interface but it still feeds in JSONs with 'id' field
->
-> set to something. So i
->
-> think the related fragment in qmp_check_input_obj() function should
->
-> be brought back
->
->
-If QMP is rejecting the 'id' parameter that is a regression bug.
-It is definitely a regression, my fault, and I'll get it fixed a.s.a.p.
-
-[...]
-