[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 03:15 PM, Julien Grall wrote:
On 11/09/15 13:54, 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 ?

The device tree blobs is not a multiboot module but directly pass in a
register to the kernel.

FWIW, we don't have any ELF support right now on ARM.

Okay, I thought so, but I wasn't sure.


-    /* 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.

Shouldn't we ought to have a common code ELF agnostic? I.e we may have
other kernel image format where we have notes but not ELF notes.

dom->parms is the same for all architectures. I think it would have to
be extended in that case.


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®.