add 17th version of the classifier, including results

3 files changed, 606 insertions, 0 deletions

diff --git a/results/classifier/016/kernel/12869209 b/results/classifier/016/kernel/12869209
new file mode 100644
index 000000000..84c34dec9
--- /dev/null
+++ b/results/classifier/016/kernel/12869209
@@ -0,0 +1,115 @@
+kernel: 0.934
+operating system: 0.427
+files: 0.207
+hypervisor: 0.169
+x86: 0.136
+virtual: 0.104
+TCG: 0.091
+i386: 0.070
+debug: 0.070
+device: 0.069
+risc-v: 0.064
+ppc: 0.064
+PID: 0.043
+VMM: 0.036
+arm: 0.029
+KVM: 0.020
+boot: 0.019
+register: 0.015
+semantic: 0.008
+network: 0.007
+peripherals: 0.004
+architecture: 0.004
+performance: 0.004
+socket: 0.003
+vnc: 0.003
+graphic: 0.003
+assembly: 0.003
+alpha: 0.003
+user-level: 0.002
+permissions: 0.002
+mistranslation: 0.001
+
+[BUG FIX][PATCH v3 0/3] vhost-user-blk: fix bug on device disconnection during initialization
+
+This is a series fixing a bug in
+          host-user-blk.
+Is there any chance for it to be considered for the next rc?
+Thanks!
+Denis
+On 29.03.2021 16:44, Denis Plotnikov
+      wrote:
+ping!
+On 25.03.2021 18:12, Denis Plotnikov
+        wrote:
+v3:
+  * 0003: a new patch added fixing the problem on vm shutdown
+    I stumbled on this bug after v2 sending.
+  * 0001: gramma fixing (Raphael)
+  * 0002: commit message fixing (Raphael)
+
+v2:
+  * split the initial patch into two (Raphael)
+  * rename init to realized (Raphael)
+  * remove unrelated comment (Raphael)
+
+When the vhost-user-blk device lose the connection to the daemon during
+the initialization phase it kills qemu because of the assert in the code.
+The series fixes the bug.
+
+0001 is preparation for the fix
+0002 fixes the bug, patch description has the full motivation for the series
+0003 (added in v3) fix bug on vm shutdown
+
+Denis Plotnikov (3):
+  vhost-user-blk: use different event handlers on initialization
+  vhost-user-blk: perform immediate cleanup if disconnect on
+    initialization
+  vhost-user-blk: add immediate cleanup on shutdown
+
+ hw/block/vhost-user-blk.c | 79 ++++++++++++++++++++++++---------------
+ 1 file changed, 48 insertions(+), 31 deletions(-)
+
+On 01.04.2021 14:21, Denis Plotnikov wrote:
+This is a series fixing a bug in host-user-blk.
+More specifically, it's not just a bug but crasher.
+
+Valentine
+Is there any chance for it to be considered for the next rc?
+
+Thanks!
+
+Denis
+
+On 29.03.2021 16:44, Denis Plotnikov wrote:
+ping!
+
+On 25.03.2021 18:12, Denis Plotnikov wrote:
+v3:
+   * 0003: a new patch added fixing the problem on vm shutdown
+     I stumbled on this bug after v2 sending.
+   * 0001: gramma fixing (Raphael)
+   * 0002: commit message fixing (Raphael)
+
+v2:
+   * split the initial patch into two (Raphael)
+   * rename init to realized (Raphael)
+   * remove unrelated comment (Raphael)
+
+When the vhost-user-blk device lose the connection to the daemon during
+the initialization phase it kills qemu because of the assert in the code.
+The series fixes the bug.
+
+0001 is preparation for the fix
+0002 fixes the bug, patch description has the full motivation for the series
+0003 (added in v3) fix bug on vm shutdown
+
+Denis Plotnikov (3):
+   vhost-user-blk: use different event handlers on initialization
+   vhost-user-blk: perform immediate cleanup if disconnect on
+     initialization
+   vhost-user-blk: add immediate cleanup on shutdown
+
+  hw/block/vhost-user-blk.c | 79 ++++++++++++++++++++++++---------------
+  1 file changed, 48 insertions(+), 31 deletions(-)
+
diff --git a/results/classifier/016/kernel/59540920 b/results/classifier/016/kernel/59540920
new file mode 100644
index 000000000..a8ec93606
--- /dev/null
+++ b/results/classifier/016/kernel/59540920
@@ -0,0 +1,403 @@
+x86: 0.986
+kernel: 0.945
+KVM: 0.913
+boot: 0.770
+hypervisor: 0.714
+debug: 0.662
+operating system: 0.639
+virtual: 0.204
+TCG: 0.199
+risc-v: 0.097
+user-level: 0.097
+register: 0.091
+files: 0.088
+socket: 0.078
+PID: 0.056
+VMM: 0.045
+architecture: 0.041
+vnc: 0.040
+performance: 0.037
+device: 0.034
+assembly: 0.031
+network: 0.024
+alpha: 0.021
+semantic: 0.013
+ppc: 0.013
+peripherals: 0.009
+mistranslation: 0.007
+permissions: 0.006
+graphic: 0.005
+i386: 0.004
+arm: 0.002
+
+[BUG] No irqchip created after commit 11bc4a13d1f4 ("kvm: convert "-machine kernel_irqchip" to an accelerator property")
+
+I apologize if this was already reported,
+
+I just noticed that with the latest updates QEMU doesn't start with the
+following configuration:
+
+qemu-system-x86_64 -name guest=win10 -machine pc,accel=kvm -cpu 
+host,hv_vpindex,hv_synic ...
+
+qemu-system-x86_64: failed to turn on HyperV SynIC in KVM: Invalid argument
+qemu-system-x86_64: kvm_init_vcpu failed: Invalid argument
+
+If I add 'kernel-irqchip=split' or ',kernel-irqchip=on' it starts as
+usual. I bisected this to the following commit:
+
+commit 11bc4a13d1f4b07dafbd1dda4d4bf0fdd7ad65f2 (HEAD, refs/bisect/bad)
+Author: Paolo Bonzini <address@hidden>
+Date:   Wed Nov 13 10:56:53 2019 +0100
+
+    kvm: convert "-machine kernel_irqchip" to an accelerator property
+    
+so aparently we now default to 'kernel_irqchip=off'. Is this the desired
+behavior?
+
+-- 
+Vitaly
+
+No, absolutely not. I was sure I had tested it, but I will take a look.
+Paolo
+Il ven 20 dic 2019, 15:11 Vitaly Kuznetsov <
+address@hidden
+> ha scritto:
+I apologize if this was already reported,
+I just noticed that with the latest updates QEMU doesn't start with the
+following configuration:
+qemu-system-x86_64 -name guest=win10 -machine pc,accel=kvm -cpu host,hv_vpindex,hv_synic ...
+qemu-system-x86_64: failed to turn on HyperV SynIC in KVM: Invalid argument
+qemu-system-x86_64: kvm_init_vcpu failed: Invalid argument
+If I add 'kernel-irqchip=split' or ',kernel-irqchip=on' it starts as
+usual. I bisected this to the following commit:
+commit 11bc4a13d1f4b07dafbd1dda4d4bf0fdd7ad65f2 (HEAD, refs/bisect/bad)
+Author: Paolo Bonzini <
+address@hidden
+>
+Date:   Wed Nov 13 10:56:53 2019 +0100
+    kvm: convert "-machine kernel_irqchip" to an accelerator property
+so aparently we now default to 'kernel_irqchip=off'. Is this the desired
+behavior?
+--
+Vitaly
+
+Commit 11bc4a13d1f4 ("kvm: convert "-machine kernel_irqchip" to an
+accelerator property") moves kernel_irqchip property from "-machine" to
+"-accel kvm", but it forgets to set the default value of
+kernel_irqchip_allowed and kernel_irqchip_split.
+
+Also cleaning up the three useless members (kernel_irqchip_allowed,
+kernel_irqchip_required, kernel_irqchip_split) in struct MachineState.
+
+Fixes: 11bc4a13d1f4 ("kvm: convert "-machine kernel_irqchip" to an accelerator 
+property")
+Signed-off-by: Xiaoyao Li <address@hidden>
+---
+ accel/kvm/kvm-all.c | 3 +++
+ include/hw/boards.h | 3 ---
+ 2 files changed, 3 insertions(+), 3 deletions(-)
+
+diff --git a/accel/kvm/kvm-all.c b/accel/kvm/kvm-all.c
+index b2f1a5bcb5ef..40f74094f8d3 100644
+--- a/accel/kvm/kvm-all.c
++++ b/accel/kvm/kvm-all.c
+@@ -3044,8 +3044,11 @@ bool kvm_kernel_irqchip_split(void)
+ static void kvm_accel_instance_init(Object *obj)
+ {
+     KVMState *s = KVM_STATE(obj);
++    MachineClass *mc = MACHINE_GET_CLASS(current_machine);
+ 
+     s->kvm_shadow_mem = -1;
++    s->kernel_irqchip_allowed = true;
++    s->kernel_irqchip_split = mc->default_kernel_irqchip_split;
+ }
+ 
+ static void kvm_accel_class_init(ObjectClass *oc, void *data)
+diff --git a/include/hw/boards.h b/include/hw/boards.h
+index 61f8bb8e5a42..fb1b43d5b972 100644
+--- a/include/hw/boards.h
++++ b/include/hw/boards.h
+@@ -271,9 +271,6 @@ struct MachineState {
+ 
+     /*< public >*/
+ 
+-    bool kernel_irqchip_allowed;
+-    bool kernel_irqchip_required;
+-    bool kernel_irqchip_split;
+     char *dtb;
+     char *dumpdtb;
+     int phandle_start;
+-- 
+2.19.1
+
+Il sab 28 dic 2019, 09:48 Xiaoyao Li <
+address@hidden
+> ha scritto:
+Commit 11bc4a13d1f4 ("kvm: convert "-machine kernel_irqchip" to an
+accelerator property") moves kernel_irqchip property from "-machine" to
+"-accel kvm", but it forgets to set the default value of
+kernel_irqchip_allowed and kernel_irqchip_split.
+Also cleaning up the three useless members (kernel_irqchip_allowed,
+kernel_irqchip_required, kernel_irqchip_split) in struct MachineState.
+Fixes: 11bc4a13d1f4 ("kvm: convert "-machine kernel_irqchip" to an accelerator property")
+Signed-off-by: Xiaoyao Li <
+address@hidden
+>
+Please also add a Reported-by line for Vitaly Kuznetsov.
+---
+ accel/kvm/kvm-all.c | 3 +++
+ include/hw/boards.h | 3 ---
+ 2 files changed, 3 insertions(+), 3 deletions(-)
+diff --git a/accel/kvm/kvm-all.c b/accel/kvm/kvm-all.c
+index b2f1a5bcb5ef..40f74094f8d3 100644
+--- a/accel/kvm/kvm-all.c
++++ b/accel/kvm/kvm-all.c
+@@ -3044,8 +3044,11 @@ bool kvm_kernel_irqchip_split(void)
+ static void kvm_accel_instance_init(Object *obj)
+ {
+     KVMState *s = KVM_STATE(obj);
++    MachineClass *mc = MACHINE_GET_CLASS(current_machine);
+     s->kvm_shadow_mem = -1;
++    s->kernel_irqchip_allowed = true;
++    s->kernel_irqchip_split = mc->default_kernel_irqchip_split;
+Can you initialize this from the init_machine method instead of assuming that current_machine has been initialized earlier?
+Thanks for the quick fix!
+Paolo
+ }
+ static void kvm_accel_class_init(ObjectClass *oc, void *data)
+diff --git a/include/hw/boards.h b/include/hw/boards.h
+index 61f8bb8e5a42..fb1b43d5b972 100644
+--- a/include/hw/boards.h
++++ b/include/hw/boards.h
+@@ -271,9 +271,6 @@ struct MachineState {
+     /*< public >*/
+-    bool kernel_irqchip_allowed;
+-    bool kernel_irqchip_required;
+-    bool kernel_irqchip_split;
+     char *dtb;
+     char *dumpdtb;
+     int phandle_start;
+--
+2.19.1
+
+On Sat, 2019-12-28 at 10:02 +0000, Paolo Bonzini wrote:
+>
+>
+>
+Il sab 28 dic 2019, 09:48 Xiaoyao Li <address@hidden> ha scritto:
+>
+> Commit 11bc4a13d1f4 ("kvm: convert "-machine kernel_irqchip" to an
+>
+> accelerator property") moves kernel_irqchip property from "-machine" to
+>
+> "-accel kvm", but it forgets to set the default value of
+>
+> kernel_irqchip_allowed and kernel_irqchip_split.
+>
+>
+>
+> Also cleaning up the three useless members (kernel_irqchip_allowed,
+>
+> kernel_irqchip_required, kernel_irqchip_split) in struct MachineState.
+>
+>
+>
+> Fixes: 11bc4a13d1f4 ("kvm: convert "-machine kernel_irqchip" to an
+>
+> accelerator property")
+>
+> Signed-off-by: Xiaoyao Li <address@hidden>
+>
+>
+Please also add a Reported-by line for Vitaly Kuznetsov.
+Sure.
+
+>
+> ---
+>
+>  accel/kvm/kvm-all.c | 3 +++
+>
+>  include/hw/boards.h | 3 ---
+>
+>  2 files changed, 3 insertions(+), 3 deletions(-)
+>
+>
+>
+> diff --git a/accel/kvm/kvm-all.c b/accel/kvm/kvm-all.c
+>
+> index b2f1a5bcb5ef..40f74094f8d3 100644
+>
+> --- a/accel/kvm/kvm-all.c
+>
+> +++ b/accel/kvm/kvm-all.c
+>
+> @@ -3044,8 +3044,11 @@ bool kvm_kernel_irqchip_split(void)
+>
+>  static void kvm_accel_instance_init(Object *obj)
+>
+>  {
+>
+>      KVMState *s = KVM_STATE(obj);
+>
+> +    MachineClass *mc = MACHINE_GET_CLASS(current_machine);
+>
+>
+>
+>      s->kvm_shadow_mem = -1;
+>
+> +    s->kernel_irqchip_allowed = true;
+>
+> +    s->kernel_irqchip_split = mc->default_kernel_irqchip_split;
+>
+>
+Can you initialize this from the init_machine method instead of assuming that
+>
+current_machine has been initialized earlier?
+OK, will do it in v2.
+
+>
+Thanks for the quick fix!
+BTW, it seems that this patch makes kernel_irqchip default on to workaround the
+bug. 
+However, when explicitly configuring kernel_irqchip=off, guest still fails
+booting due to "KVM: failed to send PV IPI: -95" with a latest upstream kernel
+ubuntu guest. Any idea about this? 
+
+>
+Paolo
+>
+>  }
+>
+>
+>
+>  static void kvm_accel_class_init(ObjectClass *oc, void *data)
+>
+> diff --git a/include/hw/boards.h b/include/hw/boards.h
+>
+> index 61f8bb8e5a42..fb1b43d5b972 100644
+>
+> --- a/include/hw/boards.h
+>
+> +++ b/include/hw/boards.h
+>
+> @@ -271,9 +271,6 @@ struct MachineState {
+>
+>
+>
+>      /*< public >*/
+>
+>
+>
+> -    bool kernel_irqchip_allowed;
+>
+> -    bool kernel_irqchip_required;
+>
+> -    bool kernel_irqchip_split;
+>
+>      char *dtb;
+>
+>      char *dumpdtb;
+>
+>      int phandle_start;
+
+Il sab 28 dic 2019, 10:24 Xiaoyao Li <
+address@hidden
+> ha scritto:
+BTW, it seems that this patch makes kernel_irqchip default on to workaround the
+bug.
+However, when explicitly configuring kernel_irqchip=off, guest still fails
+booting due to "KVM: failed to send PV IPI: -95" with a latest upstream kernel
+ubuntu guest. Any idea about this?
+We need to clear the PV IPI feature for userspace irqchip. Are you using -cpu host by chance?
+Paolo
+> Paolo
+> >  }
+> >
+> >  static void kvm_accel_class_init(ObjectClass *oc, void *data)
+> > diff --git a/include/hw/boards.h b/include/hw/boards.h
+> > index 61f8bb8e5a42..fb1b43d5b972 100644
+> > --- a/include/hw/boards.h
+> > +++ b/include/hw/boards.h
+> > @@ -271,9 +271,6 @@ struct MachineState {
+> >
+> >      /*< public >*/
+> >
+> > -    bool kernel_irqchip_allowed;
+> > -    bool kernel_irqchip_required;
+> > -    bool kernel_irqchip_split;
+> >      char *dtb;
+> >      char *dumpdtb;
+> >      int phandle_start;
+
+On Sat, 2019-12-28 at 10:57 +0000, Paolo Bonzini wrote:
+>
+>
+>
+Il sab 28 dic 2019, 10:24 Xiaoyao Li <address@hidden> ha scritto:
+>
+> BTW, it seems that this patch makes kernel_irqchip default on to workaround
+>
+> the
+>
+> bug.
+>
+> However, when explicitly configuring kernel_irqchip=off, guest still fails
+>
+> booting due to "KVM: failed to send PV IPI: -95" with a latest upstream
+>
+> kernel
+>
+> ubuntu guest. Any idea about this?
+>
+>
+We need to clear the PV IPI feature for userspace irqchip. Are you using -cpu
+>
+host by chance?
+Yes, I used -cpu host.
+
+After using "-cpu host,-kvm-pv-ipi" with kernel_irqchip=off, it can boot
+successfully.
+
+>
+Paolo
+>
+>
+> > Paolo
+>
+> > >  }
+>
+> > >
+>
+> > >  static void kvm_accel_class_init(ObjectClass *oc, void *data)
+>
+> > > diff --git a/include/hw/boards.h b/include/hw/boards.h
+>
+> > > index 61f8bb8e5a42..fb1b43d5b972 100644
+>
+> > > --- a/include/hw/boards.h
+>
+> > > +++ b/include/hw/boards.h
+>
+> > > @@ -271,9 +271,6 @@ struct MachineState {
+>
+> > >
+>
+> > >      /*< public >*/
+>
+> > >
+>
+> > > -    bool kernel_irqchip_allowed;
+>
+> > > -    bool kernel_irqchip_required;
+>
+> > > -    bool kernel_irqchip_split;
+>
+> > >      char *dtb;
+>
+> > >      char *dumpdtb;
+>
+> > >      int phandle_start;
+>
+>
+
diff --git a/results/classifier/016/kernel/60339453 b/results/classifier/016/kernel/60339453
new file mode 100644
index 000000000..4be655849
--- /dev/null
+++ b/results/classifier/016/kernel/60339453
@@ -0,0 +1,88 @@
+kernel: 0.931
+boot: 0.878
+operating system: 0.260
+virtual: 0.196
+debug: 0.165
+x86: 0.081
+hypervisor: 0.065
+TCG: 0.062
+register: 0.027
+PID: 0.021
+files: 0.020
+i386: 0.020
+performance: 0.019
+device: 0.018
+risc-v: 0.018
+VMM: 0.017
+architecture: 0.009
+semantic: 0.009
+assembly: 0.008
+arm: 0.007
+ppc: 0.006
+socket: 0.004
+user-level: 0.004
+KVM: 0.003
+alpha: 0.003
+network: 0.003
+permissions: 0.003
+vnc: 0.002
+peripherals: 0.002
+graphic: 0.001
+mistranslation: 0.001
+
+[BUG] scsi: vmw_pvscsi: Boot hangs during scsi under qemu, post commit e662502b3a78
+
+Hi,
+
+Commit e662502b3a78 ("scsi: vmw_pvscsi: Set correct residual data length"),
+and its backports to stable trees, makes kernel hang during boot, when
+ran as a VM under qemu with following parameters:
+
+  -drive file=$DISKFILE,if=none,id=sda
+  -device pvscsi
+  -device scsi-hd,bus=scsi.0,drive=sda
+
+Diving deeper, commit e662502b3a78
+
+  @@ -585,7 +585,13 @@ static void pvscsi_complete_request(struct 
+pvscsi_adapter *adapter,
+                case BTSTAT_SUCCESS:
+  +                     /*
+  +                      * Commands like INQUIRY may transfer less data than
+  +                      * requested by the initiator via bufflen. Set residual
+  +                      * count to make upper layer aware of the actual amount
+  +                      * of data returned.
+  +                      */
+  +                     scsi_set_resid(cmd, scsi_bufflen(cmd) - e->dataLen);
+
+assumes 'e->dataLen' is properly armed with actual num of bytes
+transferred; alas qemu's hw/scsi/vmw_pvscsi.c never arms the 'dataLen'
+field of the completion descriptor (kept zero).
+
+As a result, the residual count is set as the *entire* 'scsi_bufflen' of a
+good transfer, which makes upper scsi layers repeatedly ignore this
+valid transfer.
+
+Not properly arming 'dataLen' seems as an oversight in qemu, which needs
+to be fixed.
+
+However, since kernels with commit e662502b3a78 (and backports) now fail
+to boot under qemu's "-device pvscsi", a suggested workaround is to set
+the residual count *only* if 'e->dataLen' is armed, e.g:
+
+  @@ -588,7 +588,8 @@ static void pvscsi_complete_request(struct pvscsi_adapter 
+*adapter,
+                           * count to make upper layer aware of the actual 
+amount
+                           * of data returned.
+                           */
+  -                       scsi_set_resid(cmd, scsi_bufflen(cmd) - e->dataLen);
+  +                       if (e->dataLen)
+  +                               scsi_set_resid(cmd, scsi_bufflen(cmd) - 
+e->dataLen);
+
+in order to make kernels boot on old qemu binaries.
+
+Best,
+Shmulik
+