1. 22 4月, 2020 28 次提交
  2. 21 4月, 2020 8 次提交
  3. 20 4月, 2020 4 次提交
    • M
      vhost: disable for OABI · d085eb8c
      Michael S. Tsirkin 提交于
      vhost is currently broken on the some ARM configs.
      
      The reason is that the ring element addresses are passed between
      components with different alignments assumptions. Thus, if
      guest selects a pointer and host then gets and dereferences
      it, then alignment assumed by the host's compiler might be
      greater than the actual alignment of the pointer.
      compiler on the host from assuming pointer is aligned.
      
      This actually triggers on ARM with -mabi=apcs-gnu - which is a
      deprecated configuration. With this OABI, compiler assumes that
      all structures are 4 byte aligned - which is stronger than
      virtio guarantees for available and used rings, which are
      merely 2 bytes. Thus a guest without -mabi=apcs-gnu running
      on top of host with -mabi=apcs-gnu will be broken.
      
      The correct fix is to force alignment of structures - however
      that is an intrusive fix that's best deferred until the next release.
      
      We didn't previously support such ancient systems at all - this surfaced
      after vdpa support prompted removing dependency of vhost on
      VIRTULIZATION. So for now, let's just add something along the lines of
      
      	depends on !ARM || AEABI
      
      to the virtio Kconfig declaration, and add a comment that it has to do
      with struct member alignment.
      
      Note: we can't make VHOST and VHOST_RING themselves have
      a dependency since these are selected. Add a new symbol for that.
      
      We should be able to drop this dependency down the road.
      
      Fixes: 20c384f1 ("vhost: refine vhost and vringh kconfig")
      Suggested-by: NArd Biesheuvel <ardb@kernel.org>
      Suggested-by: NRichard Earnshaw <Richard.Earnshaw@arm.com>
      Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
      d085eb8c
    • C
    • E
      KVM: s390: Fix PV check in deliverable_irqs() · d47c4c45
      Eric Farman 提交于
      The diag 0x44 handler, which handles a directed yield, goes into a
      a codepath that does a kvm_for_each_vcpu() and ultimately
      deliverable_irqs().  The new check for kvm_s390_pv_cpu_is_protected()
      contains an assertion that the vcpu->mutex is held, which isn't going
      to be the case in this scenario.
      
      The result is a plethora of these messages if the lock debugging
      is enabled, and thus an implication that we have a problem.
      
        WARNING: CPU: 9 PID: 16167 at arch/s390/kvm/kvm-s390.h:239 deliverable_irqs+0x1c6/0x1d0 [kvm]
        ...snip...
        Call Trace:
         [<000003ff80429bf2>] deliverable_irqs+0x1ca/0x1d0 [kvm]
        ([<000003ff80429b34>] deliverable_irqs+0x10c/0x1d0 [kvm])
         [<000003ff8042ba82>] kvm_s390_vcpu_has_irq+0x2a/0xa8 [kvm]
         [<000003ff804101e2>] kvm_arch_dy_runnable+0x22/0x38 [kvm]
         [<000003ff80410284>] kvm_vcpu_on_spin+0x8c/0x1d0 [kvm]
         [<000003ff80436888>] kvm_s390_handle_diag+0x3b0/0x768 [kvm]
         [<000003ff80425af4>] kvm_handle_sie_intercept+0x1cc/0xcd0 [kvm]
         [<000003ff80422bb0>] __vcpu_run+0x7b8/0xfd0 [kvm]
         [<000003ff80423de6>] kvm_arch_vcpu_ioctl_run+0xee/0x3e0 [kvm]
         [<000003ff8040ccd8>] kvm_vcpu_ioctl+0x2c8/0x8d0 [kvm]
         [<00000001504ced06>] ksys_ioctl+0xae/0xe8
         [<00000001504cedaa>] __s390x_sys_ioctl+0x2a/0x38
         [<0000000150cb9034>] system_call+0xd8/0x2d8
        2 locks held by CPU 2/KVM/16167:
         #0: 00000001951980c0 (&vcpu->mutex){+.+.}, at: kvm_vcpu_ioctl+0x90/0x8d0 [kvm]
         #1: 000000019599c0f0 (&kvm->srcu){....}, at: __vcpu_run+0x4bc/0xfd0 [kvm]
        Last Breaking-Event-Address:
         [<000003ff80429b34>] deliverable_irqs+0x10c/0x1d0 [kvm]
        irq event stamp: 11967
        hardirqs last  enabled at (11975): [<00000001502992f2>] console_unlock+0x4ca/0x650
        hardirqs last disabled at (11982): [<0000000150298ee8>] console_unlock+0xc0/0x650
        softirqs last  enabled at (7940): [<0000000150cba6ca>] __do_softirq+0x422/0x4d8
        softirqs last disabled at (7929): [<00000001501cd688>] do_softirq_own_stack+0x70/0x80
      
      Considering what's being done here, let's fix this by removing the
      mutex assertion rather than acquiring the mutex for every other vcpu.
      
      Fixes: 201ae986 ("KVM: s390: protvirt: Implement interrupt injection")
      Signed-off-by: NEric Farman <farman@linux.ibm.com>
      Signed-off-by: NChristian Borntraeger <borntraeger@de.ibm.com>
      Reviewed-by: NChristian Borntraeger <borntraeger@de.ibm.com>
      Reviewed-by: NCornelia Huck <cohuck@redhat.com>
      Link: https://lore.kernel.org/r/20200415190353.63625-1-farman@linux.ibm.comSigned-off-by: NChristian Borntraeger <borntraeger@de.ibm.com>
      d47c4c45
    • L
      Linux 5.7-rc2 · ae83d0b4
      Linus Torvalds 提交于
      ae83d0b4
新手
引导
客服 返回
顶部