6d54cab1fe
This is needed by the event channel user-space device, that requires registering event channels without unmasking them. intr_add_handler will unconditionally unmask the event channel, so we avoid calling it if no filter/handler is provided, and then the user will be in charge of calling it when ready. In order to do this, we need to change the opaque type xen_intr_handle_t to contain the event channel port instead of the opaque cookie returned by intr_add_handler, since now registration of event channels without handlers are allowed. The cookie will now be stored inside of the private xenisrc struct. Also, introduce a new function called xen_intr_add_handler that allows adding a filter/handler after the event channel has been registered. Sponsored by: Citrix Systems R&D x86/xen/xen_intr.c: - Leave the event channel without a handler if no filter/handler is provided to xen_intr_bind_isrc. - Don't perform an evtchn_mask_port, intr_add_handler will already do it. - Change the opaque type xen_intr_handle_t to contain a pointer to the event channel port number, and make the necessary changes to related functions. - Introduce a new function called xen_intr_add_handler that can be used to add filter/handlers to an event channel after registration. xen/xen_intr.h: - Add prototype of xen_intr_add_handler. |
||
|---|---|---|
| .. | ||
| hvm.c | ||
| pv.c | ||
| pvcpu_enum.c | ||
| xen_apic.c | ||
| xen_intr.c | ||
| xen_msi.c | ||
| xen_nexus.c | ||
| xen_pci.c | ||
| xenpv.c | ||