xen: sync with xen headers
Use the newest headers from the xen tree to get some new structure layouts. Signed-off-by: Juergen Gross <jgross@suse.com> Reviewed-by: David Vrabel <david.vrabel@citrix.com> Acked-by: Konrad Rzeszutek Wilk <Konrad.wilk@oracle.com> Signed-off-by: David Vrabel <david.vrabel@citrix.com>
This commit is contained in:
@@ -585,26 +585,29 @@ struct shared_info {
|
||||
};
|
||||
|
||||
/*
|
||||
* Start-of-day memory layout for the initial domain (DOM0):
|
||||
* Start-of-day memory layout
|
||||
*
|
||||
* 1. The domain is started within contiguous virtual-memory region.
|
||||
* 2. The contiguous region begins and ends on an aligned 4MB boundary.
|
||||
* 3. The region start corresponds to the load address of the OS image.
|
||||
* If the load address is not 4MB aligned then the address is rounded down.
|
||||
* 4. This the order of bootstrap elements in the initial virtual region:
|
||||
* 3. This the order of bootstrap elements in the initial virtual region:
|
||||
* a. relocated kernel image
|
||||
* b. initial ram disk [mod_start, mod_len]
|
||||
* (may be omitted)
|
||||
* c. list of allocated page frames [mfn_list, nr_pages]
|
||||
* (unless relocated due to XEN_ELFNOTE_INIT_P2M)
|
||||
* d. start_info_t structure [register ESI (x86)]
|
||||
* e. bootstrap page tables [pt_base, CR3 (x86)]
|
||||
* f. bootstrap stack [register ESP (x86)]
|
||||
* 5. Bootstrap elements are packed together, but each is 4kB-aligned.
|
||||
* 6. The initial ram disk may be omitted.
|
||||
* 7. The list of page frames forms a contiguous 'pseudo-physical' memory
|
||||
* in case of dom0 this page contains the console info, too
|
||||
* e. unless dom0: xenstore ring page
|
||||
* f. unless dom0: console ring page
|
||||
* g. bootstrap page tables [pt_base, CR3 (x86)]
|
||||
* h. bootstrap stack [register ESP (x86)]
|
||||
* 4. Bootstrap elements are packed together, but each is 4kB-aligned.
|
||||
* 5. The list of page frames forms a contiguous 'pseudo-physical' memory
|
||||
* layout for the domain. In particular, the bootstrap virtual-memory
|
||||
* region is a 1:1 mapping to the first section of the pseudo-physical map.
|
||||
* 8. All bootstrap elements are mapped read-writable for the guest OS. The
|
||||
* 6. All bootstrap elements are mapped read-writable for the guest OS. The
|
||||
* only exception is the bootstrap page table, which is mapped read-only.
|
||||
* 9. There is guaranteed to be at least 512kB padding after the final
|
||||
* 7. There is guaranteed to be at least 512kB padding after the final
|
||||
* bootstrap element. If necessary, the bootstrap virtual region is
|
||||
* extended by an extra 4MB to ensure this.
|
||||
*/
|
||||
@@ -641,10 +644,12 @@ struct start_info {
|
||||
};
|
||||
|
||||
/* These flags are passed in the 'flags' field of start_info_t. */
|
||||
#define SIF_PRIVILEGED (1<<0) /* Is the domain privileged? */
|
||||
#define SIF_INITDOMAIN (1<<1) /* Is this the initial control domain? */
|
||||
#define SIF_MULTIBOOT_MOD (1<<2) /* Is mod_start a multiboot module? */
|
||||
#define SIF_MOD_START_PFN (1<<3) /* Is mod_start a PFN? */
|
||||
#define SIF_PRIVILEGED (1<<0) /* Is the domain privileged? */
|
||||
#define SIF_INITDOMAIN (1<<1) /* Is this the initial control domain? */
|
||||
#define SIF_MULTIBOOT_MOD (1<<2) /* Is mod_start a multiboot module? */
|
||||
#define SIF_MOD_START_PFN (1<<3) /* Is mod_start a PFN? */
|
||||
#define SIF_VIRT_P2M_4TOOLS (1<<4) /* Do Xen tools understand a virt. mapped */
|
||||
/* P->M making the 3 level tree obsolete? */
|
||||
#define SIF_PM_MASK (0xFF<<8) /* reserve 1 byte for xen-pm options */
|
||||
|
||||
/*
|
||||
|
Reference in New Issue
Block a user