1. 08 Nov, 2017 2 commits
    • Harald Freudenberger's avatar
      s390/archrandom: Reconsider s390 arch random implementation · f44fa887
      Harald Freudenberger authored
      The reworked version of the random device driver now calls
      the arch_get_random_* functions on a very high frequency.
      It does about 100.000 calls to arch_get_random_long for
      providing 10 MB via /dev/urandom. Each invocation was
      fetching entropy from the hardware random generator which
      has a rate limit of about 4 MB/s. As the trng invocation
      waits until enough entropy is gathered, the random device
      driver is slowed down dramatically.
      
      The s390 true random generator is not designed for such
      a high rate. The TRNG is more designed to be used together
      with the arch_get_random_seed_* functions. This is similar
      to the way how powerpc has implemented their arch random
      functionality.
      
      This patch removes the invocations of the s390 TRNG for
      arch_get_random_long() and arch_get_random_int() but leaving
      the invocations for arch_get_random_seed_long() and
      arch_get_random_seed_int(). So the s390 arch random
      implementation now contributes high quality entropy to
      the kernel random device for reseeding.
      Signed-off-by: default avatarHarald Freudenberger <freude@linux.vnet.ibm.com>
      Signed-off-by: default avatarHeiko Carstens <heiko.carstens@de.ibm.com>
      f44fa887
    • Christian Borntraeger's avatar
      s390/pci: do not require AIS facility · 48070c73
      Christian Borntraeger authored
      As of today QEMU does not provide the AIS facility to its guest.  This
      prevents Linux guests from using PCI devices as the ais facility is
      checked during init. As this is just a performance optimization, we can
      move the ais check into the code where we need it (calling the SIC
      instruction). This is used at initialization and on interrupt. Both
      places do not require any serialization, so we can simply skip the
      instruction.
      
      Since we will now get all interrupts, we can also avoid the 2nd scan.
      As we can have multiple interrupts in parallel we might trigger spurious
      irqs more often for the non-AIS case but the core code can handle that.
      Signed-off-by: default avatarChristian Borntraeger <borntraeger@de.ibm.com>
      Reviewed-by: default avatarPierre Morel <pmorel@linux.vnet.ibm.com>
      Reviewed-by: default avatarHalil Pasic <pasic@linux.vnet.ibm.com>
      Acked-by: default avatarSebastian Ott <sebott@linux.vnet.ibm.com>
      Signed-off-by: default avatarHeiko Carstens <heiko.carstens@de.ibm.com>
      48070c73
  2. 03 Nov, 2017 2 commits
  3. 02 Nov, 2017 2 commits
  4. 26 Oct, 2017 3 commits
  5. 23 Oct, 2017 3 commits
  6. 19 Oct, 2017 5 commits
  7. 18 Oct, 2017 7 commits
  8. 16 Oct, 2017 6 commits
  9. 12 Oct, 2017 1 commit
  10. 09 Oct, 2017 8 commits
  11. 04 Oct, 2017 1 commit
    • Heiko Carstens's avatar
      s390: use generic rwsem implementation · 91a1fad7
      Heiko Carstens authored
      We never optimized our rwsem inline assemblies to make use of the new
      atomic instructions. The generic rwsem implementation implicitly makes
      use of the new instructions, since it implements the required rwsem
      primitives with atomic operations, which we did optimize.
      
      However even when compiling for old architectures the generic variant
      still generates better code. So it's time to simply remove our old
      code and switch to the generic implementation.
      Signed-off-by: default avatarHeiko Carstens <heiko.carstens@de.ibm.com>
      Signed-off-by: default avatarMartin Schwidefsky <schwidefsky@de.ibm.com>
      91a1fad7