|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [v10][PATCH 11/16] tools/libxl: detect and avoid conflicts with RDM
Tiejun Chen writes ("[v10][PATCH 11/16] tools/libxl: detect and avoid conflicts
with RDM"):
> While building a VM, HVM domain builder provides struct hvm_info_table{}
> to help hvmloader. Currently it includes two fields to construct guest
> e820 table by hvmloader, low_mem_pgend and high_mem_pgend. So we should
> check them to fix any conflict with RDM.
...
Thanks. I think this patch is nearly there.
> +static int
> +libxl__xc_device_get_rdm(libxl__gc *gc,
...
> + *xrdm = libxl__malloc(gc,
> + *nr_entries *
> sizeof(xen_reserved_device_memory_t));
Sorry for not spotting this before, but this should use GCNEW_ARRAY.
> +}
> +
> +#define pfn_to_paddr(x) ((uint64_t)x << XC_PAGE_SHIFT)
> +static void
Missing blank line after the #define - although I think this #define
could profitably be moved to libxl_internal.h. If you do keep it here
please move it further up the file, to at least before any function
or struct definition.
Also the #define is missing safety ( ) around x.
> +set_rdm_entries(libxl__gc *gc, libxl_domain_config *d_config,
> + uint64_t rdm_start, uint64_t rdm_size, int rdm_policy,
> + unsigned int nr_entries)
> +{
> + assert(nr_entries);
> +
> + d_config->num_rdms = nr_entries;
> + 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 for breaking this out. I think though that the division of
labour between this function and the call site is confusing.
Can I suggest a function
void add_rdm_entry(libxl__gc *gc, libxl_domain_config *d_config,
uint64_t rdm_start, uint64_t rdm_size, int rdm_policy)
which assumes that d_config->num_rdms is set correctly, and increments
it ?
(Please put the increment at the end so that the assignments are to
->rdms[d_config->num_rdms], or perhaps make a convenience alias.)
> +int libxl__domain_device_construct_rdm(libxl__gc *gc,
> + libxl_domain_config *d_config,
> + uint64_t rdm_mem_boundary,
> + struct xc_hvm_build_args *args)
> +{
...
> + /* Query all RDM entries in this platform */
> + if (strategy == LIBXL_RDM_RESERVE_STRATEGY_HOST) {
...
> + } else {
> + d_config->num_rdms = 0;
> + }
Does this not override the domain configuration's num_rdms ? I don't
think that is correct.
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.)
Can you please also wrap at least the already-word-wrapped comments to
70 (or maybe 75) columns ? What you have lookes like this when I
quote it for review:
> + * Next step is to check and avoid potential conflict between RDM entri\
es
> + * and guest RAM. To avoid intrusive impact to existing memory layout
> + * {lowmem, mmio, highmem} which is passed around various function bloc\
ks,
> + * below conflicts are not handled which are rare and handling them wou\
ld
Thanks,
Ian.
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |