Re: [v4][PATCH 15/19] tools: introduce a new parameter to set a predefined rdm boundary

["Chen, Tiejun" <tiejun.chen@intel.com>]

>> diff --git a/docs/man/xl.cfg.pod.5 b/docs/man/xl.cfg.pod.5
>> index 638b350..079465f 100644
>> --- a/docs/man/xl.cfg.pod.5
>> +++ b/docs/man/xl.cfg.pod.5
>> @@ -767,6 +767,27 @@ to a given device, and "strict" is default here.
>>
>>   Note this would override global B<rdm> option.
>>
>> +=item B<rdm_mem_boundary=MBYTES>
>> +
>> +Number of megabytes to set a boundary for checking rdm conflict.
>> +
>> +When RDM conflicts with RAM, RDM probably scatter the whole RAM space.
>> +Especially multiple RDM entries would worsen this to lead a complicated
>> +memory layout. So here we're trying to figure out a simple solution to
>> +avoid breaking existing layout. So when a conflict occurs,
>> +
>> +    #1. Above a predefined boundary
>> +        - move lowmem_end below reserved region to solve conflict;
>> +
>> +    #2. Below a predefined boundary
>> +        - Check strict/relaxed policy.
>> +        "strict" policy leads to fail libxl. Note when both policies
>> +        are specified on a given region, 'strict' is always preferred.
>> +        "relaxed" policy issue a warning message and also mask this entry INVALID
>> +        to indicate we shouldn't expose this entry to hvmloader.
>> +
>
> Can you check the generated manpage to see if the format is correct?
>

Yes, the format is correct but according to your comment below, I need 
to move this elsewhere.

>> +Here the default is 2G.
>> +
>>   =back
>>

[snip]

>>       if (ret) {
>>           LOG(ERROR, "checking reserved device memory failed");
>> diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
>> index 5ba075d..d130d48 100644
>> --- a/tools/libxl/libxl_types.idl
>> +++ b/tools/libxl/libxl_types.idl
>> @@ -395,6 +395,7 @@ libxl_domain_build_info = Struct("domain_build_info",[
>>       ("target_memkb",    MemKB),
>>       ("video_memkb",     MemKB),
>>       ("shadow_memkb",    MemKB),
>> +    ("rdm_mem_boundary_memkb",    MemKB),
>
> Should this be restricted to .hvm? This is HVM only feature after all.
>

Yes, I think this make sense but I think should move that parameter, 
"rdm" into .hvm as well.

Thanks
Tiejun