Xen devel - Jan 2013 - 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.

On Fri, 2013-01-11 at 12:34 +0000, Wei Liu wrote:
> Ian suggested I use XEN_GUEST_HANDLE_64 to get 64-bit clean version and
> avoid compat layer.
One issue with this which needs specifically considering is that
XEN_GUEST_HANDLE_64 is currently only available/used by control
interfaces (sysctl & domctl) and not by guest APIs. So the question
becomes whether it is acceptable to change that state of affairs.

Ian.

>>> On 11.01.13 at 13:34, Wei Liu <Wei.Liu2@citrix.com> wrote:
> 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.
Indeed. In this case I think either open coding the compat case
or having a helper function that gets compiled twice is the best
route.
> Ian suggested I use XEN_GUEST_HANDLE_64 to get 64-bit clean version and
> avoid compat layer.
So far these exist only in tools interfaces, and the way x86''s
set_xen_guest_handle() works currently you wouldn''t even be
permitted to use those (as the upper halves would remain
uninitialized, hence expected to fail the validity checks within
the hypervisor).

Also, they''re inefficient in terms of kernel side use (albeit in the
case here we''re talking about only one time setup code).

Jan

On Fri, 2013-01-11 at 12:48 +0000, Jan Beulich wrote:
> >>> On 11.01.13 at 13:34, Wei Liu <Wei.Liu2@citrix.com>
wrote:
> > Ian suggested I use XEN_GUEST_HANDLE_64 to get 64-bit clean version
and
> > avoid compat layer.
> 
> So far these exist only in tools interfaces, and the way x86''s
> set_xen_guest_handle() works currently you wouldn''t even be
> permitted to use those (as the upper halves would remain
> uninitialized, hence expected to fail the validity checks within
> the hypervisor).
Yes, if we extend the usage we''d need to add the initialisation of the
other half.
> Also, they''re inefficient in terms of kernel side use (albeit in
the
> case here we''re talking about only one time setup code).
Right.