1. 02 Dec, 2015 2 commits
  2. 26 Nov, 2015 3 commits
    • David Vrabel's avatar
      xen/evtchn: dynamically grow pending event channel ring · 86200154
      David Vrabel authored
      If more than 1024 event channels are bound to a evtchn device then it
      possible (even with well behaved applications) for the ring to
      overflow and events to be lost (reported as an -EFBIG error).
      
      Dynamically increase the size of the ring so there is always enough
      space for all bound events.  Well behaved applicables that only unmask
      events after draining them from the ring can thus no longer lose
      events.
      
      However, an application could unmask an event before draining it,
      allowing multiple entries per port to accumulate in the ring, and a
      overflow could still occur.  So the overflow detection and reporting
      is retained.
      
      The ring size is initially only 64 entries so the common use case of
      an application only binding a few events will use less memory than
      before.  The ring size may grow to 512 KiB (enough for all 2^17
      possible channels).  This order 7 kmalloc() may fail due to memory
      fragmentation, so we fall back to trying vmalloc().
      Signed-off-by: default avatarDavid Vrabel <david.vrabel@citrix.com>
      Reviewed-by: default avatarAndrew Cooper <andrew.cooper3@citrix.com>
      86200154
    • Boris Ostrovsky's avatar
      xen/events: Always allocate legacy interrupts on PV guests · b4ff8389
      Boris Ostrovsky authored
      After commit 8c058b0b ("x86/irq: Probe for PIC presence before
      allocating descs for legacy IRQs") early_irq_init() will no longer
      preallocate descriptors for legacy interrupts if PIC does not
      exist, which is the case for Xen PV guests.
      
      Therefore we may need to allocate those descriptors ourselves.
      Signed-off-by: default avatarBoris Ostrovsky <boris.ostrovsky@oracle.com>
      Suggested-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Signed-off-by: default avatarDavid Vrabel <david.vrabel@citrix.com>
      b4ff8389
    • Boris Ostrovsky's avatar
      xen/gntdev: Grant maps should not be subject to NUMA balancing · 9c17d965
      Boris Ostrovsky authored
      Doing so will cause the grant to be unmapped and then, during
      fault handling, the fault to be mistakenly treated as NUMA hint
      fault.
      
      In addition, even if those maps could partcipate in NUMA
      balancing, it wouldn't provide any benefit since we are unable
      to determine physical page's node (even if/when VNUMA is
      implemented).
      
      Marking grant maps' VMAs as VM_IO will exclude them from being
      part of NUMA balancing.
      Signed-off-by: default avatarBoris Ostrovsky <boris.ostrovsky@oracle.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarDavid Vrabel <david.vrabel@citrix.com>
      9c17d965
  3. 02 Nov, 2015 1 commit
  4. 28 Oct, 2015 1 commit
  5. 23 Oct, 2015 33 commits