1. 20 8月, 2015 4 次提交
  2. 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
  3. 30 4月, 2015 1 次提交
    • B
      xen: Suspend ticks on all CPUs during suspend · 2b953a5e
      Boris Ostrovsky 提交于
      Commit 77e32c89 ("clockevents: Manage device's state separately for
      the core") decouples clockevent device's modes from states. With this
      change when a Xen guest tries to resume, it won't be calling its
      set_mode op which needs to be done on each VCPU in order to make the
      hypervisor aware that we are in oneshot mode.
      
      This happens because clockevents_tick_resume() (which is an intermediate
      step of resuming ticks on a processor) doesn't call clockevents_set_state()
      anymore and because during suspend clockevent devices on all VCPUs (except
      for the one doing the suspend) are left in ONESHOT state. As result, during
      resume the clockevents state machine will assume that device is already
      where it should be and doesn't need to be updated.
      
      To avoid this problem we should suspend ticks on all VCPUs during
      suspend.
      Signed-off-by: NBoris Ostrovsky <boris.ostrovsky@oracle.com>
      Signed-off-by: NDavid Vrabel <david.vrabel@citrix.com>
      2b953a5e
  4. 27 4月, 2015 1 次提交
  5. 15 4月, 2015 1 次提交
  6. 16 3月, 2015 3 次提交
  7. 02 3月, 2015 1 次提交
  8. 24 2月, 2015 1 次提交
    • D
      x86/xen: allow privcmd hypercalls to be preempted · fdfd811d
      David Vrabel 提交于
      Hypercalls submitted by user space tools via the privcmd driver can
      take a long time (potentially many 10s of seconds) if the hypercall
      has many sub-operations.
      
      A fully preemptible kernel may deschedule such as task in any upcall
      called from a hypercall continuation.
      
      However, in a kernel with voluntary or no preemption, hypercall
      continuations in Xen allow event handlers to be run but the task
      issuing the hypercall will not be descheduled until the hypercall is
      complete and the ioctl returns to user space.  These long running
      tasks may also trigger the kernel's soft lockup detection.
      
      Add xen_preemptible_hcall_begin() and xen_preemptible_hcall_end() to
      bracket hypercalls that may be preempted.  Use these in the privcmd
      driver.
      
      When returning from an upcall, call xen_maybe_preempt_hcall() which
      adds a schedule point if if the current task was within a preemptible
      hypercall.
      
      Since _cond_resched() can move the task to a different CPU, clear and
      set xen_in_preemptible_hcall around the call.
      Signed-off-by: NDavid Vrabel <david.vrabel@citrix.com>
      Reviewed-by: NBoris Ostrovsky <boris.ostrovsky@oracle.com>
      fdfd811d
  9. 28 1月, 2015 5 次提交
  10. 14 1月, 2015 1 次提交
  11. 13 1月, 2015 1 次提交
    • J
      x86/xen: properly retrieve NMI reason · f221b04f
      Jan Beulich 提交于
      Using the native code here can't work properly, as the hypervisor would
      normally have cleared the two reason bits by the time Dom0 gets to see
      the NMI (if passed to it at all). There's a shared info field for this,
      and there's an existing hook to use - just fit the two together. This
      is particularly relevant so that NMIs intended to be handled by APEI /
      GHES actually make it to the respective handler.
      
      Note that the hook can (and should) be used irrespective of whether
      being in Dom0, as accessing port 0x61 in a DomU would be even worse,
      while the shared info field would just hold zero all the time. Note
      further that hardware NMI handling for PVH doesn't currently work
      anyway due to missing code in the hypervisor (but it is expected to
      work the native rather than the PV way).
      Signed-off-by: NJan Beulich <jbeulich@suse.com>
      Reviewed-by: NBoris Ostrovsky <boris.ostrovsky@oracle.com>
      Signed-off-by: NDavid Vrabel <david.vrabel@citrix.com>
      f221b04f
  12. 04 12月, 2014 2 次提交
  13. 06 10月, 2014 1 次提交
  14. 03 10月, 2014 1 次提交
  15. 23 9月, 2014 2 次提交
  16. 12 9月, 2014 1 次提交
  17. 30 7月, 2014 1 次提交
    • D
      x86/xen: safely map and unmap grant frames when in atomic context · b7dd0e35
      David Vrabel 提交于
      arch_gnttab_map_frames() and arch_gnttab_unmap_frames() are called in
      atomic context but were calling alloc_vm_area() which might sleep.
      
      Also, if a driver attempts to allocate a grant ref from an interrupt
      and the table needs expanding, then the CPU may already by in lazy MMU
      mode and apply_to_page_range() will BUG when it tries to re-enable
      lazy MMU mode.
      
      These two functions are only used in PV guests.
      
      Introduce arch_gnttab_init() to allocates the virtual address space in
      advance.
      
      Avoid the use of apply_to_page_range() by using saving and using the
      array of PTE addresses from the alloc_vm_area() call (which ensures
      that the required page tables are pre-allocated).
      Signed-off-by: NDavid Vrabel <david.vrabel@citrix.com>
      Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      b7dd0e35
  18. 19 7月, 2014 3 次提交
  19. 15 7月, 2014 2 次提交
  20. 05 6月, 2014 1 次提交
  21. 29 5月, 2014 1 次提交
  22. 13 5月, 2014 1 次提交
  23. 24 4月, 2014 1 次提交
    • I
      arm: xen: implement multicall hypercall support. · 5e40704e
      Ian Campbell 提交于
      As part of this make the usual change to xen_ulong_t in place of unsigned long.
      This change has no impact on x86.
      
      The Linux definition of struct multicall_entry.result differs from the Xen
      definition, I think for good reasons, and used a long rather than an unsigned
      long. Therefore introduce a xen_long_t, which is a long on x86 architectures
      and a signed 64-bit integer on ARM.
      
      Use uint32_t nr_calls on x86 for consistency with the ARM definition.
      
      Build tested on amd64 and i386 builds. Runtime tested on ARM.
      Signed-off-by: NIan Campbell <ian.campbell@citrix.com>
      Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
      Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>
      Signed-off-by: NDavid Vrabel <david.vrabel@citrix.com>
      5e40704e
  24. 18 3月, 2014 2 次提交
    • S
      xen/acpi-processor: fix enabling interrupts on syscore_resume · cd979883
      Stanislaw Gruszka 提交于
      syscore->resume() callback is expected to do not enable interrupts,
      it generates warning like below otherwise:
      
      [ 9386.365390] WARNING: CPU: 0 PID: 6733 at drivers/base/syscore.c:104 syscore_resume+0x9a/0xe0()
      [ 9386.365403] Interrupts enabled after xen_acpi_processor_resume+0x0/0x34 [xen_acpi_processor]
      ...
      [ 9386.365429] Call Trace:
      [ 9386.365434]  [<ffffffff81667a8b>] dump_stack+0x45/0x56
      [ 9386.365437]  [<ffffffff8106921d>] warn_slowpath_common+0x7d/0xa0
      [ 9386.365439]  [<ffffffff8106928c>] warn_slowpath_fmt+0x4c/0x50
      [ 9386.365442]  [<ffffffffa0261bb0>] ? xen_upload_processor_pm_data+0x300/0x300 [xen_acpi_processor]
      [ 9386.365443]  [<ffffffff814055fa>] syscore_resume+0x9a/0xe0
      [ 9386.365445]  [<ffffffff810aef42>] suspend_devices_and_enter+0x402/0x470
      [ 9386.365447]  [<ffffffff810af128>] pm_suspend+0x178/0x260
      
      On xen_acpi_processor_resume() we call various procedures, which are
      non atomic and can enable interrupts. To prevent the issue introduce
      separate resume notify called after we enable interrupts on resume
      and before we call other drivers resume callbacks.
      Signed-off-by: NStanislaw Gruszka <sgruszka@redhat.com>
      Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      cd979883
    • 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
  25. 01 3月, 2014 1 次提交