|
[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 |