On 2015/7/21 19:11, Ian Jackson wrote:
Chen, Tiejun writes ("Re: [v10][PATCH 11/16] tools/libxl: detect and avoid conflicts
with RDM"):
I would add this check at the beginning of this function:
assert(!d_config->num_rdms && !d_config->rdms).
As Ian Campbell and I have explained, that is not OK.
The caller may choose to pass both some rdms and strategy=host.
The most obvious case is something like the following code
libxl_domain_config cfg;
cfg.stuff = blah;
cfg.rdm.strategy = HOST;
libxl_domain_create_new(&cfg, &domid);
libxl_domain_destroy(domid);
I'm not sure about this procedure, so do you mean this doesn't free
d_config->num_rdms/d_config->rdms?
If not, I should double check this duplication so what about a return in
the case of duplicating one entry?
static void
add_rdm_entry(libxl__gc *gc, libxl_domain_config *d_config,
uint64_t rdm_start, uint64_t rdm_size, int rdm_policy)
{
if (d_config->rdms)
{
unsigned int i;
for (i = 0; i < d_config->num_rdms; i++)
{
if (d_config->rdms[i].start == rdm_start)
return;
}
}
d_config->num_rdms++;
d_config->rdms = libxl__realloc(NOGC, d_config->rdms,
d_config->num_rdms * sizeof(libxl_device_rdm));
d_config->rdms[d_config->num_rdms - 1].start = rdm_start;
d_config->rdms[d_config->num_rdms - 1].size = rdm_size;
d_config->rdms[d_config->num_rdms - 1].policy = rdm_policy;
}
Thanks
Tiejun
libxl_domain_create_new(&cfg, &domid);
which must work (and the second domain should have identical
configuration to the first).
Ian.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel