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
      
          @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.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>
      00085f1e
  3. 26 Jul, 2016 1 commit
  4. 25 Jul, 2016 1 commit
    • Vitaly Kuznetsov's avatar
      xen: introduce xen_vcpu_id mapping · 88e957d6
      Vitaly Kuznetsov authored
      It may happen that Xen's and Linux's ideas of vCPU id diverge. In
      particular, when we crash on a secondary vCPU we may want to do kdump
      and unlike plain kexec where we do migrate_to_reboot_cpu() we try
      booting on the vCPU which crashed. This doesn't work very well for
      PVHVM guests as we have a number of hypercalls where we pass vCPU id
      as a parameter. These hypercalls either fail or do something
      unexpected.
      
      To solve the issue introduce percpu xen_vcpu_id mapping. ARM and PV
      guests get direct mapping for now. Boot CPU for PVHVM guest gets its
      id from CPUID. With secondary CPUs it is a bit more
      trickier. Currently, we initialize IPI vectors before these CPUs boot
      so we can't use CPUID. Use ACPI ids from MADT instead.
      Signed-off-by: default avatarVitaly Kuznetsov <vkuznets@redhat.com>
      Signed-off-by: default avatarDavid Vrabel <david.vrabel@citrix.com>
      88e957d6
  5. 06 Jul, 2016 7 commits
  6. 06 Apr, 2016 1 commit
    • Ross Lagerwall's avatar
      xen: Fix page <-> pfn conversion on 32 bit systems · 60901df3
      Ross Lagerwall authored
      Commit 1084b198 (xen: Add Xen specific
      page definition) caused a regression in 4.4.
      
      The xen functions to convert between pages and pfns fail due to an
      overflow on systems where a physical address may not fit in an
      unsigned long (e.g. x86 32 bit PAE systems). Rework the conversion to
      avoid overflow. This should also result in simpler object code.
      
      This bug manifested itself as disk corruption with Linux 4.4 when
      using blkfront in a Xen HVM x86 32 bit guest with more than 4 GiB of
      memory.
      Signed-off-by: default avatarRoss Lagerwall <ross.lagerwall@citrix.com>
      Cc: <stable@vger.kernel.org> # 4.4+
      Signed-off-by: default avatarDavid Vrabel <david.vrabel@citrix.com>
      60901df3
  7. 13 Mar, 2016 1 commit
    • Paul Durrant's avatar
      xen-netback: re-import canonical netif header · 6b8abef5
      Paul Durrant authored
      The canonical netif header (in the Xen source repo) and the Linux variant
      have diverged significantly. Recently much documentation has been added to
      the canonical header which is highly useful for developers making
      modifications to either xen-netfront or xen-netback. This patch therefore
      re-imports the canonical header in its entirity.
      
      To maintain compatibility and some style consistency with the old Linux
      variant, the header was stripped of its emacs boilerplate, and
      post-processed and copied into place with the following commands:
      
      ed -s netif.h << EOF
      H
      ,s/NETTXF_/XEN_NETTXF_/g
      ,s/NETRXF_/XEN_NETRXF_/g
      ,s/NETIF_/XEN_NETIF_/g
      ,s/XEN_XEN_/XEN_/g
      ,s/netif/xen_netif/g
      ,s/xen_xen_/xen_/g
      ,s/^typedef.*$//g
      ,s/^    /${TAB}/g
      w
      $
      w
      EOF
      
      indent --line-length 80 --linux-style netif.h \
      -o include/xen/interface/io/netif.h
      Signed-off-by: default avatarPaul Durrant <paul.durrant@citrix.com>
      Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>
      Cc: David Vrabel <david.vrabel@citrix.com>
      Cc: Wei Liu <wei.liu2@citrix.com>
      Acked-by: default avatarWei Liu <wei.liu2@citrix.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      6b8abef5
  8. 12 Jan, 2016 1 commit
  9. 04 Jan, 2016 1 commit
  10. 21 Dec, 2015 3 commits
  11. 18 Dec, 2015 1 commit
    • David Vrabel's avatar
      xen: Add RING_COPY_REQUEST() · 454d5d88
      David Vrabel authored
      Using RING_GET_REQUEST() on a shared ring is easy to use incorrectly
      (i.e., by not considering that the other end may alter the data in the
      shared ring while it is being inspected).  Safe usage of a request
      generally requires taking a local copy.
      
      Provide a RING_COPY_REQUEST() macro to use instead of
      RING_GET_REQUEST() and an open-coded memcpy().  This takes care of
      ensuring that the copy is done correctly regardless of any possible
      compiler optimizations.
      
      Use a volatile source to prevent the compiler from reordering or
      omitting the copy.
      
      This is part of XSA155.
      
      CC: stable@vger.kernel.org
      Signed-off-by: default avatarDavid Vrabel <david.vrabel@citrix.com>
      Signed-off-by: default avatarKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      454d5d88
  12. 23 Oct, 2015 9 commits
  13. 28 Sep, 2015 1 commit
    • Vitaly Kuznetsov's avatar
      x86/xen: Support kexec/kdump in HVM guests by doing a soft reset · 0b34a166
      Vitaly Kuznetsov authored
      Currently there is a number of issues preventing PVHVM Xen guests from
      doing successful kexec/kdump:
      
        - Bound event channels.
        - Registered vcpu_info.
        - PIRQ/emuirq mappings.
        - shared_info frame after XENMAPSPACE_shared_info operation.
        - Active grant mappings.
      
      Basically, newly booted kernel stumbles upon already set up Xen
      interfaces and there is no way to reestablish them. In Xen-4.7 a new
      feature called 'soft reset' is coming. A guest performing kexec/kdump
      operation is supposed to call SCHEDOP_shutdown hypercall with
      SHUTDOWN_soft_reset reason before jumping to new kernel. Hypervisor
      (with some help from toolstack) will do full domain cleanup (but
      keeping its memory and vCPU contexts intact) returning the guest to
      the state it had when it was first booted and thus allowing it to
      start over.
      
      Doing SHUTDOWN_soft_reset on Xen hypervisors which don't support it is
      probably OK as by default all unknown shutdown reasons cause domain
      destroy with a message in toolstack log: 'Unknown shutdown reason code
      5. Destroying domain.'  which gives a clue to what the problem is and
      eliminates false expectations.
      Signed-off-by: default avatarVitaly Kuznetsov <vkuznets@redhat.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarDavid Vrabel <david.vrabel@citrix.com>
      0b34a166
  14. 08 Sep, 2015 3 commits
  15. 02 Sep, 2015 1 commit
    • Paul Durrant's avatar
      xen-netback: add support for multicast control · 210c34dc
      Paul Durrant authored
      Xen's PV network protocol includes messages to add/remove ethernet
      multicast addresses to/from a filter list in the backend. This allows
      the frontend to request the backend only forward multicast packets
      which are of interest thus preventing unnecessary noise on the shared
      ring.
      
      The canonical netif header in git://xenbits.xen.org/xen.git specifies
      the message format (two more XEN_NETIF_EXTRA_TYPEs) so the minimal
      necessary changes have been pulled into include/xen/interface/io/netif.h.
      
      To prevent the frontend from extending the multicast filter list
      arbitrarily a limit (XEN_NETBK_MCAST_MAX) has been set to 64 entries.
      This limit is not specified by the protocol and so may change in future.
      If the limit is reached then the next XEN_NETIF_EXTRA_TYPE_MCAST_ADD
      sent by the frontend will be failed with NETIF_RSP_ERROR.
      Signed-off-by: default avatarPaul Durrant <paul.durrant@citrix.com>
      Cc: Ian Campbell <ian.campbell@citrix.com>
      Cc: Wei Liu <wei.liu2@citrix.com>
      Acked-by: default avatarWei Liu <wei.liu2@citrix.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      210c34dc
  16. 20 Aug, 2015 6 commits
  17. 19 May, 2015 1 commit
    • David Vrabel's avatar
      xen/events: don't bind non-percpu VIRQs with percpu chip · 77bb3dfd
      David Vrabel authored
      A non-percpu VIRQ (e.g., VIRQ_CONSOLE) may be freed on a different
      VCPU than it is bound to.  This can result in a race between
      handle_percpu_irq() and removing the action in __free_irq() because
      handle_percpu_irq() does not take desc->lock.  The interrupt handler
      sees a NULL action and oopses.
      
      Only use the percpu chip/handler for per-CPU VIRQs (like VIRQ_TIMER).
      
        # cat /proc/interrupts | grep virq
         40:      87246          0  xen-percpu-virq      timer0
         44:          0          0  xen-percpu-virq      debug0
         47:          0      20995  xen-percpu-virq      timer1
         51:          0          0  xen-percpu-virq      debug1
         69:          0          0   xen-dyn-virq      xen-pcpu
         74:          0          0   xen-dyn-virq      mce
         75:         29          0   xen-dyn-virq      hvc_console
      Signed-off-by: default avatarDavid Vrabel <david.vrabel@citrix.com>
      Cc: <stable@vger.kernel.org>
      77bb3dfd