1. 26 Aug, 2011 3 commits
    • Randy Dunlap's avatar
      xen-swiotlb: fix printk and panic args · 61ca7983
      Randy Dunlap authored
      Fix printk() and panic() args [swap them] to fix build warnings:
      
      drivers/xen/swiotlb-xen.c:201: warning: format '%s' expects type 'char *', but argument 2 has type 'int'
      drivers/xen/swiotlb-xen.c:201: warning: format '%d' expects type 'int', but argument 3 has type 'char *'
      drivers/xen/swiotlb-xen.c:202: warning: format '%s' expects type 'char *', but argument 2 has type 'int'
      drivers/xen/swiotlb-xen.c:202: warning: format '%d' expects type 'int', but argument 3 has type 'char *'
      Signed-off-by: default avatarRandy Dunlap <rdunlap@xenotime.net>
      Signed-off-by: default avatarKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      61ca7983
    • Konrad Rzeszutek Wilk's avatar
      xen-swiotlb: Fix wrong panic. · ab2a47bd
      Konrad Rzeszutek Wilk authored
      Propagate the baremetal git commit "swiotlb: fix wrong panic"
      (fba99fa3) in the Xen-SWIOTLB version.
      wherein swiotlb's map_page wrongly calls panic() when it can't find
      a buffer fit for device's dma mask.  It should return an error instead.
      
      Devices with an odd dma mask (i.e.  under 4G) like b44 network card hit
      this bug (the system crashes):
      
      http://marc.info/?l=linux-kernel&m=129648943830106&w=2
      
      If xen-swiotlb returns an error, b44 driver can use the own bouncing
      mechanism.
      
      CC: stable@kernel.org
      Signed-off-by: default avatarKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      ab2a47bd
    • Konrad Rzeszutek Wilk's avatar
      xen-swiotlb: Retry up three times to allocate Xen-SWIOTLB · f4b2f07b
      Konrad Rzeszutek Wilk authored
      We can fail seting up Xen-SWIOTLB if:
       - The host does not have enough contiguous DMA32 memory available
         (can happen on a machine that has fragmented memory from starting,
         stopping many guests).
       - Not enough low memory (almost never happens).
      
      We retry allocating and exchanging the swath of contiguous memory
      up to three times. Each time we decrease the amount we need  - the
      minimum being of 2MB.
      
      If we compleltly fail, we will print the reason for failure on the Xen
      console on top of doing it to earlyprintk=xen console.
      Signed-off-by: default avatarKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      f4b2f07b
  2. 06 Jun, 2011 1 commit
    • FUJITA Tomonori's avatar
      swiotlb: Export swioltb_nr_tbl and utilize it as appropiate. · 5f98ecdb
      FUJITA Tomonori authored
      By default the io_tlb_nslabs is set to zero, and gets set to
      whatever value is passed in via swiotlb_init_with_tbl function.
      The default value passed in is 64MB. However, if the user provides
      the 'swiotlb=<nslabs>' the default value is ignored and
      the value provided by the user is used... Except when the SWIOTLB
      is used under Xen - there the default value of 64MB is used and
      the Xen-SWIOTLB has no mechanism to get the 'io_tlb_nslabs' filled
      out by setup_io_tlb_npages functions. This patch provides a function
      for the Xen-SWIOTLB to call to see if the io_tlb_nslabs is set
      and if so use that value.
      Signed-off-by: default avatarFUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
      Signed-off-by: default avatarKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      5f98ecdb
  3. 10 Apr, 2011 1 commit
  4. 27 Jul, 2010 1 commit
    • Konrad Rzeszutek Wilk's avatar
      swiotlb-xen: SWIOTLB library for Xen PV guest with PCI passthrough. · b097186f
      Konrad Rzeszutek Wilk authored
      This patchset:
      
      PV guests under Xen are running in an non-contiguous memory architecture.
      
      When PCI pass-through is utilized, this necessitates an IOMMU for
      translating bus (DMA) to virtual and vice-versa and also providing a
      mechanism to have contiguous pages for device drivers operations (say DMA
      operations).
      
      Specifically, under Xen the Linux idea of pages is an illusion. It
      assumes that pages start at zero and go up to the available memory. To
      help with that, the Linux Xen MMU provides a lookup mechanism to
      translate the page frame numbers (PFN) to machine frame numbers (MFN)
      and vice-versa. The MFN are the "real" frame numbers. Furthermore
      memory is not contiguous. Xen hypervisor stitches memory for guests
      from different pools, which means there is no guarantee that PFN==MFN
      and PFN+1==MFN+1. Lastly with Xen 4.0, pages (in debug mode) are
      allocated in descending order (high to low), meaning the guest might
      never get any MFN's under the 4GB mark.
      Signed-off-by: default avatarKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      Acked-by: default avatarJeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
      Cc: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
      Cc: Albert Herranz <albert_herranz@yahoo.es>
      Cc: Ian Campbell <Ian.Campbell@citrix.com>
      b097186f