[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


 


Rackspace

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