1. 31 Aug, 2017 19 commits
  2. 11 Aug, 2017 2 commits
    • Liu Shuo's avatar
      xen/events: Fix interrupt lost during irq_disable and irq_enable · 020db9d3
      Liu Shuo authored
      Here is a device has xen-pirq-MSI interrupt. Dom0 might lost interrupt
      during driver irq_disable/irq_enable. Here is the scenario,
       1. irq_disable -> disable_dynirq -> mask_evtchn(irq channel)
       2. dev interrupt raised by HW and Xen mark its evtchn as pending
       3. irq_enable -> startup_pirq -> eoi_pirq ->
          clear_evtchn(channel of irq) -> clear pending status
       4. consume_one_event process the irq event without pending bit assert
          which result in interrupt lost once
       5. No HW interrupt raising anymore.
      
      Now use enable_dynirq for enable_pirq of xen_pirq_chip to remove
      eoi_pirq when irq_enable.
      Signed-off-by: 's avatarLiu Shuo <shuo.a.liu@intel.com>
      Reviewed-by: 's avatarBoris Ostrovsky <boris.ostrovsky@oracle.com>
      Signed-off-by: 's avatarJuergen Gross <jgross@suse.com>
      020db9d3
    • Juergen Gross's avatar
      xen: avoid deadlock in xenbus · 529871bb
      Juergen Gross authored
      When starting the xenwatch thread a theoretical deadlock situation is
      possible:
      
      xs_init() contains:
      
          task = kthread_run(xenwatch_thread, NULL, "xenwatch");
          if (IS_ERR(task))
              return PTR_ERR(task);
          xenwatch_pid = task->pid;
      
      And xenwatch_thread() does:
      
          mutex_lock(&xenwatch_mutex);
          ...
          event->handle->callback();
          ...
          mutex_unlock(&xenwatch_mutex);
      
      The callback could call unregister_xenbus_watch() which does:
      
          ...
          if (current->pid != xenwatch_pid)
              mutex_lock(&xenwatch_mutex);
          ...
      
      In case a watch is firing before xenwatch_pid could be set and the
      callback of that watch unregisters a watch, then a self-deadlock would
      occur.
      
      Avoid this by setting xenwatch_pid in xenwatch_thread().
      Signed-off-by: 's avatarJuergen Gross <jgross@suse.com>
      Reviewed-by: 's avatarBoris Ostrovsky <boris.ostrovsky@oracle.com>
      Signed-off-by: 's avatarJuergen Gross <jgross@suse.com>
      529871bb
  3. 27 Jul, 2017 3 commits
  4. 23 Jul, 2017 2 commits
  5. 07 Jul, 2017 3 commits
  6. 28 Jun, 2017 1 commit
  7. 25 Jun, 2017 1 commit
    • Juergen Gross's avatar
      xen: avoid deadlock in xenbus driver · 1a3fc2c4
      Juergen Gross authored
      There has been a report about a deadlock in the xenbus driver:
      
      [  247.979498] ======================================================
      [  247.985688] WARNING: possible circular locking dependency detected
      [  247.991882] 4.12.0-rc4-00022-gc4b25c0 #575 Not tainted
      [  247.997040] ------------------------------------------------------
      [  248.003232] xenbus/91 is trying to acquire lock:
      [  248.007875]  (&u->msgbuffer_mutex){+.+.+.}, at: [<ffff00000863e904>]
      xenbus_dev_queue_reply+0x3c/0x230
      [  248.017163]
      [  248.017163] but task is already holding lock:
      [  248.023096]  (xb_write_mutex){+.+...}, at: [<ffff00000863a940>]
      xenbus_thread+0x5f0/0x798
      [  248.031267]
      [  248.031267] which lock already depends on the new lock.
      [  248.031267]
      [  248.039615]
      [  248.039615] the existing dependency chain (in reverse order) is:
      [  248.047176]
      [  248.047176] -> #1 (xb_write_mutex){+.+...}:
      [  248.052943]        __lock_acquire+0x1728/0x1778
      [  248.057498]        lock_acquire+0xc4/0x288
      [  248.061630]        __mutex_lock+0x84/0x868
      [  248.065755]        mutex_lock_nested+0x3c/0x50
      [  248.070227]        xs_send+0x164/0x1f8
      [  248.074015]        xenbus_dev_request_and_reply+0x6c/0x88
      [  248.079427]        xenbus_file_write+0x260/0x420
      [  248.084073]        __vfs_write+0x48/0x138
      [  248.088113]        vfs_write+0xa8/0x1b8
      [  248.091983]        SyS_write+0x54/0xb0
      [  248.095768]        el0_svc_naked+0x24/0x28
      [  248.099897]
      [  248.099897] -> #0 (&u->msgbuffer_mutex){+.+.+.}:
      [  248.106088]        print_circular_bug+0x80/0x2e0
      [  248.110730]        __lock_acquire+0x1768/0x1778
      [  248.115288]        lock_acquire+0xc4/0x288
      [  248.119417]        __mutex_lock+0x84/0x868
      [  248.123545]        mutex_lock_nested+0x3c/0x50
      [  248.128016]        xenbus_dev_queue_reply+0x3c/0x230
      [  248.133005]        xenbus_thread+0x788/0x798
      [  248.137306]        kthread+0x110/0x140
      [  248.141087]        ret_from_fork+0x10/0x40
      
      It is rather easy to avoid by dropping xb_write_mutex before calling
      xenbus_dev_queue_reply().
      
      Fixes: fd8aa909 ("xen: optimize xenbus
      driver for multiple concurrent xenstore accesses").
      
      Cc: <stable@vger.kernel.org> # 4.11
      Reported-by: 's avatarAndre Przywara <andre.przywara@arm.com>
      Signed-off-by: 's avatarJuergen Gross <jgross@suse.com>
      Tested-by: 's avatarAndre Przywara <andre.przywara@arm.com>
      Signed-off-by: 's avatarJuergen Gross <jgross@suse.com>
      1a3fc2c4
  8. 22 Jun, 2017 1 commit
  9. 20 Jun, 2017 3 commits
  10. 15 Jun, 2017 2 commits
  11. 13 Jun, 2017 1 commit
    • Anoob Soman's avatar
      xen-evtchn: Bind dyn evtchn:qemu-dm interrupt to next online VCPU · c48f64ab
      Anoob Soman authored
      A HVM domian booting generates around 200K (evtchn:qemu-dm xen-dyn)
      interrupts,in a short period of time. All these evtchn:qemu-dm are bound
      to VCPU 0, until irqbalance sees these IRQ and moves it to a different VCPU.
      In one configuration, irqbalance runs every 10 seconds, which means
      irqbalance doesn't get to see these burst of interrupts and doesn't
      re-balance interrupts most of the time, making all evtchn:qemu-dm to be
      processed by VCPU0. This cause VCPU0 to spend most of time processing
      hardirq and very little time on softirq. Moreover, if dom0 kernel PREEMPTION
      is disabled, VCPU0 never runs watchdog (process context), triggering a
      softlockup detection code to panic.
      
      Binding evtchn:qemu-dm to next online VCPU, will spread hardirq
      processing evenly across different CPU. Later, irqbalance will try to balance
      evtchn:qemu-dm, if required.
      Signed-off-by: 's avatarAnoob Soman <anoob.soman@citrix.com>
      Reviewed-by: 's avatarBoris Ostrovsky <boris.ostrovsky@oracle.com>
      Signed-off-by: 's avatarJuergen Gross <jgross@suse.com>
      c48f64ab
  12. 07 Jun, 2017 2 commits