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

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

On 1/27/2016 11:58 PM, Jan Beulich wrote:
>>>> On 27.01.16 at 16:23, <yu.c.zhang@linux.intel.com> wrote:
>
>>
>> On 1/27/2016 11:12 PM, Jan Beulich wrote:
>>>>>> On 27.01.16 at 15:56, <yu.c.zhang@linux.intel.com> wrote:
>>>> On 1/27/2016 10:32 PM, Jan Beulich wrote:
>>>>>>>> On 27.01.16 at 15:13, <yu.c.zhang@linux.intel.com> wrote:
>>>>>> About the truncation issue:
>>>>>>       I do not quite follow. Will this hurt if the value configured does
>>>>>> not exceed 4G? What about a type cast?
>>>>>
>>>>> A typecast would not alter behavior in any way. And of course
>>>>> a problem only arises if the value was above 4 billion. You either
>>>>> need to refuse such values while the attempt is made to set it.
>>>>> or you need to deal with the full range of possible values. Likely
>>>>> the former is the better (and I wonder whether the upper
>>>>> bound shouldn't be forced even lower than 4 billion).
>>>>
>>>> Oh, I see. A check with the upper bound sounds better. Using 4G as the
>>>> upper bound is a little conservative, but I do not have any better
>>>> criteria right now. :)
>>>
>>> But when making that decision keep security in mind: How much
>>> memory would it take to populate 4G rangeset nodes?
>>>
>> Well, for XenGT, one extreme case I can imagine would be half of all
>> the guest ram is used as the GPU page table, and page frames containing
>> these page tables are discontinuous (rangeset can combine continuous
>> ranges). For other virtual devices to leverage the write-protected gfn
>> rangeset, I believe the same idea applies. :)
>> Is this logic OK?
>
> I can follow it, yes, but 4G ranges mean 16Tb of memory put
> in page tables, which to be honest doesn't seem reasonable to
> me.
>

Thanks for your reply, Jan.
In most cases max_memkb in configuration file will not be set to such a
big value. So I'd suggest we use a comparison between the one
calculated from max_memkb and 4G, and choose the smaller one as upper
bound. If some time in the future, it becomes common cases for VMs to
use huge rams, we should use uint64 for the rangeset limit other than a 
uint32.

Yu