1. 29 Apr, 2019 26 commits
  2. 26 Apr, 2019 7 commits
  3. 25 Apr, 2019 4 commits
    • Martin Schwidefsky's avatar
      s390: report new CPU capabilities · a8fd6168
      Martin Schwidefsky authored
      Add hardware capability bits and features tags to /proc/cpuinfo
      for 4 new CPU features:
        "Vector-Enhancements Facility 2" (tag "vxe2", hwcap 2^15)
        "Vector-Packed-Decimal-Enhancement Facility" (tag "vxp", hwcap 2^16)
        "Enhanced-Sort Facility" (tag "sort", hwcap 2^17)
        "Deflate-Conversion Facility" (tag "dflt", hwcap 2^18)
      Reviewed-by: default avatarHeiko Carstens <heiko.carstens@de.ibm.com>
      Signed-off-by: default avatarMartin Schwidefsky <schwidefsky@de.ibm.com>
      a8fd6168
    • Harald Freudenberger's avatar
      s390/crypto: use TRNG for seeding/reseeding · 769f020b
      Harald Freudenberger authored
      With the z14 machine there came also a CPACF hardware extension
      which provides a True Random Number Generator. This TRNG can
      be accessed with a new subfunction code within the CPACF prno
      instruction and provides random data with very high entropy.
      
      So if there is a TRNG available, let's use it for initial seeding
      and reseeding instead of the current implementation which tries
      to generate entropy based on stckf (store clock fast) jitters.
      
      For details about the amount of data needed and pulled for
      seeding and reseeding there can be explaining comments in the
      code found.
      Signed-off-by: default avatarHarald Freudenberger <freude@linux.ibm.com>
      Signed-off-by: default avatarMartin Schwidefsky <schwidefsky@de.ibm.com>
      769f020b
    • Harald Freudenberger's avatar
      s390/crypto: rework generate_entropy function for pseudo random dd · 23d1aee9
      Harald Freudenberger authored
      Here is a rework of the generate_entropy function of the pseudo random
      device driver exploiting the prno CPACF instruction.
      
      George Spelvin pointed out some issues with the existing
      implementation. One point was, that the buffer used to store the stckf
      values is 2 pages which are initially filled with get_random_bytes()
      for each 64 byte junk produced by the function. Another point was that
      the stckf values only carry entropy in the LSB and thus a buffer of
      2 pages is not really needed. Then there was a comment about the use
      of the kimd cpacf function without proper initialization.
      
      The rework addresses these points and now one page is used and only
      one half of this is filled with get_random_bytes() on each chunk of 64
      bytes requested data. The other half of the page is filled with stckf
      values exored into with an overlap of 4 bytes. This can be done due to
      the fact that only the lower 4 bytes carry entropy we need.  For more
      details about the algorithm used, see the header of the function.
      
      The generate_entropy() function now uses the cpacf function klmd with
      proper initialization of the parameter block to perform the sha512
      hash.
      
      George also pointed out some issues with the internal buffers used for
      seeding and reads. These buffers are now zeroed with memzero_implicit
      after use.
      Signed-off-by: default avatarHarald Freudenberger <freude@linux.ibm.com>
      Reported-by: default avatarGeorge Spelvin <lkml@sdf.org>
      Suggested-by: default avatarGeorge Spelvin <lkml@sdf.org>
      Reviewed-by: default avatarPatrick Steuer <steuer@linux.ibm.com>
      Signed-off-by: default avatarMartin Schwidefsky <schwidefsky@de.ibm.com>
      23d1aee9
    • Martin Schwidefsky's avatar
      Merge tag 'vfio-ccw-20190425' of... · 5513bc8e
      Martin Schwidefsky authored
      Merge tag 'vfio-ccw-20190425' of https://git.kernel.org/pub/scm/linux/kernel/git/kvms390/vfio-ccw into features
      
      Pull vfio-ccw from Cornelia Huck with the following changes:
      
       - support for sending halt/clear requests to the device
      
       - various bug fixes
      5513bc8e
  4. 24 Apr, 2019 3 commits
    • Farhan Ali's avatar
      vfio-ccw: Prevent quiesce function going into an infinite loop · d1ffa760
      Farhan Ali authored
      The quiesce function calls cio_cancel_halt_clear() and if we
      get an -EBUSY we go into a loop where we:
      	- wait for any interrupts
      	- flush all I/O in the workqueue
      	- retry cio_cancel_halt_clear
      
      During the period where we are waiting for interrupts or
      flushing all I/O, the channel subsystem could have completed
      a halt/clear action and turned off the corresponding activity
      control bits in the subchannel status word. This means the next
      time we call cio_cancel_halt_clear(), we will again start by
      calling cancel subchannel and so we can be stuck between calling
      cancel and halt forever.
      
      Rather than calling cio_cancel_halt_clear() immediately after
      waiting, let's try to disable the subchannel. If we succeed in
      disabling the subchannel then we know nothing else can happen
      with the device.
      Suggested-by: default avatarEric Farman <farman@linux.ibm.com>
      Signed-off-by: default avatarFarhan Ali <alifm@linux.ibm.com>
      Message-Id: <4d5a4b98ab1b41ac6131b5c36de18b76c5d66898.1555449329.git.alifm@linux.ibm.com>
      Reviewed-by: default avatarEric Farman <farman@linux.ibm.com>
      Acked-by: default avatarHalil Pasic <pasic@linux.ibm.com>
      Signed-off-by: default avatarCornelia Huck <cohuck@redhat.com>
      d1ffa760
    • 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