From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Chen, Tiejun" Subject: Re: [v10][PATCH 11/16] tools/libxl: detect and avoid conflicts with RDM Date: Tue, 21 Jul 2015 19:04:10 +0800 Message-ID: <55AE272A.4020306@intel.com> References: <1437373023-14884-1-git-send-email-tiejun.chen@intel.com> <1437373023-14884-12-git-send-email-tiejun.chen@intel.com> <21932.63595.566823.211293@mariner.uk.xensource.com> <21934.8684.318670.874156@mariner.uk.xensource.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <21934.8684.318670.874156@mariner.uk.xensource.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Ian Jackson , xen-devel@lists.xen.org, Stefano Stabellini , Ian Campbell , Wei Liu List-Id: xen-devel@lists.xenproject.org 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