Re: [Xen-devel] [RFC][PATCH 10/13] tools: extend XENMEM_set_memory_map

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

Wei,

Thanks for your quick comment.

> > +static int libxl__domain_construct_memmap(libxl_ctx *ctx,
> Internal function should take libxl__gc *gc.
Right.

> > +                                          libxl_domain_config *d_config,
> > +                                          uint32_t domid,
> > +                                          struct xc_hvm_build_args *args,
> > +                                          int num_pcidevs,
> > +                                          libxl_device_pci *pcidevs)
> I think domid, num_pcidevs and pcidevs should be in d_config by the
> time you call this function? At least num_pcidevs and pcidevs should be
Yes, but looks 'domid' is still needed.

> available.
>
> That said, I don't see pci stuff being used anywhere in the function, so
> please just delete them.
Sorry I really should clean these stuffs.

> > +{
> > +    unsigned int nr = 0, i;
> > +    /* We always own at least one lowmem entry. */
> > +    unsigned int e820_entries = 1;
> > +    uint64_t highmem_end = 0, highmem_size = args->mem_size - 
> > args->lowmem_size;
> FWIW there are some new output fields called lowmem_end, highmem_end and
> mmio_start in xc_hvm_build_args. Those might be useful as well?
No. These e820 entries will be used in hvmloader.

Note these constructed e820 info are based on args->mem_size, 
args->lowmem_size and args->mmio_size. And looks these fields are never 
changed inside xc_hvm_build_args().
> Note that they are only available *after* calling xc_hvm_build, which
> seems to *not* be the case for you.
>
> So if you somehow find those fields useful you might want to consider
> moving the callsite a bit later.
But I think I'd better follow your logic here since we can't guarantee 
all related fields wouldn't be modified in the future.
So I will push libxl__domain_construct_memmap() after xc_hvm_build_args().

> > +    struct e820entry *e820 = NULL;
> > +
> > +    /* Add all rdm entries. */
> > +    e820_entries += d_config->num_rdms;
> > +
> > +    /* If we should have a highmem range. */
> > +    if (highmem_size)
> > +    {
> > +        highmem_end = (1ull<<32) + highmem_size;
> > +        e820_entries++;
> > +    }
> > +
> > +    e820 = malloc(sizeof(struct e820entry) * e820_entries);
> You can use libxl__malloc(gc, ...).
Good simplification.

> > +    if (!e820) {
> > +        return -1;
> > +    }
> No need to check if you use libxl__malloc.
Sure.

> > +
> > +    /* Low memory */
> > +    e820[nr].addr = 0x100000;
> Hardcoded value?
Yes. Actually, we intend to use this to present that lowmem entry,

tools/firmware/hvmloader/e820.c:

    /* Low RAM goes here. Reserve space for special pages. */
    ...
    e820[nr].addr = 0x100000;

> > +    e820[nr].size = args->lowmem_size - 0x100000;
> > +    e820[nr].type = E820_RAM;
> > +    nr++;
> > +
> > +    /* RDM mapping */
> > +    for (i = 0; i < d_config->num_rdms; i++) {
> > +        /*
> > +         * We should drop this kind of rdm entry.
> > +         */
> > +        if (d_config->rdms[i].flag == LIBXL_RDM_RESERVE_FLAG_INVALID)
> > +            continue;
> > +
> > +        e820[nr].addr = d_config->rdms[i].start;
> > +        e820[nr].size = d_config->rdms[i].size;
> > +        e820[nr].type = E820_RESERVED;
> > +        nr++;
> > +    }
> > +
> > +    /* High memory */
> > +    if (highmem_size) {
> > +        e820[nr].addr = ((uint64_t)1 << 32);
> > +        e820[nr].size = highmem_size;
> > +        e820[nr].type = E820_RAM;
> > +    }
> > +
> > +    if (xc_domain_set_memory_map(ctx->xch, domid, e820, e820_entries) != 0) {
> > +        free(e820);
> No need to free if you use libxl__malloc(gc, ...).
Sure.

> > +        return -1;
> > +    }
> > +
> > +    free(e820);
> Ditto.
Sure.

Thanks
Tiejun

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel