1. 14 9月, 2018 1 次提交
  2. 22 6月, 2018 1 次提交
  3. 01 3月, 2018 1 次提交
  4. 29 8月, 2017 1 次提交
  5. 11 8月, 2017 1 次提交
  6. 28 7月, 2017 1 次提交
  7. 23 6月, 2017 1 次提交
  8. 13 6月, 2017 1 次提交
    • A
      xen-evtchn: Bind dyn evtchn:qemu-dm interrupt to next online VCPU · c48f64ab
      Anoob Soman 提交于
      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: NAnoob Soman <anoob.soman@citrix.com>
      Reviewed-by: NBoris Ostrovsky <boris.ostrovsky@oracle.com>
      Signed-off-by: NJuergen Gross <jgross@suse.com>
      c48f64ab
  9. 02 5月, 2017 1 次提交
    • B
      xen: Revert commits da72ff5b and 72a9b186 · 84d582d2
      Boris Ostrovsky 提交于
      Recent discussion (http://marc.info/?l=xen-devel&m=149192184523741)
      established that commit 72a9b186 ("xen: Remove event channel
      notification through Xen PCI platform device") (and thus commit
      da72ff5b ("partially revert "xen: Remove event channel
      notification through Xen PCI platform device"")) are unnecessary and,
      in fact, prevent HVM guests from booting on Xen releases prior to 4.0
      
      Therefore we revert both of those commits.
      
      The summary of that discussion is below:
      
        Here is the brief summary of the current situation:
      
        Before the offending commit (72a9b186):
      
        1) INTx does not work because of the reset_watches path.
        2) The reset_watches path is only taken if you have Xen > 4.0
        3) The Linux Kernel by default will use vector inject if the hypervisor
           support. So even INTx does not work no body running the kernel with
           Xen > 4.0 would notice. Unless he explicitly disabled this feature
           either in the kernel or in Xen (and this can only be disabled by
           modifying the code, not user-supported way to do it).
      
        After the offending commit (+ partial revert):
      
        1) INTx is no longer support for HVM (only for PV guests).
        2) Any HVM guest The kernel will not boot on Xen < 4.0 which does
           not have vector injection support. Since the only other mode
           supported is INTx which.
      
        So based on this summary, I think before commit (72a9b186) we were
        in much better position from a user point of view.
      Signed-off-by: NBoris Ostrovsky <boris.ostrovsky@oracle.com>
      Reviewed-by: NJuergen Gross <jgross@suse.com>
      Signed-off-by: NJuergen Gross <jgross@suse.com>
      84d582d2
  10. 07 2月, 2017 1 次提交
  11. 10 12月, 2016 1 次提交
  12. 30 11月, 2016 1 次提交
  13. 18 11月, 2016 1 次提交
  14. 30 9月, 2016 1 次提交
    • K
      xen: Remove event channel notification through Xen PCI platform device · 72a9b186
      KarimAllah Ahmed 提交于
      Ever since commit 254d1a3f ("xen/pv-on-hvm kexec: shutdown watches
      from old kernel") using the INTx interrupt from Xen PCI platform
      device for event channel notification would just lockup the guest
      during bootup.  postcore_initcall now calls xs_reset_watches which
      will eventually try to read a value from XenStore and will get stuck
      on read_reply at XenBus forever since the platform driver is not
      probed yet and its INTx interrupt handler is not registered yet. That
      means that the guest can not be notified at this moment of any pending
      event channels and none of the per-event handlers will ever be invoked
      (including the XenStore one) and the reply will never be picked up by
      the kernel.
      
      The exact stack where things get stuck during xenbus_init:
      
      -xenbus_init
       -xs_init
        -xs_reset_watches
         -xenbus_scanf
          -xenbus_read
           -xs_single
            -xs_single
             -xs_talkv
      
      Vector callbacks have always been the favourite event notification
      mechanism since their introduction in commit 38e20b07 ("x86/xen:
      event channels delivery on HVM.") and the vector callback feature has
      always been advertised for quite some time by Xen that's why INTx was
      broken for several years now without impacting anyone.
      
      Luckily this also means that event channel notification through INTx
      is basically dead-code which can be safely removed without impacting
      anybody since it has been effectively disabled for more than 4 years
      with nobody complaining about it (at least as far as I'm aware of).
      
      This commit removes event channel notification through Xen PCI
      platform device.
      
      Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>
      Cc: David Vrabel <david.vrabel@citrix.com>
      Cc: Juergen Gross <jgross@suse.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: x86@kernel.org
      Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      Cc: Bjorn Helgaas <bhelgaas@google.com>
      Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
      Cc: Julien Grall <julien.grall@citrix.com>
      Cc: Vitaly Kuznetsov <vkuznets@redhat.com>
      Cc: Paul Gortmaker <paul.gortmaker@windriver.com>
      Cc: Ross Lagerwall <ross.lagerwall@citrix.com>
      Cc: xen-devel@lists.xenproject.org
      Cc: linux-kernel@vger.kernel.org
      Cc: linux-pci@vger.kernel.org
      Cc: Anthony Liguori <aliguori@amazon.com>
      Signed-off-by: NKarimAllah Ahmed <karahmed@amazon.de>
      Reviewed-by: NBoris Ostrovsky <boris.ostrovsky@oracle.com>
      Signed-off-by: NDavid Vrabel <david.vrabel@citrix.com>
      72a9b186
  15. 25 7月, 2016 2 次提交
  16. 24 5月, 2016 1 次提交
    • R
      xen/events: Don't move disabled irqs · f0f39387
      Ross Lagerwall 提交于
      Commit ff1e22e7 ("xen/events: Mask a moving irq") open-coded
      irq_move_irq() but left out checking if the IRQ is disabled. This broke
      resuming from suspend since it tries to move a (disabled) irq without
      holding the IRQ's desc->lock. Fix it by adding in a check for disabled
      IRQs.
      
      The resulting stacktrace was:
      kernel BUG at /build/linux-UbQGH5/linux-4.4.0/kernel/irq/migration.c:31!
      invalid opcode: 0000 [#1] SMP
      Modules linked in: xenfs xen_privcmd ...
      CPU: 0 PID: 9 Comm: migration/0 Not tainted 4.4.0-22-generic #39-Ubuntu
      Hardware name: Xen HVM domU, BIOS 4.6.1-xs125180 05/04/2016
      task: ffff88003d75ee00 ti: ffff88003d7bc000 task.ti: ffff88003d7bc000
      RIP: 0010:[<ffffffff810e26e2>]  [<ffffffff810e26e2>] irq_move_masked_irq+0xd2/0xe0
      RSP: 0018:ffff88003d7bfc50  EFLAGS: 00010046
      RAX: 0000000000000000 RBX: ffff88003d40ba00 RCX: 0000000000000001
      RDX: 0000000000000001 RSI: 0000000000000100 RDI: ffff88003d40bad8
      RBP: ffff88003d7bfc68 R08: 0000000000000000 R09: ffff88003d000000
      R10: 0000000000000000 R11: 000000000000023c R12: ffff88003d40bad0
      R13: ffffffff81f3a4a0 R14: 0000000000000010 R15: 00000000ffffffff
      FS:  0000000000000000(0000) GS:ffff88003da00000(0000) knlGS:0000000000000000
      CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      CR2: 00007fd4264de624 CR3: 0000000037922000 CR4: 00000000003406f0
      DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
      Stack:
       ffff88003d40ba38 0000000000000024 0000000000000000 ffff88003d7bfca0
       ffffffff814c8d92 00000010813ef89d 00000000805ea732 0000000000000009
       0000000000000024 ffff88003cc39b80 ffff88003d7bfce0 ffffffff814c8f66
      Call Trace:
       [<ffffffff814c8d92>] eoi_pirq+0xb2/0xf0
       [<ffffffff814c8f66>] __startup_pirq+0xe6/0x150
       [<ffffffff814ca659>] xen_irq_resume+0x319/0x360
       [<ffffffff814c7e75>] xen_suspend+0xb5/0x180
       [<ffffffff81120155>] multi_cpu_stop+0xb5/0xe0
       [<ffffffff811200a0>] ? cpu_stop_queue_work+0x80/0x80
       [<ffffffff811203d0>] cpu_stopper_thread+0xb0/0x140
       [<ffffffff810a94e6>] ? finish_task_switch+0x76/0x220
       [<ffffffff810ca731>] ? __raw_callee_save___pv_queued_spin_unlock+0x11/0x20
       [<ffffffff810a3935>] smpboot_thread_fn+0x105/0x160
       [<ffffffff810a3830>] ? sort_range+0x30/0x30
       [<ffffffff810a0588>] kthread+0xd8/0xf0
       [<ffffffff810a04b0>] ? kthread_create_on_node+0x1e0/0x1e0
       [<ffffffff8182568f>] ret_from_fork+0x3f/0x70
       [<ffffffff810a04b0>] ? kthread_create_on_node+0x1e0/0x1e0
      Signed-off-by: NRoss Lagerwall <ross.lagerwall@citrix.com>
      Reviewed-by: NBoris Ostrovsky <boris.ostrovsky@oracle.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: NDavid Vrabel <david.vrabel@citrix.com>
      f0f39387
  17. 04 4月, 2016 1 次提交
    • B
      xen/events: Mask a moving irq · ff1e22e7
      Boris Ostrovsky 提交于
      Moving an unmasked irq may result in irq handler being invoked on both
      source and target CPUs.
      
      With 2-level this can happen as follows:
      
      On source CPU:
              evtchn_2l_handle_events() ->
                  generic_handle_irq() ->
                      handle_edge_irq() ->
                         eoi_pirq():
                             irq_move_irq(data);
      
                             /***** WE ARE HERE *****/
      
                             if (VALID_EVTCHN(evtchn))
                                 clear_evtchn(evtchn);
      
      If at this moment target processor is handling an unrelated event in
      evtchn_2l_handle_events()'s loop it may pick up our event since target's
      cpu_evtchn_mask claims that this event belongs to it *and* the event is
      unmasked and still pending. At the same time, source CPU will continue
      executing its own handle_edge_irq().
      
      With FIFO interrupt the scenario is similar: irq_move_irq() may result
      in a EVTCHNOP_unmask hypercall which, in turn, may make the event
      pending on the target CPU.
      
      We can avoid this situation by moving and clearing the event while
      keeping event masked.
      Signed-off-by: NBoris Ostrovsky <boris.ostrovsky@oracle.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: NDavid Vrabel <david.vrabel@citrix.com>
      ff1e22e7
  18. 21 3月, 2016 1 次提交
  19. 27 11月, 2015 1 次提交
  20. 23 10月, 2015 1 次提交
  21. 09 9月, 2015 1 次提交
  22. 20 8月, 2015 1 次提交
    • J
      xen/events: Support event channel rebind on ARM · 4a5b6946
      Julien Grall 提交于
      Currently, the event channel rebind code is gated with the presence of
      the vector callback.
      
      The virtual interrupt controller on ARM has the concept of per-CPU
      interrupt (PPI) which allow us to support per-VCPU event channel.
      Therefore there is no need of vector callback for ARM.
      
      Xen is already using a free PPI to notify the guest VCPU of an event.
      Furthermore, the xen code initialization in Linux (see
      arch/arm/xen/enlighten.c) is requesting correctly a per-CPU IRQ.
      
      Introduce new helper xen_support_evtchn_rebind to allow architecture
      decide whether rebind an event is support or not. It will always return
      true on ARM and keep the same behavior on x86.
      
      This is also allow us to drop the usage of xen_have_vector_callback
      entirely in the ARM code.
      Signed-off-by: NJulien Grall <julien.grall@citrix.com>
      Signed-off-by: NDavid Vrabel <david.vrabel@citrix.com>
      4a5b6946
  23. 11 8月, 2015 1 次提交
  24. 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
  25. 14 7月, 2015 1 次提交
  26. 17 6月, 2015 1 次提交
  27. 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
  28. 06 5月, 2015 2 次提交
    • B
      xen/events: Set irq_info->evtchn before binding the channel to CPU in __startup_pirq() · 16e6bd59
      Boris Ostrovsky 提交于
      .. because bind_evtchn_to_cpu(evtchn, cpu) will map evtchn to
      'info' and pass 'info' down to xen_evtchn_port_bind_to_cpu().
      Signed-off-by: NBoris Ostrovsky <boris.ostrovsky@oracle.com>
      Tested-by: NAnnie Li <annie.li@oracle.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: NDavid Vrabel <david.vrabel@citrix.com>
      16e6bd59
    • B
      xen/events: Clear cpu_evtchn_mask before resuming · 5cec9883
      Boris Ostrovsky 提交于
      When a guest is resumed, the hypervisor may change event channel
      assignments. If this happens and the guest uses 2-level events it
      is possible for the interrupt to be claimed by wrong VCPU since
      cpu_evtchn_mask bits may be stale. This can happen even though
      evtchn_2l_bind_to_cpu() attempts to clear old bits: irq_info that
      is passed in is not necessarily the original one (from pre-migration
      times) but instead is freshly allocated during resume and so any
      information about which CPU the channel was bound to is lost.
      
      Thus we should clear the mask during resume.
      
      We also need to make sure that bits for xenstore and console channels
      are set when these two subsystems are resumed. While rebind_evtchn_irq()
      (which is invoked for both of them on a resume) calls irq_set_affinity(),
      the latter will in fact postpone setting affinity until handling the
      interrupt. But because cpu_evtchn_mask will have bits for these two
      cleared we won't be able to take the interrupt.
      
      With that in mind, we need to bind those two channels explicitly in
      rebind_evtchn_irq(). We will keep irq_set_affinity() so that we have a
      pass through generic irq affinity code later, in case something needs
      to be updated there as well.
      
      (Also replace cpumask_of(0) with cpumask_of(info->cpu) in
      rebind_evtchn_irq(): it should be set to zero in preceding
      xen_irq_info_evtchn_setup().)
      Signed-off-by: NBoris Ostrovsky <boris.ostrovsky@oracle.com>
      Reported-by: NAnnie Li <annie.li@oracle.com>
      Cc: <stable@vger.kernel.org> # 3.14+
      Signed-off-by: NDavid Vrabel <david.vrabel@citrix.com>
      5cec9883
  29. 06 3月, 2015 1 次提交
    • J
      xen/events: avoid NULL pointer dereference in dom0 on large machines · 85e40b05
      Juergen Gross 提交于
      Using the pvops kernel a NULL pointer dereference was detected on a
      large machine (144 processors) when booting as dom0 in
      evtchn_fifo_unmask() during assignment of a pirq.
      
      The event channel in question was the first to need a new entry in
      event_array[] in events_fifo.c. Unfortunately xen_irq_info_pirq_setup()
      is called with evtchn being 0 for a new pirq and the real event channel
      number is assigned to the pirq only during __startup_pirq().
      
      It is mandatory to call xen_evtchn_port_setup() after assigning the
      event channel number to the pirq to make sure all memory needed for the
      event channel is allocated.
      Signed-off-by: NJuergen Gross <jgross@suse.com>
      Cc: <stable@vger.kernel.org> # 3.14+
      Signed-off-by: NDavid Vrabel <david.vrabel@citrix.com>
      85e40b05
  30. 23 9月, 2014 1 次提交
  31. 01 8月, 2014 1 次提交
  32. 16 5月, 2014 1 次提交
  33. 07 4月, 2014 1 次提交
    • A
      Xen: do hv callback accounting only on x86 · d06eb3ee
      Arnd Bergmann 提交于
      Patch 99c8b79d "xen: Add proper irq accounting for HYPERCALL vector"
      added a call to inc_irq_stat(irq_hv_callback_count) in common Xen code,
      however both the inc_irq_stat function and the irq_hv_callback_count
      counter are architecture specific.
      
      This makes the code build again on ARM by moving the call into the
      existing #ifdef CONFIG_X86. We may want to later do the same implementation
      on ARM that x86 has though.
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Signed-off-by: NDavid Vrabel <david.vrabel@citrix.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      Cc: Xen <xen-devel@lists.xenproject.org>
      d06eb3ee
  34. 18 3月, 2014 1 次提交
    • R
      xen: add support for MSI message groups · 4892c9b4
      Roger Pau Monne 提交于
      Add support for MSI message groups for Xen Dom0 using the
      MAP_PIRQ_TYPE_MULTI_MSI pirq map type.
      
      In order to keep track of which pirq is the first one in the group all
      pirqs in the MSI group except for the first one have the newly
      introduced PIRQ_MSI_GROUP flag set. This prevents calling
      PHYSDEVOP_unmap_pirq on them, since the unmap must be done with the
      first pirq in the group.
      Signed-off-by: NRoger Pau Monné <roger.pau@citrix.com>
      Signed-off-by: NDavid Vrabel <david.vrabel@citrix.com>
      Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>
      4892c9b4
  35. 12 3月, 2014 1 次提交
  36. 05 3月, 2014 3 次提交
新手
引导
客服 返回
顶部