1. 29 Apr, 2019 20 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 9 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
    • 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