[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v2 2/5] xen: add generic flag to elf_dom_parms indicating support of unmapped initrd
On 02/10/15 10:44, Juergen Gross wrote: > On 10/02/2015 11:37 AM, Andrew Cooper wrote: >> On 02/10/15 06:49, Juergen Gross wrote: >>> Support of an unmapped initrd is indicated by the kernel of the domain >>> via elf notes. In order not to have to use raw elf data in the tools >>> for support of an unmapped initrd add a flag to the parsed data area >>> to indicate the kernel supporting this feature. >>> >>> Switch using this flag in the hypervisor domain builder. >>> >>> Cc: Keir Fraser <keir@xxxxxxx> >>> Cc: Jan Beulich <jbeulich@xxxxxxxx> >>> Cc: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> >>> Cc: Tim Deegan <tim@xxxxxxx> >>> Suggested-by: Ian Campbell <ian.campbell@xxxxxxxxxx> >>> Signed-off-by: Juergen Gross <jgross@xxxxxxxx> >>> --- >>> xen/arch/x86/domain_build.c | 4 ++-- >>> xen/common/libelf/libelf-dominfo.c | 3 +++ >>> xen/include/xen/libelf.h | 1 + >>> 3 files changed, 6 insertions(+), 2 deletions(-) >>> >>> diff --git a/xen/arch/x86/domain_build.c b/xen/arch/x86/domain_build.c >>> index c2ef87a..a02c9fb 100644 >>> --- a/xen/arch/x86/domain_build.c >>> +++ b/xen/arch/x86/domain_build.c >>> @@ -353,7 +353,7 @@ static unsigned long __init compute_dom0_nr_pages( >>> >>> vstart = parms->virt_base; >>> vend = round_pgup(parms->virt_kend); >>> - if ( !parms->elf_notes[XEN_ELFNOTE_MOD_START_PFN].data.num ) >>> + if ( !parms->mod_start_pfn ) >>> vend += round_pgup(initrd_len); >>> end = vend + nr_pages * sizeof_long; >>> >>> @@ -1037,7 +1037,7 @@ int __init construct_dom0( >>> v_start = parms.virt_base; >>> vkern_start = parms.virt_kstart; >>> vkern_end = parms.virt_kend; >>> - if ( parms.elf_notes[XEN_ELFNOTE_MOD_START_PFN].data.num ) >>> + if ( parms.mod_start_pfn ) >>> { >>> vinitrd_start = vinitrd_end = 0; >>> vphysmap_start = round_pgup(vkern_end); >>> diff --git a/xen/common/libelf/libelf-dominfo.c >>> b/xen/common/libelf/libelf-dominfo.c >>> index 3de1c23..31d8436 100644 >>> --- a/xen/common/libelf/libelf-dominfo.c >>> +++ b/xen/common/libelf/libelf-dominfo.c >>> @@ -190,6 +190,9 @@ elf_errorstatus elf_xen_parse_note(struct >>> elf_binary *elf, >>> case XEN_ELFNOTE_INIT_P2M: >>> parms->p2m_base = val; >>> break; >>> + case XEN_ELFNOTE_MOD_START_PFN: >>> + parms->mod_start_pfn = !!val; >>> + break; >>> case XEN_ELFNOTE_PADDR_OFFSET: >>> parms->elf_paddr_offset = val; >>> break; >>> diff --git a/xen/include/xen/libelf.h b/xen/include/xen/libelf.h >>> index d7045f6..07b96a3 100644 >>> --- a/xen/include/xen/libelf.h >>> +++ b/xen/include/xen/libelf.h >>> @@ -423,6 +423,7 @@ struct elf_dom_parms { >>> char loader[16]; >>> enum xen_pae_type pae; >>> bool bsd_symtab; >>> + bool mod_start_pfn; >> >> The _pfn suffix here is confusing given the type of bool. >> >> Perhaps "has_initrd" is a better choice of name? The rest of the patch >> looks fine. > > Hmm, I just followed the naming of the note index in the raw data: > XEN_ELFNOTE_MOD_START_PFN. "has_initrd" would be completely misleading: > the flag doesn't indicate the support of an initrd, but the support of > an initrd (or more general: module as understood by grub) not covered by > the initial kernel mapping and due to this specified by it's starting > pfn instead it's virtual address. It would appear that a lot of the naming around there is confusing. Would "unmapped_initrd" be a better name then? If not, I am not too fussed, seeing as it matches the (questionably named) ELF note. ~Andrew _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |