brintos

brintos / linux-shallow public Read only

0
0
Text · 8.2 KiB · 918f47d Raw
277 lines · c
1/* SPDX-License-Identifier: MIT */2/******************************************************************************3 * elfnote.h4 *5 * Definitions used for the Xen ELF notes.6 *7 * Copyright (c) 2006, Ian Campbell, XenSource Ltd.8 */9 10#ifndef __XEN_PUBLIC_ELFNOTE_H__11#define __XEN_PUBLIC_ELFNOTE_H__12 13/*14 * `incontents 200 elfnotes ELF notes15 *16 * The notes should live in a PT_NOTE segment and have "Xen" in the17 * name field.18 *19 * Numeric types are either 4 or 8 bytes depending on the content of20 * the desc field.21 *22 * LEGACY indicated the fields in the legacy __xen_guest string which23 * this a note type replaces.24 *25 * String values (for non-legacy) are NULL terminated ASCII, also known26 * as ASCIZ type.27 *28 * Xen only uses ELF Notes contained in x86 binaries.29 */30 31/*32 * NAME=VALUE pair (string).33 */34#define XEN_ELFNOTE_INFO           035 36/*37 * The virtual address of the entry point (numeric).38 *39 * LEGACY: VIRT_ENTRY40 */41#define XEN_ELFNOTE_ENTRY          142 43/* The virtual address of the hypercall transfer page (numeric).44 *45 * LEGACY: HYPERCALL_PAGE. (n.b. legacy value is a physical page46 * number not a virtual address)47 */48#define XEN_ELFNOTE_HYPERCALL_PAGE 249 50/* The virtual address where the kernel image should be mapped (numeric).51 *52 * Defaults to 0.53 *54 * LEGACY: VIRT_BASE55 */56#define XEN_ELFNOTE_VIRT_BASE      357 58/*59 * The offset of the ELF paddr field from the actual required60 * pseudo-physical address (numeric).61 *62 * This is used to maintain backwards compatibility with older kernels63 * which wrote __PAGE_OFFSET into that field. This field defaults to 064 * if not present.65 *66 * LEGACY: ELF_PADDR_OFFSET. (n.b. legacy default is VIRT_BASE)67 */68#define XEN_ELFNOTE_PADDR_OFFSET   469 70/*71 * The version of Xen that we work with (string).72 *73 * LEGACY: XEN_VER74 */75#define XEN_ELFNOTE_XEN_VERSION    576 77/*78 * The name of the guest operating system (string).79 *80 * LEGACY: GUEST_OS81 */82#define XEN_ELFNOTE_GUEST_OS       683 84/*85 * The version of the guest operating system (string).86 *87 * LEGACY: GUEST_VER88 */89#define XEN_ELFNOTE_GUEST_VERSION  790 91/*92 * The loader type (string).93 *94 * LEGACY: LOADER95 */96#define XEN_ELFNOTE_LOADER         897 98/*99 * The kernel supports PAE (x86/32 only, string = "yes", "no" or100 * "bimodal").101 *102 * For compatibility with Xen 3.0.3 and earlier the "bimodal" setting103 * may be given as "yes,bimodal" which will cause older Xen to treat104 * this kernel as PAE.105 *106 * LEGACY: PAE (n.b. The legacy interface included a provision to107 * indicate 'extended-cr3' support allowing L3 page tables to be108 * placed above 4G. It is assumed that any kernel new enough to use109 * these ELF notes will include this and therefore "yes" here is110 * equivalent to "yes[entended-cr3]" in the __xen_guest interface.111 */112#define XEN_ELFNOTE_PAE_MODE       9113 114/*115 * The features supported/required by this kernel (string).116 *117 * The string must consist of a list of feature names (as given in118 * features.h, without the "XENFEAT_" prefix) separated by '|'119 * characters. If a feature is required for the kernel to function120 * then the feature name must be preceded by a '!' character.121 *122 * LEGACY: FEATURES123 */124#define XEN_ELFNOTE_FEATURES      10125 126/*127 * The kernel requires the symbol table to be loaded (string = "yes" or "no")128 * LEGACY: BSD_SYMTAB (n.b. The legacy treated the presence or absence129 * of this string as a boolean flag rather than requiring "yes" or130 * "no".131 */132#define XEN_ELFNOTE_BSD_SYMTAB    11133 134/*135 * The lowest address the hypervisor hole can begin at (numeric).136 *137 * This must not be set higher than HYPERVISOR_VIRT_START. Its presence138 * also indicates to the hypervisor that the kernel can deal with the139 * hole starting at a higher address.140 */141#define XEN_ELFNOTE_HV_START_LOW  12142 143/*144 * List of maddr_t-sized mask/value pairs describing how to recognize145 * (non-present) L1 page table entries carrying valid MFNs (numeric).146 */147#define XEN_ELFNOTE_L1_MFN_VALID  13148 149/*150 * Whether or not the guest supports cooperative suspend cancellation.151 * This is a numeric value.152 *153 * Default is 0154 */155#define XEN_ELFNOTE_SUSPEND_CANCEL 14156 157/*158 * The (non-default) location the initial phys-to-machine map should be159 * placed at by the hypervisor (Dom0) or the tools (DomU).160 * The kernel must be prepared for this mapping to be established using161 * large pages, despite such otherwise not being available to guests. Note162 * that these large pages may be misaligned in PFN space (they'll obviously163 * be aligned in MFN and virtual address spaces).164 * The kernel must also be able to handle the page table pages used for165 * this mapping not being accessible through the initial mapping.166 * (Only x86-64 supports this at present.)167 */168#define XEN_ELFNOTE_INIT_P2M      15169 170/*171 * Whether or not the guest can deal with being passed an initrd not172 * mapped through its initial page tables.173 */174#define XEN_ELFNOTE_MOD_START_PFN 16175 176/*177 * The features supported by this kernel (numeric).178 *179 * Other than XEN_ELFNOTE_FEATURES on pre-4.2 Xen, this note allows a180 * kernel to specify support for features that older hypervisors don't181 * know about. The set of features 4.2 and newer hypervisors will182 * consider supported by the kernel is the combination of the sets183 * specified through this and the string note.184 *185 * LEGACY: FEATURES186 */187#define XEN_ELFNOTE_SUPPORTED_FEATURES 17188 189/*190 * Physical entry point into the kernel.191 *192 * 32bit entry point into the kernel. When requested to launch the193 * guest kernel in a HVM container, Xen will use this entry point to194 * launch the guest in 32bit protected mode with paging disabled.195 * Ignored otherwise.196 */197#define XEN_ELFNOTE_PHYS32_ENTRY 18198 199/*200 * Physical loading constraints for PVH kernels201 *202 * The presence of this note indicates the kernel supports relocating itself.203 *204 * The note may include up to three 32bit values to place constraints on the205 * guest physical loading addresses and alignment for a PVH kernel.  Values206 * are read in the following order:207 *  - a required start alignment (default 0x200000)208 *  - a minimum address for the start of the image (default 0; see below)209 *  - a maximum address for the last byte of the image (default 0xffffffff)210 *211 * When this note specifies an alignment value, it is used.  Otherwise the212 * maximum p_align value from loadable ELF Program Headers is used, if it is213 * greater than or equal to 4k (0x1000).  Otherwise, the default is used.214 */215#define XEN_ELFNOTE_PHYS32_RELOC 19216 217/*218 * The number of the highest elfnote defined.219 */220#define XEN_ELFNOTE_MAX XEN_ELFNOTE_PHYS32_RELOC221 222/*223 * System information exported through crash notes.224 *225 * The kexec / kdump code will create one XEN_ELFNOTE_CRASH_INFO226 * note in case of a system crash. This note will contain various227 * information about the system, see xen/include/xen/elfcore.h.228 */229#define XEN_ELFNOTE_CRASH_INFO 0x1000001230 231/*232 * System registers exported through crash notes.233 *234 * The kexec / kdump code will create one XEN_ELFNOTE_CRASH_REGS235 * note per cpu in case of a system crash. This note is architecture236 * specific and will contain registers not saved in the "CORE" note.237 * See xen/include/xen/elfcore.h for more information.238 */239#define XEN_ELFNOTE_CRASH_REGS 0x1000002240 241 242/*243 * xen dump-core none note.244 * xm dump-core code will create one XEN_ELFNOTE_DUMPCORE_NONE245 * in its dump file to indicate that the file is xen dump-core246 * file. This note doesn't have any other information.247 * See tools/libxc/xc_core.h for more information.248 */249#define XEN_ELFNOTE_DUMPCORE_NONE               0x2000000250 251/*252 * xen dump-core header note.253 * xm dump-core code will create one XEN_ELFNOTE_DUMPCORE_HEADER254 * in its dump file.255 * See tools/libxc/xc_core.h for more information.256 */257#define XEN_ELFNOTE_DUMPCORE_HEADER             0x2000001258 259/*260 * xen dump-core xen version note.261 * xm dump-core code will create one XEN_ELFNOTE_DUMPCORE_XEN_VERSION262 * in its dump file. It contains the xen version obtained via the263 * XENVER hypercall.264 * See tools/libxc/xc_core.h for more information.265 */266#define XEN_ELFNOTE_DUMPCORE_XEN_VERSION        0x2000002267 268/*269 * xen dump-core format version note.270 * xm dump-core code will create one XEN_ELFNOTE_DUMPCORE_FORMAT_VERSION271 * in its dump file. It contains a format version identifier.272 * See tools/libxc/xc_core.h for more information.273 */274#define XEN_ELFNOTE_DUMPCORE_FORMAT_VERSION     0x2000003275 276#endif /* __XEN_PUBLIC_ELFNOTE_H__ */277