[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


 


Rackspace

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