[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [Xen-devel] Designing the N-level event channel registration interface
Hi all, I have been thinking about the N-level event channel interface for some time and could not make up my mind. As people suggested in my RFC patch, there should be compat checking / handling for the interface. The interface I have in mind at the moment: /* * EVTCHNOP_register_nlevel: Register N-level event channel * NOTES: * 1. Currently only 3-level is supported. * 2. Should fall back to 2-level if this call fails. */ /* 64 bit guests need 8 pages for evtchn_pending and evtchn_mask for * 256k event channels while 32 bit ones only need 1 page for 32k * event channels. */ #define EVTCHN_MAX_L3_PAGES 8 struct evtchn_register_3level { /* IN parameters */ uint32_t nr_pages; XEN_GUEST_HANDLE(xen_pfn_t) evtchn_pending; XEN_GUEST_HANDLE(xen_pfn_t) evtchn_mask; uint32_t nr_vcpus; XEN_GUEST_HANDLE(void) l2sel; }; struct evtchn_register_nlevel { /* IN parameters. */ uint32_t level; union { struct evtchn_register_3level l3; } u; }; typedef struct evtchn_register_nlevel evtchn_register_nlevel_t; There are 3 XEN_GUEST_HANDLEs in evtchn_register_3level. evtchn_pending / evtchn_mask points to an array which is used to stored pending / mask mfns. l2sel points to an array storing per-vcpu variable for 2nd level selectors. This interface is still very primitive and padding is not accounted for. One way to achieve compat is to write compat/event_channel.c. As other interfaces in event_channel.c don't need compat handling, re-compiling event_channel.c is probably not a good idea. Jan is worried about this. Ian suggested I use XEN_GUEST_HANDLE_64 to get 64-bit clean version and avoid compat layer. Any input is welcomed. Thanks Wei. _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |