Re: [PATCH RFC v1 09/13] elfnotes: intorduce a new PHYS_ENTRY elfnote

["Jan Beulich" <JBeulich@suse.com>]

>>> On 23.06.15 at 11:40, <roger.pau@citrix.com> wrote:
> El 23/06/15 a les 11.35, Jan Beulich ha escrit:
>>>>> On 22.06.15 at 18:11, <roger.pau@citrix.com> wrote:
>>> @@ -213,6 +214,9 @@ elf_errorstatus elf_xen_parse_note(struct elf_binary 
> *elf,
>>>                  elf, note, sizeof(*parms->f_supported), i);
>>>          break;
>>>  
>>> +    case XEN_ELFNOTE_PHYS_ENTRY:
>>> +        parms->phys_entry = val;
>> 
>> I don't think I've seen this field having got added in an earlier patch,
>> and it's also not getting added here.
> 
> Yes, it's added in patch 5, because it's also used by the HVM-generic
> loader.

So indeed missed it (being in an otherwise tools only patch). Sorry.

>>> --- a/xen/include/public/elfnote.h
>>> +++ b/xen/include/public/elfnote.h
>>> @@ -200,9 +200,18 @@
>>>  #define XEN_ELFNOTE_SUPPORTED_FEATURES 17
>>>  
>>>  /*
>>> + * Physical entry point into the kernel.
>>> + *
>>> + * 32bit entry point into the kernel. Xen will use this entry point
>>> + * in order to launch the guest kernel in 32bit protected mode
>>> + * with paging disabled.
>>> + */
>>> +#define XEN_ELFNOTE_PHYS_ENTRY 18
>> 
>> Perhaps XEN_ELFNOTE_PHYS_ENTRY32 or XEN_ELFNOTE_PHYS32_ENTRY
>> then?
> 
> That's fine, I don't mind changing it. Although AFAIK it's not possible
> to have a 64bit physical entry point (paging-disabled).

That depends on the perspective you take: Under UEFI the kernel
would be entered in pseudo-physical (1:1 mapped virtual) mode.
And that's certainly a model to at least keep in mind.

Jan