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. |
||
|---|---|---|
| .. | ||
| evtchn | ||
| interface | ||
| xenbus | ||
| xenstore | ||
| blkif.h | ||
| evtchn.h | ||
| features.c | ||
| features.h | ||
| gnttab.c | ||
| gnttab.h | ||
| hvm.h | ||
| hypervisor.h | ||
| xen_intr.h | ||
| xen_msi.h | ||
| xen_pv.h | ||
| xen-os.h | ||