[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.