1. 20 Jan, 2017 1 commit
  2. 06 Jan, 2017 1 commit
  3. 19 Dec, 2016 1 commit
  4. 09 Dec, 2016 1 commit
  5. 18 Nov, 2016 1 commit
  6. 10 Nov, 2016 1 commit
  7. 07 Nov, 2016 2 commits
    • Alexander Duyck's avatar
      swiotlb: Add support for DMA_ATTR_SKIP_CPU_SYNC · 0443fa00
      Alexander Duyck authored
      
      
      As a first step to making DMA_ATTR_SKIP_CPU_SYNC apply to architectures
      beyond just ARM I need to make it so that the swiotlb will respect the
      flag.  In order to do that I also need to update the swiotlb-xen since it
      heavily makes use of the functionality.
      
      Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      Signed-off-by: default avatarAlexander Duyck <alexander.h.duyck@intel.com>
      Signed-off-by: default avatarKonrad Rzeszutek Wilk <konrad@kernel.org>
      0443fa00
    • Alexander Duyck's avatar
      swiotlb-xen: Enforce return of DMA_ERROR_CODE in mapping function · 76418421
      Alexander Duyck authored
      
      
      The mapping function should always return DMA_ERROR_CODE when a mapping has
      failed as this is what the DMA API expects when a DMA error has occurred.
      The current function for mapping a page in Xen was returning either
      DMA_ERROR_CODE or 0 depending on where it failed.
      
      On x86 DMA_ERROR_CODE is 0, but on other architectures such as ARM it is
      ~0. We need to make sure we return the same error value if either the
      mapping failed or the device is not capable of accessing the mapping.
      
      If we are returning DMA_ERROR_CODE as our error value we can drop the
      function for checking the error code as the default is to compare the
      return value against DMA_ERROR_CODE if no function is defined.
      
      Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      Signed-off-by: default avatarAlexander Duyck <alexander.h.duyck@intel.com>
      Signed-off-by: default avatarKonrad Rzeszutek Wilk <konrad@kernel.org>
      76418421
  8. 24 Oct, 2016 3 commits
  9. 30 Sep, 2016 5 commits
    • Juergen Gross's avatar
      xen/pciback: support driver_override · b057878b
      Juergen Gross authored
      Support the driver_override scheme introduced with commit 782a985d
      
      
      ("PCI: Introduce new device binding path using pci_dev.driver_override")
      
      As pcistub_probe() is called for all devices (it has to check for a
      match based on the slot address rather than device type) it has to
      check for driver_override set to "pciback" itself.
      
      Up to now for assigning a pci device to pciback you need something like:
      
      echo 0000:07:10.0 > /sys/bus/pci/devices/0000\:07\:10.0/driver/unbind
      echo 0000:07:10.0 > /sys/bus/pci/drivers/pciback/new_slot
      echo 0000:07:10.0 > /sys/bus/pci/drivers_probe
      
      while with the patch you can use the same mechanism as for similar
      drivers like pci-stub and vfio-pci:
      
      echo pciback > /sys/bus/pci/devices/0000\:07\:10.0/driver_override
      echo 0000:07:10.0 > /sys/bus/pci/devices/0000\:07\:10.0/driver/unbind
      echo 0000:07:10.0 > /sys/bus/pci/drivers_probe
      
      So e.g. libvirt doesn't need special handling for pciback.
      Signed-off-by: default avatarJuergen Gross <jgross@suse.com>
      Signed-off-by: default avatarDavid Vrabel <david.vrabel@citrix.com>
      b057878b
    • Juergen Gross's avatar
      xen/pciback: avoid multiple entries in slot list · 9f8bee9c
      Juergen Gross authored
      
      
      The Xen pciback driver has a list of all pci devices it is ready to
      seize. There is no check whether a to be added entry already exists.
      While this might be no problem in the common case it might confuse
      those which consume the list via sysfs.
      
      Modify the handling of this list by not adding an entry which already
      exists. As this will be needed later split out the list handling into
      a separate function.
      Signed-off-by: default avatarJuergen Gross <jgross@suse.com>
      Signed-off-by: default avatarDavid Vrabel <david.vrabel@citrix.com>
      9f8bee9c
    • Juergen Gross's avatar
      xen/pciback: simplify pcistub device handling · 1af916b7
      Juergen Gross authored
      
      
      The Xen pciback driver maintains a list of all its seized devices.
      There are two functions searching the list for a specific device with
      basically the same semantics just returning different structures in
      case of a match.
      
      Split out the search function.
      Signed-off-by: default avatarJuergen Gross <jgross@suse.com>
      Signed-off-by: default avatarDavid Vrabel <david.vrabel@citrix.com>
      1af916b7
    • KarimAllah Ahmed's avatar
      xen: Remove event channel notification through Xen PCI platform device · 72a9b186
      KarimAllah Ahmed authored
      Ever since commit 254d1a3f ("xen/pv-on-hvm kexec: shutdown watches
      from old kernel") using the INTx interrupt from Xen PCI platform
      device for event channel notification would just lockup the guest
      during bootup.  postcore_initcall now calls xs_reset_watches which
      will eventually try to read a value from XenStore and will get stuck
      on read_reply at XenBus forever since the platform driver is not
      probed yet and its INTx interrupt handler is not registered yet. That
      means that the guest can not be notified at this moment of any pending
      event channels and none of the per-event handlers will ever be invoked
      (including the XenStore one) and the reply will never be picked up by
      the kernel.
      
      The exact stack where things get stuck during xenbus_init:
      
      -xenbus_init
       -xs_init
        -xs_reset_watches
         -xenbus_scanf
          -xenbus_read
           -xs_single
            -xs_single
             -xs_talkv
      
      Vector callbacks have always been the favourite event notification
      mechanism since their introduction in commit 38e20b07
      
       ("x86/xen:
      event channels delivery on HVM.") and the vector callback feature has
      always been advertised for quite some time by Xen that's why INTx was
      broken for several years now without impacting anyone.
      
      Luckily this also means that event channel notification through INTx
      is basically dead-code which can be safely removed without impacting
      anybody since it has been effectively disabled for more than 4 years
      with nobody complaining about it (at least as far as I'm aware of).
      
      This commit removes event channel notification through Xen PCI
      platform device.
      
      Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>
      Cc: David Vrabel <david.vrabel@citrix.com>
      Cc: Juergen Gross <jgross@suse.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: x86@kernel.org
      Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      Cc: Bjorn Helgaas <bhelgaas@google.com>
      Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
      Cc: Julien Grall <julien.grall@citrix.com>
      Cc: Vitaly Kuznetsov <vkuznets@redhat.com>
      Cc: Paul Gortmaker <paul.gortmaker@windriver.com>
      Cc: Ross Lagerwall <ross.lagerwall@citrix.com>
      Cc: xen-devel@lists.xenproject.org
      Cc: linux-kernel@vger.kernel.org
      Cc: linux-pci@vger.kernel.org
      Cc: Anthony Liguori <aliguori@amazon.com>
      Signed-off-by: default avatarKarimAllah Ahmed <karahmed@amazon.de>
      Reviewed-by: default avatarBoris Ostrovsky <boris.ostrovsky@oracle.com>
      Signed-off-by: default avatarDavid Vrabel <david.vrabel@citrix.com>
      72a9b186
    • Sebastian Andrzej Siewior's avatar
      xen/events: Convert to hotplug state machine · c8761e20
      Sebastian Andrzej Siewior authored
      
      
      Install the callbacks via the state machine.
      Signed-off-by: default avatarSebastian Andrzej Siewior <bigeasy@linutronix.de>
      Signed-off-by: default avatarBoris Ostrovsky <boris.ostrovsky@oracle.com>
      Signed-off-by: default avatarDavid Vrabel <david.vrabel@citrix.com>
      c8761e20
  10. 24 Aug, 2016 2 commits
  11. 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
      
          @r@
          identifier f, attrs;
      
          @@
          f(...,
          - struct dma_attrs *attrs
          + unsigned long attrs
          , ...)
          {
          ...
          }
      
          @@
          identifier r.f;
          @@
          f(...,
          - NULL
          + 0
           )
      
      and
      
          // Options: --all-includes
          virtual patch
          virtual context
      
          @r@
          identifier f, attrs;
          type t;
      
          @@
          t f(..., struct dma_attrs *attrs);
      
          @@
          identifier r.f;
          @@
          f(...,
          - NULL
          + 0
           )
      
      Link: http://lkml.kernel.org/r/1468399300-5399-2-git-send-email-k.kozlowski@samsung.com
      
      Signed-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>
      00085f1e
  12. 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
      exceptions:
      
      - 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
        registered.
      
      - 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.cz
      
      Signed-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>
      8ea1d2a1
    • 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>
      d34c30cc
  13. 25 Jul, 2016 5 commits
  14. 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>
      6f2d9d99
    • 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>
      e5a79475
    • 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
      called.
      
      If sending an XS_TRANSACTION_END message fails, the transaction is
      still open, but if an error response is returned the transaction is
      closed.
      
      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>
      7469be95
  15. 07 Jul, 2016 1 commit
  16. 06 Jul, 2016 10 commits