1. 24 Apr, 2019 8 commits
    • Farhan Ali's avatar
      vfio-ccw: Release any channel program when releasing/removing vfio-ccw mdev · b49bdc86
      Farhan Ali authored
      When releasing the vfio-ccw mdev, we currently do not release
      any existing channel program and its pinned pages. This can
      lead to the following warning:
      
      [1038876.561565] WARNING: CPU: 2 PID: 144727 at drivers/vfio/vfio_iommu_type1.c:1494 vfio_sanity_check_pfn_list+0x40/0x70 [vfio_iommu_type1]
      
      ....
      
      1038876.561921] Call Trace:
      [1038876.561935] ([<00000009897fb870>] 0x9897fb870)
      [1038876.561949]  [<000003ff8013bf62>] vfio_iommu_type1_detach_group+0xda/0x2f0 [vfio_iommu_type1]
      [1038876.561965]  [<000003ff8007b634>] __vfio_group_unset_container+0x64/0x190 [vfio]
      [1038876.561978]  [<000003ff8007b87e>] vfio_group_put_external_user+0x26/0x38 [vfio]
      [1038876.562024]  [<000003ff806fc608>] kvm_vfio_group_put_external_user+0x40/0x60 [kvm]
      [1038876.562045]  [<000003ff806fcb9e>] kvm_vfio_destroy+0x5e/0xd0 [kvm]
      [1038876.562065]  [<000003ff806f63fc>] kvm_put_kvm+0x2a4/0x3d0 [kvm]
      [1038876.562083]  [<000003ff806f655e>] kvm_vm_release+0x36/0x48 [kvm]
      [1038876.562098]  [<00000000003c2dc4>] __fput+0x144/0x228
      [1038876.562113]  [<000000000016ee82>] task_work_run+0x8a/0xd8
      [1038876.562125]  [<000000000014c7a8>] do_exit+0x5d8/0xd90
      [1038876.562140]  [<000000000014d084>] do_group_exit+0xc4/0xc8
      [1038876.562155]  [<000000000015c046>] get_signal+0x9ae/0xa68
      [1038876.562169]  [<0000000000108d66>] do_signal+0x66/0x768
      [1038876.562185]  [<0000000000b9e37e>] system_call+0x1ea/0x2d8
      [1038876.562195] 2 locks held by qemu-system-s39/144727:
      [1038876.562205]  #0: 00000000537abaf9 (&container->group_lock){++++}, at: __vfio_group_unset_container+0x3c/0x190 [vfio]
      [1038876.562230]  #1: 00000000670008b5 (&iommu->lock){+.+.}, at: vfio_iommu_type1_detach_group+0x36/0x2f0 [vfio_iommu_type1]
      [1038876.562250] Last Breaking-Event-Address:
      [1038876.562262]  [<000003ff8013aa24>] vfio_sanity_check_pfn_list+0x3c/0x70 [vfio_iommu_type1]
      [1038876.562272] irq event stamp: 4236481
      [1038876.562287] hardirqs last  enabled at (4236489): [<00000000001cee7a>] console_unlock+0x6d2/0x740
      [1038876.562299] hardirqs last disabled at (4236496): [<00000000001ce87e>] console_unlock+0xd6/0x740
      [1038876.562311] softirqs last  enabled at (4234162): [<0000000000b9fa1e>] __do_softirq+0x556/0x598
      [1038876.562325] softirqs last disabled at (4234153): [<000000000014e4cc>] irq_exit+0xac/0x108
      [1038876.562337] ---[ end trace 6c96d467b1c3ca06 ]---
      
      Similarly we do not free the channel program when we are removing
      the vfio-ccw device. Let's fix this by resetting the device and freeing
      the channel program and pinned pages in the release path. For the remove
      path we can just quiesce the device, since in the remove path the mediated
      device is going away for good and so we don't need to do a full reset.
      Signed-off-by: default avatarFarhan Ali <alifm@linux.ibm.com>
      Message-Id: <ae9f20dc8873f2027f7b3c5d2aaa0bdfe06850b8.1554756534.git.alifm@linux.ibm.com>
      Acked-by: default avatarEric Farman <farman@linux.ibm.com>
      Signed-off-by: default avatarCornelia Huck <cohuck@redhat.com>
      b49bdc86
    • Farhan Ali's avatar
      vfio-ccw: Do not call flush_workqueue while holding the spinlock · cea5dde4
      Farhan Ali authored
      Currently we call flush_workqueue while holding the subchannel
      spinlock. But flush_workqueue function can go to sleep, so
      do not call the function while holding the spinlock.
      
      Fixes the following bug:
      
      [  285.203430] BUG: scheduling while atomic: bash/14193/0x00000002
      [  285.203434] INFO: lockdep is turned off.
      ....
      [  285.203485] Preemption disabled at:
      [  285.203488] [<000003ff80243e5c>] vfio_ccw_sch_quiesce+0xbc/0x120 [vfio_ccw]
      [  285.203496] CPU: 7 PID: 14193 Comm: bash Tainted: G        W
      ....
      [  285.203504] Call Trace:
      [  285.203510] ([<0000000000113772>] show_stack+0x82/0xd0)
      [  285.203514]  [<0000000000b7a102>] dump_stack+0x92/0xd0
      [  285.203518]  [<000000000017b8be>] __schedule_bug+0xde/0xf8
      [  285.203524]  [<0000000000b95b5a>] __schedule+0x7a/0xc38
      [  285.203528]  [<0000000000b9678a>] schedule+0x72/0xb0
      [  285.203533]  [<0000000000b9bfbc>] schedule_timeout+0x34/0x528
      [  285.203538]  [<0000000000b97608>] wait_for_common+0x118/0x1b0
      [  285.203544]  [<0000000000166d6a>] flush_workqueue+0x182/0x548
      [  285.203550]  [<000003ff80243e6e>] vfio_ccw_sch_quiesce+0xce/0x120 [vfio_ccw]
      [  285.203556]  [<000003ff80245278>] vfio_ccw_mdev_reset+0x38/0x70 [vfio_ccw]
      [  285.203562]  [<000003ff802458b0>] vfio_ccw_mdev_remove+0x40/0x78 [vfio_ccw]
      [  285.203567]  [<000003ff801a499c>] mdev_device_remove_ops+0x3c/0x80 [mdev]
      [  285.203573]  [<000003ff801a4d5c>] mdev_device_remove+0xc4/0x130 [mdev]
      [  285.203578]  [<000003ff801a5074>] remove_store+0x6c/0xa8 [mdev]
      [  285.203582]  [<000000000046f494>] kernfs_fop_write+0x14c/0x1f8
      [  285.203588]  [<00000000003c1530>] __vfs_write+0x38/0x1a8
      [  285.203593]  [<00000000003c187c>] vfs_write+0xb4/0x198
      [  285.203597]  [<00000000003c1af2>] ksys_write+0x5a/0xb0
      [  285.203601]  [<0000000000b9e270>] system_call+0xdc/0x2d8
      Signed-off-by: default avatarFarhan Ali <alifm@linux.ibm.com>
      Reviewed-by: default avatarEric Farman <farman@linux.ibm.com>
      Reviewed-by: default avatarPierre Morel <pmorel@linux.ibm.com>
      Message-Id: <626bab8bb2958ae132452e1ddaf1b20882ad5a9d.1554756534.git.alifm@linux.ibm.com>
      Signed-off-by: default avatarCornelia Huck <cohuck@redhat.com>
      cea5dde4
    • Cornelia Huck's avatar
      vfio-ccw: add handling for async channel instructions · d5afd5d1
      Cornelia Huck authored
      Add a region to the vfio-ccw device that can be used to submit
      asynchronous I/O instructions. ssch continues to be handled by the
      existing I/O region; the new region handles hsch and csch.
      
      Interrupt status continues to be reported through the same channels
      as for ssch.
      Acked-by: default avatarEric Farman <farman@linux.ibm.com>
      Reviewed-by: default avatarFarhan Ali <alifm@linux.ibm.com>
      Signed-off-by: default avatarCornelia Huck <cohuck@redhat.com>
      d5afd5d1
    • Cornelia Huck's avatar
      s390/cio: export hsch to modules · b0940857
      Cornelia Huck authored
      The vfio-ccw code will need this, and it matches treatment of ssch
      and csch.
      Reviewed-by: default avatarPierre Morel <pmorel@linux.ibm.com>
      Reviewed-by: default avatarHalil Pasic <pasic@linux.ibm.com>
      Signed-off-by: default avatarCornelia Huck <cohuck@redhat.com>
      b0940857
    • Cornelia Huck's avatar
      vfio-ccw: add capabilities chain · db8e5d17
      Cornelia Huck authored
      Allow to extend the regions used by vfio-ccw. The first user will be
      handling of halt and clear subchannel.
      Reviewed-by: default avatarEric Farman <farman@linux.ibm.com>
      Reviewed-by: default avatarFarhan Ali <alifm@linux.ibm.com>
      Signed-off-by: default avatarCornelia Huck <cohuck@redhat.com>
      db8e5d17
    • Cornelia Huck's avatar
      vfio-ccw: protect the I/O region · 4f766173
      Cornelia Huck authored
      Introduce a mutex to disallow concurrent reads or writes to the
      I/O region. This makes sure that the data the kernel or user
      space see is always consistent.
      
      The same mutex will be used to protect the async region as well.
      Reviewed-by: default avatarEric Farman <farman@linux.ibm.com>
      Signed-off-by: default avatarCornelia Huck <cohuck@redhat.com>
      4f766173
    • Cornelia Huck's avatar
      vfio-ccw: rework ssch state handling · 690f6a15
      Cornelia Huck authored
      The flow for processing ssch requests can be improved by splitting
      the BUSY state:
      
      - CP_PROCESSING: We reject any user space requests while we are in
        the process of translating a channel program and submitting it to
        the hardware. Use -EAGAIN to signal user space that it should
        retry the request.
      - CP_PENDING: We have successfully submitted a request with ssch and
        are now expecting an interrupt. As we can't handle more than one
        channel program being processed, reject any further requests with
        -EBUSY. A final interrupt will move us out of this state.
        By making this a separate state, we make it possible to issue a
        halt or a clear while we're still waiting for the final interrupt
        for the ssch (in a follow-on patch).
      
      It also makes a lot of sense not to preemptively filter out writes to
      the io_region if we're in an incorrect state: the state machine will
      handle this correctly.
      Reviewed-by: default avatarEric Farman <farman@linux.ibm.com>
      Signed-off-by: default avatarCornelia Huck <cohuck@redhat.com>
      690f6a15
    • Cornelia Huck's avatar
      vfio-ccw: make it safe to access channel programs · 71189f26
      Cornelia Huck authored
      When we get a solicited interrupt, the start function may have
      been cleared by a csch, but we still have a channel program
      structure allocated. Make it safe to call the cp accessors in
      any case, so we can call them unconditionally.
      
      While at it, also make sure that functions called from other parts
      of the code return gracefully if the channel program structure
      has not been initialized (even though that is a bug in the caller).
      Reviewed-by: default avatarEric Farman <farman@linux.ibm.com>
      Reviewed-by: default avatarFarhan Ali <alifm@linux.ibm.com>
      Signed-off-by: default avatarCornelia Huck <cohuck@redhat.com>
      71189f26
  2. 23 Apr, 2019 3 commits
  3. 18 Apr, 2019 2 commits
  4. 11 Apr, 2019 9 commits
    • Arnd Bergmann's avatar
      s390: zcrypt: initialize variables before_use · 913140e2
      Arnd Bergmann authored
      The 'func_code' variable gets printed in debug statements without
      a prior initialization in multiple functions, as reported when building
      with clang:
      
      drivers/s390/crypto/zcrypt_api.c:659:6: warning: variable 'func_code' is used uninitialized whenever 'if' condition is true
            [-Wsometimes-uninitialized]
              if (mex->outputdatalength < mex->inputdatalength) {
                  ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      drivers/s390/crypto/zcrypt_api.c:725:29: note: uninitialized use occurs here
              trace_s390_zcrypt_rep(mex, func_code, rc,
                                         ^~~~~~~~~
      drivers/s390/crypto/zcrypt_api.c:659:2: note: remove the 'if' if its condition is always false
              if (mex->outputdatalength < mex->inputdatalength) {
              ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      drivers/s390/crypto/zcrypt_api.c:654:24: note: initialize the variable 'func_code' to silence this warning
              unsigned int func_code;
                                    ^
      
      Add initializations to all affected code paths to shut up the warning
      and make the warning output consistent.
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarMartin Schwidefsky <schwidefsky@de.ibm.com>
      913140e2
    • Arnd Bergmann's avatar
      s390: avoid __builtin_return_address(n) on clang · 6e042492
      Arnd Bergmann authored
      llvm on s390 has problems with __builtin_return_address(n), with n>0,
      this results in a somewhat cryptic error message:
      
      fatal error: error in backend: Unsupported stack frame traversal count
      
      To work around it, use the direct return address directly. This
      is probably not ideal here, but gets things to compile and should
      only lead to inferior reporting, not to misbehavior of the generated
      code.
      
      Link: https://bugs.llvm.org/show_bug.cgi?id=41424Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarMartin Schwidefsky <schwidefsky@de.ibm.com>
      6e042492
    • Joe Perches's avatar
      s390: Convert IS_ENABLED uses to __is_defined · 475c8e9e
      Joe Perches authored
      IS_ENABLED should be reserved for CONFIG_<FOO> uses so convert
      the uses of IS_ENABLED with a #define to __is_defined.
      Signed-off-by: default avatarJoe Perches <joe@perches.com>
      Signed-off-by: default avatarMartin Schwidefsky <schwidefsky@de.ibm.com>
      475c8e9e
    • Arnd Bergmann's avatar
      s390: make chkbss work with clang · 9a0ceb9c
      Arnd Bergmann authored
      llvm skips an empty .bss section entirely, which makes
      the check fail with an unexpected error:
      
      /tmp/binutils-multi-test/bin/s390x-linux-gnu-objdump: section '.bss' mentioned in a -j option, but not found in any input file
      error: arch/s390/boot/compressed/decompressor.o .bss section is not empty
      ../arch/s390/scripts/Makefile.chkbss:20: recipe for target 'arch/s390/boot/compressed/decompressor.o.chkbss' failed
      
      Change the check so we first see if a .bss section exists
      before trying to read its size.
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarMartin Schwidefsky <schwidefsky@de.ibm.com>
      9a0ceb9c
    • Arnd Bergmann's avatar
      s390: make __load_psw_mask work with clang · 0a113efc
      Arnd Bergmann authored
      clang fails to use the %O and %R inline assembly modifiers
      the same way as gcc, leading to build failures with every use
      of __load_psw_mask():
      
      /tmp/nmi-4a9f80.s: Assembler messages:
      /tmp/nmi-4a9f80.s:571: Error: junk at end of line: `+8(160(%r11))'
      /tmp/nmi-4a9f80.s:626: Error: junk at end of line: `+8(160(%r11))'
      
      Replace these with a more conventional way of passing the addresses
      that should work with both clang and gcc.
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarMartin Schwidefsky <schwidefsky@de.ibm.com>
      0a113efc
    • Arnd Bergmann's avatar
      s390: syscall_wrapper: avoid clang warning · efb150df
      Arnd Bergmann authored
      Building system calls with clang results in a warning
      about an alias from a global function to a static one:
      
      ../fs/namei.c:3847:1: warning: unused function '__se_sys_mkdirat' [-Wunused-function]
      SYSCALL_DEFINE3(mkdirat, int, dfd, const char __user *, pathname, umode_t, mode)
      ^
      ../include/linux/syscalls.h:219:36: note: expanded from macro 'SYSCALL_DEFINE3'
       #define SYSCALL_DEFINE3(name, ...) SYSCALL_DEFINEx(3, _##name, __VA_ARGS__)
                                         ^
      ../include/linux/syscalls.h:228:2: note: expanded from macro 'SYSCALL_DEFINEx'
              __SYSCALL_DEFINEx(x, sname, __VA_ARGS__)
              ^
      ../arch/s390/include/asm/syscall_wrapper.h:126:18: note: expanded from macro '__SYSCALL_DEFINEx'
              asmlinkage long __se_sys##name(__MAP(x,__SC_LONG,__VA_ARGS__))          \
                              ^
      <scratch space>:31:1: note: expanded from here
      __se_sys_mkdirat
      ^
      
      The only reference to the static __se_sys_mkdirat() here is the alias, but
      this only gets evaluated later. Making this function global as well avoids
      the warning.
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarMartin Schwidefsky <schwidefsky@de.ibm.com>
      efb150df
    • Arnd Bergmann's avatar
      s390: don't build vdso32 with clang · 96ca7674
      Arnd Bergmann authored
      clang does not support 31 bit object files on s390, so skip
      the 32-bit vdso here, and only build it when using gcc to compile
      the kernel.
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarMartin Schwidefsky <schwidefsky@de.ibm.com>
      96ca7674
    • Arnd Bergmann's avatar
      s390: remove -fno-strength-reduce flag · c1afcaec
      Arnd Bergmann authored
      This was added as a workaround for really old compilers, and it prevents
      building with clang now. I can see no reason for keeping it, as it has
      already been removed for most architectures in the pre-git era, so
      let's remove it everywhere, rather than only for clang.
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarMartin Schwidefsky <schwidefsky@de.ibm.com>
      c1afcaec
    • Martin Schwidefsky's avatar
      s390: fine-tune stack switch helper · 7aa0055e
      Martin Schwidefsky authored
      The CALL_ON_STACK helper currently does not work with clang and for
      calls without arguments. It does not initialize r2 although the constraint
      is "+&d". Rework the CALL_FMT_x and the CALL_ON_STACK macros to work
      with clang and produce optimal code in all cases.
      Reported-by: default avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarMartin Schwidefsky <schwidefsky@de.ibm.com>
      7aa0055e
  5. 10 Apr, 2019 13 commits
  6. 29 Mar, 2019 5 commits