[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] Alternate p2m design specification
>>> On 10.06.15 at 18:39, <edmund.h.white@xxxxxxxxx> wrote: > On 06/10/2015 12:43 AM, Jan Beulich wrote: >>>>> On 10.06.15 at 02:09, <edmund.h.white@xxxxxxxxx> wrote: >>> Design >>> ====== >> >> Reads all quite reasonable; just one minor remark: >> >>> - Core altp2m functionality >>> >>> A new altp2m type is added to the p2m types (in addition to the previous >>> hostp2m and nestedp2m types). An HVM domain can be started in hostp2m mode >>> and switched over into altp2m mode via a hypercall. Once a HVM domain is in >>> altp2m mode, a set of (currently set size is 10) altp2m objects is managed > by >>> Xen. >> >> Rather than hardcoding 10, how about making the Xen command line >> option specify the value (instead of being a simple boolean one)? > > For the use cases we're currently aware of, even 10 is generous. I'd be > wary of allowing the user to specify any number up to and including 512 > with the current implementation, because there are a number of places where > we do a linear search of the list. I was actually considering this to allow the user to reduce the value below 10. > In practice, 1 alternate p2m is not useful, so in a future version of the > code, when we have more idea of how useful people find it, we could say > 0=off, 1=on with 10 alternates, any other number=on with that many > alternates. > > Does that seem reasonable? That's certainly an option, but using only a number from the beginning would simplify the handling of the option in the hypervisor. But of course that's only a very minor aspect. Jan _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |