[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [RFC PATCH V4 18/18] libxl: add evtchn_extended_allowed flag

Let's start with documentation. I came up with two options for libxl, I
plan to choose one from them. The first one is generic, the second one
is 3-level ABI centric.

=item B<max_event_channels=NUMBER>

Maximum number of event channels a guest can use. The number should be within
(0, 32768] for 32 bits guest and (0, 262144] for 64 bits guest. libxl will
decide which ABI to use. In most cases, user doesn't need to use this option.

The default value for this option is 0, which is interpreted by libxl as "use
the default 2-level event channel ABI". Users should be aware that specifying
this option might enable extended event channel ABIs, which consume certain
amount of Xen internal resources (memory, address space). The amount of
resources consumed by the extended ABIs are implementation-specific.

Currently 2/3-level event channel ABIs are available. For 32 bits guest, if
B<max_event_channels> > 1024, 3-level ABI will be used. For 64 bits guest, if
B<max_event_channels> > 4096, 3-level ABI will be used. In other cases, 2-level
ABI will be used. The internal logic of libxl choosing the correct ABI might
change if more ABIs are available.

=item B<event_channel_3level_abi_allowed=BOOLEAN>

Flag for allowing domain to use the 3-level event channel ABI, which is
designed for Dom0 and driver domains. This ABI provides 32K event channels for
32 bits guest and 256K event channels for 64 bits guest.

The default value of this option is false, as this ABI consumes resources
inside Xen (memory, address space). A normal DomU will never use so many event
channels. User may want to enable this ABI for driver domains only.

Which one makes more sense to you?


Xen-devel mailing list



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