1. 24 Aug, 2016 1 commit
  2. 04 Aug, 2016 1 commit
    • Krzysztof Kozlowski's avatar
      dma-mapping: use unsigned long for dma_attrs · 00085f1e
      Krzysztof Kozlowski authored
      The dma-mapping core and the implementations do not change the DMA
      attributes passed by pointer.  Thus the pointer can point to const data.
      However the attributes do not have to be a bitfield.  Instead unsigned
      long will do fine:
      1. This is just simpler.  Both in terms of reading the code and setting
         attributes.  Instead of initializing local attributes on the stack
         and passing pointer to it to dma_set_attr(), just set the bits.
      2. It brings safeness and checking for const correctness because the
         attributes are passed by value.
      Semantic patches for this change (at least most of them):
          virtual patch
          virtual context
          identifier f, attrs;
          - struct dma_attrs *attrs
          + unsigned long attrs
          , ...)
          identifier r.f;
          - NULL
          + 0
          // Options: --all-includes
          virtual patch
          virtual context
          identifier f, attrs;
          type t;
          t f(..., struct dma_attrs *attrs);
          identifier r.f;
          - NULL
          + 0
      Link: http://lkml.kernel.org/r/1468399300-5399-2-git-send-email-k.kozlowski@samsung.comSigned-off-by: default avatarKrzysztof Kozlowski <k.kozlowski@samsung.com>
      Acked-by: default avatarVineet Gupta <vgupta@synopsys.com>
      Acked-by: default avatarRobin Murphy <robin.murphy@arm.com>
      Acked-by: default avatarHans-Christian Noren Egtvedt <egtvedt@samfundet.no>
      Acked-by: Mark Salter <msalter@redhat.com> [c6x]
      Acked-by: Jesper Nilsson <jesper.nilsson@axis.com> [cris]
      Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> [drm]
      Reviewed-by: default avatarBart Van Assche <bart.vanassche@sandisk.com>
      Acked-by: Joerg Roedel <jroedel@suse.de> [iommu]
      Acked-by: Fabien Dessenne <fabien.dessenne@st.com> [bdisp]
      Reviewed-by: Marek Szyprowski <m.szyprowski@samsung.com> [vb2-core]
      Acked-by: David Vrabel <david.vrabel@citrix.com> [xen]
      Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> [xen swiotlb]
      Acked-by: Joerg Roedel <jroedel@suse.de> [iommu]
      Acked-by: Richard Kuo <rkuo@codeaurora.org> [hexagon]
      Acked-by: Geert Uytterhoeven <geert@linux-m68k.org> [m68k]
      Acked-by: Gerald Schaefer <gerald.schaefer@de.ibm.com> [s390]
      Acked-by: default avatarBjorn Andersson <bjorn.andersson@linaro.org>
      Acked-by: Hans-Christian Noren Egtvedt <egtvedt@samfundet.no> [avr32]
      Acked-by: Vineet Gupta <vgupta@synopsys.com> [arc]
      Acked-by: Robin Murphy <robin.murphy@arm.com> [arm64 and dma-iommu]
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
  3. 26 Jul, 2016 2 commits
    • Vlastimil Babka's avatar
      mm, frontswap: convert frontswap_enabled to static key · 8ea1d2a1
      Vlastimil Babka authored
      I have noticed that frontswap.h first declares "frontswap_enabled" as
      extern bool variable, and then overrides it with "#define
      frontswap_enabled (1)" for CONFIG_FRONTSWAP=Y or (0) when disabled.  The
      bool variable isn't actually instantiated anywhere.
      This all looks like an unfinished attempt to make frontswap_enabled
      reflect whether a backend is instantiated.  But in the current state,
      all frontswap hooks call unconditionally into frontswap.c just to check
      if frontswap_ops is non-NULL.  This should at least be checked inline,
      but we can further eliminate the overhead when CONFIG_FRONTSWAP is
      enabled and no backend registered, using a static key that is initially
      disabled, and gets enabled only upon first backend registration.
      Thus, checks for "frontswap_enabled" are replaced with
      "frontswap_enabled()" wrapping the static key check.  There are two
      - xen's selfballoon_process() was testing frontswap_enabled in code guarded
        by #ifdef CONFIG_FRONTSWAP, which was effectively always true when reachable.
        The patch just removes this check. Using frontswap_enabled() does not sound
        correct here, as this can be true even without xen's own backend being
      - in SYSCALL_DEFINE2(swapon), change the check to IS_ENABLED(CONFIG_FRONTSWAP)
        as it seems the bitmap allocation cannot currently be postponed until a
        backend is registered. This means that frontswap will still have some
        memory overhead by being configured, but without a backend.
      After the patch, we can expect that some functions in frontswap.c are
      called only when frontswap_ops is non-NULL.  Change the checks there to
      VM_BUG_ONs.  While at it, convert other BUG_ONs to VM_BUG_ONs as
      frontswap has been stable for some time.
      [akpm@linux-foundation.org: coding-style fixes]
      Link: http://lkml.kernel.org/r/1463152235-9717-1-git-send-email-vbabka@suse.czSigned-off-by: default avatarVlastimil Babka <vbabka@suse.cz>
      Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>
      Cc: David Vrabel <david.vrabel@citrix.com>
      Cc: Juergen Gross <jgross@suse.com>
      Cc: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
    • Juergen Gross's avatar
      xen: add static initialization of steal_clock op to xen_time_ops · d34c30cc
      Juergen Gross authored
      pv_time_ops might be overwritten with xen_time_ops after the
      steal_clock operation has been initialized already. To prevent calling
      a now uninitialized function pointer add the steal_clock static
      initialization to xen_time_ops.
      Signed-off-by: default avatarJuergen Gross <jgross@suse.com>
      Signed-off-by: default avatarDavid Vrabel <david.vrabel@citrix.com>
  4. 25 Jul, 2016 5 commits
  5. 08 Jul, 2016 3 commits
    • Jan Beulich's avatar
      xen/acpi: allow xen-acpi-processor driver to load on Xen 4.7 · 6f2d9d99
      Jan Beulich authored
      As of Xen 4.7 PV CPUID doesn't expose either of CPUID[1].ECX[7] and
      CPUID[0x80000007].EDX[7] anymore, causing the driver to fail to load on
      both Intel and AMD systems. Doing any kind of hardware capability
      checks in the driver as a prerequisite was wrong anyway: With the
      hypervisor being in charge, all such checking should be done by it. If
      ACPI data gets uploaded despite some missing capability, the hypervisor
      is free to ignore part or all of that data.
      Ditch the entire check_prereq() function, and do the only valid check
      (xen_initial_domain()) in the caller in its place.
      Signed-off-by: default avatarJan Beulich <jbeulich@suse.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarDavid Vrabel <david.vrabel@citrix.com>
    • Jan Beulich's avatar
      xenbus: simplify xenbus_dev_request_and_reply() · e5a79475
      Jan Beulich authored
      No need to retain a local copy of the full request message, only the
      type is really needed.
      Signed-off-by: default avatarJan Beulich <jbeulich@suse.com>
      Signed-off-by: default avatarDavid Vrabel <david.vrabel@citrix.com>
    • Jan Beulich's avatar
      xenbus: don't bail early from xenbus_dev_request_and_reply() · 7469be95
      Jan Beulich authored
      xenbus_dev_request_and_reply() needs to track whether a transaction is
      open.  For XS_TRANSACTION_START messages it calls transaction_start()
      and for XS_TRANSACTION_END messages it calls transaction_end().
      If sending an XS_TRANSACTION_START message fails or responds with an
      an error, the transaction is not open and transaction_end() must be
      If sending an XS_TRANSACTION_END message fails, the transaction is
      still open, but if an error response is returned the transaction is
      Commit 027bd7e8 ("xen/xenbus: Avoid synchronous wait on XenBus
      stalling shutdown/restart") introduced a regression where failed
      XS_TRANSACTION_START messages were leaving the transaction open.  This
      can cause problems with suspend (and migration) as all transactions
      must be closed before suspending.
      It appears that the problematic change was added accidentally, so just
      remove it.
      Signed-off-by: default avatarJan Beulich <jbeulich@suse.com>
      Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarDavid Vrabel <david.vrabel@citrix.com>
  6. 07 Jul, 2016 1 commit
  7. 06 Jul, 2016 18 commits
  8. 24 Jun, 2016 1 commit
    • Jan Beulich's avatar
      xen-pciback: return proper values during BAR sizing · d2bd05d8
      Jan Beulich authored
      Reads following writes with all address bits set to 1 should return all
      changeable address bits as one, not the BAR size (nor, as was the case
      for the upper half of 64-bit BARs, the high half of the region's end
      address). Presumably this didn't cause any problems so far because
      consumers use the value to calculate the size (usually via val & -val),
      and do nothing else with it.
      But also consider the exception here: Unimplemented BARs should always
      return all zeroes.
      And finally, the check for whether to return the sizing address on read
      for the ROM BAR should ignore all non-address bits, not just the ROM
      Enable one.
      Signed-off-by: default avatarJan Beulich <jbeulich@suse.com>
      Reviewed-by: default avatarBoris Ostrovsky <boris.ostrovsky@oracle.com>
      Signed-off-by: default avatarDavid Vrabel <david.vrabel@citrix.com>
  9. 23 Jun, 2016 2 commits
  10. 24 May, 2016 3 commits
    • Ross Lagerwall's avatar
      xen/events: Don't move disabled irqs · f0f39387
      Ross Lagerwall authored
      Commit ff1e22e7 ("xen/events: Mask a moving irq") open-coded
      irq_move_irq() but left out checking if the IRQ is disabled. This broke
      resuming from suspend since it tries to move a (disabled) irq without
      holding the IRQ's desc->lock. Fix it by adding in a check for disabled
      The resulting stacktrace was:
      kernel BUG at /build/linux-UbQGH5/linux-4.4.0/kernel/irq/migration.c:31!
      invalid opcode: 0000 [#1] SMP
      Modules linked in: xenfs xen_privcmd ...
      CPU: 0 PID: 9 Comm: migration/0 Not tainted 4.4.0-22-generic #39-Ubuntu
      Hardware name: Xen HVM domU, BIOS 4.6.1-xs125180 05/04/2016
      task: ffff88003d75ee00 ti: ffff88003d7bc000 task.ti: ffff88003d7bc000
      RIP: 0010:[<ffffffff810e26e2>]  [<ffffffff810e26e2>] irq_move_masked_irq+0xd2/0xe0
      RSP: 0018:ffff88003d7bfc50  EFLAGS: 00010046
      RAX: 0000000000000000 RBX: ffff88003d40ba00 RCX: 0000000000000001
      RDX: 0000000000000001 RSI: 0000000000000100 RDI: ffff88003d40bad8
      RBP: ffff88003d7bfc68 R08: 0000000000000000 R09: ffff88003d000000
      R10: 0000000000000000 R11: 000000000000023c R12: ffff88003d40bad0
      R13: ffffffff81f3a4a0 R14: 0000000000000010 R15: 00000000ffffffff
      FS:  0000000000000000(0000) GS:ffff88003da00000(0000) knlGS:0000000000000000
      CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      CR2: 00007fd4264de624 CR3: 0000000037922000 CR4: 00000000003406f0
      DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
       ffff88003d40ba38 0000000000000024 0000000000000000 ffff88003d7bfca0
       ffffffff814c8d92 00000010813ef89d 00000000805ea732 0000000000000009
       0000000000000024 ffff88003cc39b80 ffff88003d7bfce0 ffffffff814c8f66
      Call Trace:
       [<ffffffff814c8d92>] eoi_pirq+0xb2/0xf0
       [<ffffffff814c8f66>] __startup_pirq+0xe6/0x150
       [<ffffffff814ca659>] xen_irq_resume+0x319/0x360
       [<ffffffff814c7e75>] xen_suspend+0xb5/0x180
       [<ffffffff81120155>] multi_cpu_stop+0xb5/0xe0
       [<ffffffff811200a0>] ? cpu_stop_queue_work+0x80/0x80
       [<ffffffff811203d0>] cpu_stopper_thread+0xb0/0x140
       [<ffffffff810a94e6>] ? finish_task_switch+0x76/0x220
       [<ffffffff810ca731>] ? __raw_callee_save___pv_queued_spin_unlock+0x11/0x20
       [<ffffffff810a3935>] smpboot_thread_fn+0x105/0x160
       [<ffffffff810a3830>] ? sort_range+0x30/0x30
       [<ffffffff810a0588>] kthread+0xd8/0xf0
       [<ffffffff810a04b0>] ? kthread_create_on_node+0x1e0/0x1e0
       [<ffffffff8182568f>] ret_from_fork+0x3f/0x70
       [<ffffffff810a04b0>] ? kthread_create_on_node+0x1e0/0x1e0
      Signed-off-by: default avatarRoss Lagerwall <ross.lagerwall@citrix.com>
      Reviewed-by: default avatarBoris Ostrovsky <boris.ostrovsky@oracle.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarDavid Vrabel <david.vrabel@citrix.com>
    • Arnd Bergmann's avatar
      Xen: don't warn about 2-byte wchar_t in efi · 971a69db
      Arnd Bergmann authored
      The XEN UEFI code has become available on the ARM architecture
      recently, but now causes a link-time warning:
      ld: warning: drivers/xen/efi.o uses 2-byte wchar_t yet the output is to use 4-byte wchar_t; use of wchar_t values across objects may fail
      This seems harmless, because the efi code only uses 2-byte
      characters when interacting with EFI, so we don't pass on those
      strings to elsewhere in the system, and we just need to
      silence the warning.
      It is not clear to me whether we actually need to build the file
      with the -fshort-wchar flag, but if we do, then we should also
      pass --no-wchar-size-warning to the linker, to avoid the warning.
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Reviewed-by: default avatarStefano Stabellini <sstabellini@kernel.org>
      Fixes: 37060935dc04 ("ARM64: XEN: Add a function to initialize Xen specific UEFI runtime services")
    • David Vrabel's avatar
      xen/gntdev: reduce copy batch size to 16 · 36ae220a
      David Vrabel authored
      IOCTL_GNTDEV_GRANT_COPY batches copy operations to reduce the number
      of hypercalls.  The stack is used to avoid a memory allocation in a
      hot path. However, a batch size of 24 requires more than 1024 bytes of
      stack which in some configurations causes a compiler warning.
          xen/gntdev.c: In function ‘gntdev_ioctl_grant_copy’:
          xen/gntdev.c:949:1: warning: the frame size of 1248 bytes is
          larger than 1024 bytes [-Wframe-larger-than=]
      This is a harmless warning as there is still plenty of stack spare,
      but people keep trying to "fix" it.  Reduce the batch size to 16 to
      reduce stack usage to less than 1024 bytes.  This should have minimal
      impact on performance.
      Signed-off-by: default avatarDavid Vrabel <david.vrabel@citrix.com>
  11. 10 May, 2016 2 commits
  12. 04 May, 2016 1 commit
    • Jan Beulich's avatar
      xen/evtchn: fix ring resize when binding new events · 27e0e638
      Jan Beulich authored
      The copying of ring data was wrong for two cases: For a full ring
      nothing got copied at all (as in that case the canonicalized producer
      and consumer indexes are identical). And in case one or both of the
      canonicalized (after the resize) indexes would point into the second
      half of the buffer, the copied data ended up in the wrong (free) part
      of the new buffer. In both cases uninitialized data would get passed
      back to the caller.
      Fix this by simply copying the old ring contents twice: Once to the
      low half of the new buffer, and a second time to the high half.
      This addresses the inability to boot a HVM guest with 64 or more
      vCPUs.  This regression was caused by 86200154 (xen/evtchn:
      dynamically grow pending event channel ring).
      Reported-by: default avatarKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      Signed-off-by: default avatarJan Beulich <jbeulich@suse.com>
      Cc: <stable@vger.kernel.org> # 4.4+
      Signed-off-by: default avatarDavid Vrabel <david.vrabel@citrix.com>