1. 09 9月, 2015 2 次提交
    • J
      xen: Use correctly the Xen memory terminologies · 0df4f266
      Julien Grall 提交于
      Based on include/xen/mm.h [1], Linux is mistakenly using MFN when GFN
      is meant, I suspect this is because the first support for Xen was for
      PV. This resulted in some misimplementation of helpers on ARM and
      confused developers about the expected behavior.
      
      For instance, with pfn_to_mfn, we expect to get an MFN based on the name.
      Although, if we look at the implementation on x86, it's returning a GFN.
      
      For clarity and avoid new confusion, replace any reference to mfn with
      gfn in any helpers used by PV drivers. The x86 code will still keep some
      reference of pfn_to_mfn which may be used by all kind of guests
      No changes as been made in the hypercall field, even
      though they may be invalid, in order to keep the same as the defintion
      in xen repo.
      
      Note that page_to_mfn has been renamed to xen_page_to_gfn to avoid a
      name to close to the KVM function gfn_to_page.
      
      Take also the opportunity to simplify simple construction such
      as pfn_to_mfn(page_to_pfn(page)) into xen_page_to_gfn. More complex clean up
      will come in follow-up patches.
      
      [1] http://xenbits.xen.org/gitweb/?p=xen.git;a=commitdiff;h=e758ed14f390342513405dd766e874934573e6cbSigned-off-by: NJulien Grall <julien.grall@citrix.com>
      Reviewed-by: NStefano Stabellini <stefano.stabellini@eu.citrix.com>
      Acked-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
      Acked-by: NWei Liu <wei.liu2@citrix.com>
      Signed-off-by: NDavid Vrabel <david.vrabel@citrix.com>
      0df4f266
    • J
      xen: Make clear that swiotlb and biomerge are dealing with DMA address · 32e09870
      Julien Grall 提交于
      The swiotlb is required when programming a DMA address on ARM when a
      device is not protected by an IOMMU.
      
      In this case, the DMA address should always be equal to the machine address.
      For DOM0 memory, Xen ensure it by have an identity mapping between the
      guest address and host address. However, when mapping a foreign grant
      reference, the 1:1 model doesn't work.
      
      For ARM guest, most of the callers of pfn_to_mfn expects to get a GFN
      (Guest Frame Number), i.e a PFN (Page Frame Number) from the Linux point
      of view given that all ARM guest are auto-translated.
      
      Even though the name pfn_to_mfn is misleading, we need to ensure that
      those caller get a GFN and not by mistake a MFN. In pratical, I haven't
      seen error related to this but we should fix it for the sake of
      correctness.
      
      In order to fix the implementation of pfn_to_mfn on ARM in a follow-up
      patch, we have to introduce new helpers to return the DMA from a PFN and
      the invert.
      
      On x86, the new helpers will be an alias of pfn_to_mfn and mfn_to_pfn.
      
      The helpers will be used in swiotlb and xen_biovec_phys_mergeable.
      
      This is necessary in the latter because we have to ensure that the
      biovec code will not try to merge a biovec using foreign page and
      another using Linux memory.
      
      Lastly, the helper mfn_to_local_pfn has been renamed to bfn_to_local_pfn
      given that the only usage was in swiotlb.
      Signed-off-by: NJulien Grall <julien.grall@citrix.com>
      Reviewed-by: NStefano Stabellini <stefano.stabellini@eu.citrix.com>
      Signed-off-by: NDavid Vrabel <david.vrabel@citrix.com>
      32e09870
  2. 08 9月, 2015 1 次提交
  3. 20 8月, 2015 4 次提交
  4. 11 8月, 2015 2 次提交
  5. 04 8月, 2015 1 次提交
    • R
      xen/events/fifo: Handle linked events when closing a port · fcdf31a7
      Ross Lagerwall 提交于
      An event channel bound to a CPU that was offlined may still be linked
      on that CPU's queue.  If this event channel is closed and reused,
      subsequent events will be lost because the event channel is never
      unlinked and thus cannot be linked onto the correct queue.
      
      When a channel is closed and the event is still linked into a queue,
      ensure that it is unlinked before completing.
      
      If the CPU to which the event channel bound is online, spin until the
      event is handled by that CPU. If that CPU is offline, it can't handle
      the event, so clear the event queue during the close, dropping the
      events.
      
      This fixes the missing interrupts (and subsequent disk stalls etc.)
      when offlining a CPU.
      Signed-off-by: NRoss Lagerwall <ross.lagerwall@citrix.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: NDavid Vrabel <david.vrabel@citrix.com>
      fcdf31a7
  6. 20 7月, 2015 1 次提交
    • J
      xen: release lock occasionally during ballooning · 929423fa
      Juergen Gross 提交于
      When dom0 is being ballooned balloon_process() will hold the balloon
      mutex until it is finished. This will block e.g. creation of new
      domains as the device backends for the new domain need some
      autoballooned pages for the ring buffers.
      
      Avoid this by releasing the balloon mutex from time to time during
      ballooning. Adjust the comment above balloon_process() regarding
      multiple instances of balloon_process().
      
      Instead of open coding it, just use cond_resched().
      Signed-off-by: NJuergen Gross <jgross@suse.com>
      Signed-off-by: NDavid Vrabel <david.vrabel@citrix.com>
      929423fa
  7. 30 6月, 2015 1 次提交
  8. 25 6月, 2015 1 次提交
    • D
      frontswap: allow multiple backends · d1dc6f1b
      Dan Streetman 提交于
      Change frontswap single pointer to a singly linked list of frontswap
      implementations.  Update Xen tmem implementation as register no longer
      returns anything.
      
      Frontswap only keeps track of a single implementation; any
      implementation that registers second (or later) will replace the
      previously registered implementation, and gets a pointer to the previous
      implementation that the new implementation is expected to pass all
      frontswap functions to if it can't handle the function itself.  However
      that method doesn't really make much sense, as passing that work on to
      every implementation adds unnecessary work to implementations; instead,
      frontswap should simply keep a list of all registered implementations
      and try each implementation for any function.  Most importantly, neither
      of the two currently existing frontswap implementations in the kernel
      actually do anything with any previous frontswap implementation that
      they replace when registering.
      
      This allows frontswap to successfully manage multiple implementations by
      keeping a list of them all.
      Signed-off-by: NDan Streetman <ddstreet@ieee.org>
      Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>
      Cc: David Vrabel <david.vrabel@citrix.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      d1dc6f1b
  9. 17 6月, 2015 3 次提交
  10. 16 6月, 2015 3 次提交
  11. 02 6月, 2015 1 次提交
    • B
      target: Minimize SCSI header #include directives · ba929992
      Bart Van Assche 提交于
      Only include SCSI initiator header files in target code that needs
      these header files, namely the SCSI pass-through code and the tcm_loop
      driver. Change SCSI_SENSE_BUFFERSIZE into TRANSPORT_SENSE_BUFFER in
      target code because the former is intended for initiator code and the
      latter for target code. With this patch the only initiator include
      directives in target code that remain are as follows:
      
      $ git grep -nHE 'include .scsi/(scsi.h|scsi_host.h|scsi_device.h|scsi_cmnd.h)' drivers/target drivers/infiniband/ulp/{isert,srpt} drivers/usb/gadget/legacy/tcm_*.[ch] drivers/{vhost,xen} include/{target,trace/events/target.h}
      drivers/target/loopback/tcm_loop.c:29:#include <scsi/scsi.h>
      drivers/target/loopback/tcm_loop.c:31:#include <scsi/scsi_host.h>
      drivers/target/loopback/tcm_loop.c:32:#include <scsi/scsi_device.h>
      drivers/target/loopback/tcm_loop.c:33:#include <scsi/scsi_cmnd.h>
      drivers/target/target_core_pscsi.c:39:#include <scsi/scsi_device.h>
      drivers/target/target_core_pscsi.c:40:#include <scsi/scsi_host.h>
      drivers/xen/xen-scsiback.c:52:#include <scsi/scsi_host.h> /* SG_ALL */
      Signed-off-by: NBart Van Assche <bart.vanassche@sandisk.com>
      Reviewed-by: NChristoph Hellwig <hch@lst.de>
      Signed-off-by: NJames Bottomley <JBottomley@Odin.com>
      ba929992
  12. 01 6月, 2015 1 次提交
    • N
      target: Convert se_portal_group->tpg_lun_list[] to RCU hlist · 6bb82612
      Nicholas Bellinger 提交于
      This patch converts the fixed size se_portal_group->tpg_lun_list[]
      to use modern RCU with hlist_head in order to support an arbitary
      number of se_lun ports per target endpoint.
      
      It includes dropping core_tpg_alloc_lun() from core_dev_add_lun(),
      and calling it directly from target_fabric_make_lun() to allocate
      a new se_lun.  And add a new target_fabric_port_release() configfs
      item callback to invoke kfree_rcu() to release memory during
      se_lun->lun_group shutdown.
      
      Also now that se_node_acl->lun_entry_hlist is using RCU, convert
      existing tpg_lun_lock to struct mutex so core_tpg_add_node_to_devs()
      can perform RCU updater logic without releasing ->tpg_lun_mutex.
      
      Also, drop core_tpg_clear_object_luns() and it's single consumer
      in iscsi-target, which is duplicating TPG LUN shutdown logic and
      is current code results in a NOP.
      
      Finally, sbp-target and xen-scsiback fabric driver conversions are
      included, which are required due to the non-standard way they use
      ->tpg_lun_hlist.
      Reviewed-by: NHannes Reinecke <hare@suse.de>
      Cc: Christoph Hellwig <hch@lst.de>
      Cc: Sagi Grimberg <sagig@mellanox.com>
      Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
      Cc: Chris Boot <bootc@bootc.net>
      Signed-off-by: NNicholas Bellinger <nab@linux-iscsi.org>
      6bb82612
  13. 31 5月, 2015 9 次提交
  14. 28 5月, 2015 2 次提交
  15. 20 5月, 2015 1 次提交
    • D
      xen/events: don't bind non-percpu VIRQs with percpu chip · 77bb3dfd
      David Vrabel 提交于
      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: NDavid Vrabel <david.vrabel@citrix.com>
      Cc: <stable@vger.kernel.org>
      77bb3dfd
  16. 14 5月, 2015 2 次提交
  17. 06 5月, 2015 4 次提交
  18. 30 4月, 2015 1 次提交