[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
 *  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. */
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.


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.