[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH RFC v1 09/13] elfnotes: intorduce a new PHYS_ENTRY elfnote
>>> On 23.06.15 at 11:40, <roger.pau@xxxxxxxxxx> wrote: > El 23/06/15 a les 11.35, Jan Beulich ha escrit: >>>>> On 22.06.15 at 18:11, <roger.pau@xxxxxxxxxx> 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 _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |