Re: [Xen-devel] [PATCH 3/5] libxc: create unmapped initrd in domain builder if supported

[Juergen Gross <jgross@xxxxxxxx>]

On 09/11/2015 02:54 PM, Ian Jackson wrote:
> Juergen Gross writes ("[PATCH 3/5] libxc: create unmapped initrd in domain builder 
> if supported"):
> > In case the kernel of a new pv-domU indicates it is supporting an
> > unmapped initrd, don't waste precious virtual space for the initrd,
> > but allocate only guest physical memory for it.
> ...
>
> The name of this ELFNOTE suggests that it applies to all multiboot
> modules, not just ramdisks.  In particular, that means perhaps it
> ought to apply to device tree blobs too ?
Hmm, in theory, yes.

AFAIK it is only used for initrd on x86. I think support for other
modules can be added as needed.

> > -    /* load ramdisk */
> > -    if ( dom->ramdisk_blob )
> > +    /* Load ramdisk if initial mapping required. */
> > +    if ( dom->ramdisk_blob &&
> > +         (!dom->parms.elf_notes[XEN_ELFNOTE_MOD_START_PFN].data.num ||
> > +          dom->ramdisk_seg.vstart) )
> After this patch the resulting structure of the code is rather
> unfortunate, in that the order of the main processing steps depends on
> this ELFNOTE.
>
> Wouldn't it be better to generalise xc_dom_alloc_segment ?
How?

You have to create (and allocate space for) the page tables after
all allocations which should be covered by those page tables. And
you must not allocate the other stuff before that, as this would
again waste virtual address space, which is 1:1 with guest physical
memory.

The only solution would be to calculate the needed sizes of the
single memory chunks first and then do the allocations either in
the mapped or the unmapped region according to the ELFNOTEs. This
would rip at least the initrd processing into two parts, as the
needed memory size is calculated depending on the initrd being
compressed or not.

I thought about building a table containing the sequence of the
single processing steps dependant on the ELFNOTEs and processing this
table in a generic loop afterwards. If you like this approach, I can
give it a try. I just wanted to avoid a complete rework of the main
building function.


Juergen

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