[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? Wei. _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |