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
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
