b5e579232d
When unmask_evtchn is called, if we already have an event pending, we just set evtchn_pending_sel waiting for local_irq_enable to be called. That is because PV guests set the irq_enable pvops to xen_irq_enable_direct in xen_setup_vcpu_info_placement: xen_irq_enable_direct is implemented in assembly in arch/x86/xen/xen-asm.S and call xen_force_evtchn_callback if XEN_vcpu_info_pending is set. However HVM guests (and ARM guests) do not change or do not have the irq_enable pvop, so evtchn_unmask cannot work properly for them. Considering that having the pending_irq bit set when unmask_evtchn is called is not very common, and it is simpler to keep the native_irq_enable implementation for HVM guests (and ARM guests), the best thing to do is just use the EVTCHNOP_unmask hypercall (Xen re-injects pending events in response). Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> |
||
---|---|---|
.. | ||
xen-pciback | ||
xenbus | ||
xenfs | ||
acpi.c | ||
balloon.c | ||
biomerge.c | ||
cpu_hotplug.c | ||
events.c | ||
evtchn.c | ||
features.c | ||
gntalloc.c | ||
gntdev.c | ||
grant-table.c | ||
Kconfig | ||
Makefile | ||
manage.c | ||
pci.c | ||
platform-pci.c | ||
privcmd.c | ||
privcmd.h | ||
swiotlb-xen.c | ||
sys-hypervisor.c | ||
tmem.c | ||
xen-acpi-processor.c | ||
xen-balloon.c | ||
xen-selfballoon.c | ||
xencomm.c |