Re: [v10][PATCH 11/16] tools/libxl: detect and avoid conflicts with RDM

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

On 2015/7/21 18:41, Ian Jackson wrote:
> I wrote:
>> If the domain configuration has rdms and num_rdms already set, then
>> the strategy should presumably be ignored.  (Passing the same domain
>> configuration struct to libxl_domain_create_new, after destroying the
>> domain, ought to work, even after the first call has modified it.)
>
> But even your latest patch adds the host rdm's (from the strategy
> algorithm) to the array, unconditionally.
>
> I think you need to think more clearly about what happens when the
> caller *both* supplies some rdms, and sets strategy=host.
>
> Certainly if this happens and the set of rdms supplied is the same as
> that which would be generated by the strategy, the set should not be
> duplicated.
>

I can understand we shouldn't duplicate any existing entries. But based 
on our current design, I think we don't allow this happened. And I think 
this is more like to support sort of group devices that means two or 
more devices share same RMRR entry. But currently we don't support group 
devices as we did in patch #15.

So in this perspective, what's out last policy is not clear. And 
actually as we discussed previously with other guys, this is our next 
step after this series. So we won't extend this assumption and 
especially, I also can confirm this is only one place to construct RDM now.

I would add this check at the beginning of this function:

assert(!d_config->num_rdms && !d_config->rdms).

Thanks
Tiejun