Re: [PATCH v2 3/3] tools: introduce parameter max_wp_ram_ranges.

["Yu, Zhang" <yu.c.zhang@linux.intel.com>]

On 1/26/2016 7:16 PM, David Vrabel wrote:
> On 22/01/16 03:20, Yu Zhang wrote:
>> --- a/docs/man/xl.cfg.pod.5
>> +++ b/docs/man/xl.cfg.pod.5
>> @@ -962,6 +962,24 @@ FIFO-based event channel ABI support up to 131,071 event channels.
>>   Other guests are limited to 4095 (64-bit x86 and ARM) or 1023 (32-bit
>>   x86).
>>
>> +=item B<max_wp_ram_ranges=N>
>> +
>> +Limit the maximum write-protected ram ranges that can be tracked
>> +inside one ioreq server rangeset.
>> +
>> +Ioreq server uses a group of rangesets to track the I/O or memory
>> +resources to be emulated. Default limit of ranges that one rangeset
>> +can allocate is set to a small value, due to the fact that these ranges
>> +are allocated in xen heap. Yet for the write-protected ram ranges,
>> +there are circumstances under which the upper limit inside one rangeset
>> +should exceed the default one. E.g. in XenGT, when tracking the per-
>> +process graphic translation tables on intel broadwell platforms, the
>> +number of page tables concerned will be several thousand(normally
>> +in this case, 8192 could be a big enough value). Not configuring this
>> +item, or setting its value to 0 will result in the upper limit set
>> +to its default one. Users who set his item explicitly are supposed
>> +to know the specific scenarios that necessitate this configuration.
>
> This help text isn't very helpful.  How is a user supposed to "know the
> specific scenarios" that need this option?
>

Thank you for your comment, David. :)

Well, "know the specific scenarios" may seem too ambiguous. Here the
"specific scenarios" means when this parameter is used:
1> for virtual devices other than vGPU in GVT-g;
2> for GVT-g, there also might be some extreme cases, e.g. too many
graphic related applications in one VM, which create a great deal of
per-process graphic translation tables.
3> for GVT-g, future cpu platforms which provide even more PPGGTs.
Other than these cases, 8192 is a suggested value for this option.

So how about we add a section to point out these scenarios in this
text?

> Why doesn't the toolstack (or qemu) automatically set this value based
> on whether GVT-g/GVT-d is being used? Then there is no need to even
> present this option to the user.
>
> David
>

By now, this parameter is used in GVT-g, but we are expecting more
usages for other devices which adopt this mediated pass-through idea.
Indeed, XenGT has an xl configuration flag, and several other XenGT
specific parameters. We have plans to upstream these options later
this year. After these XenGT options are accepted, we can set this
"max_wp_ram_ranges" to a default value if GVT-g is detected and the
"max_wp_ram_ranges" is not explicitly configured.