ia64/xen-unstable

changeset 14231:939d2b7d4a12

xen: Make dom0 domain builder behaviour match that of domU.
Signed-off-by: Keir Fraser <keir@xensource.com>
author kfraser@localhost.localdomain
date Mon Mar 05 10:52:54 2007 +0000 (2007-03-05)
parents aae662fdf53e
children a951cf1da459 e74bfc744717
files xen/arch/x86/domain_build.c xen/include/public/xen.h
line diff
     1.1 --- a/xen/arch/x86/domain_build.c	Mon Mar 05 10:37:01 2007 +0000
     1.2 +++ b/xen/arch/x86/domain_build.c	Mon Mar 05 10:52:54 2007 +0000
     1.3 @@ -374,9 +374,6 @@ int construct_dom0(struct domain *d,
     1.4      if ( parms.f_required[0] /* Huh? -- kraxel */ )
     1.5              panic("Domain 0 requires an unsupported hypervisor feature.\n");
     1.6  
     1.7 -    /* Align load address to 4MB boundary. */
     1.8 -    v_start = parms.virt_base & ~((1UL<<22)-1);
     1.9 -
    1.10      /*
    1.11       * Why do we need this? The number of page-table frames depends on the 
    1.12       * size of the bootstrap address space. But the size of the address space 
    1.13 @@ -384,6 +381,7 @@ int construct_dom0(struct domain *d,
    1.14       * read-only). We have a pair of simultaneous equations in two unknowns, 
    1.15       * which we solve by exhaustive search.
    1.16       */
    1.17 +    v_start          = parms.virt_base;
    1.18      vkern_start      = parms.virt_kstart;
    1.19      vkern_end        = parms.virt_kend;
    1.20      vinitrd_start    = round_pgup(vkern_end);
     2.1 --- a/xen/include/public/xen.h	Mon Mar 05 10:37:01 2007 +0000
     2.2 +++ b/xen/include/public/xen.h	Mon Mar 05 10:52:54 2007 +0000
     2.3 @@ -473,26 +473,24 @@ typedef struct shared_info shared_info_t
     2.4  #endif
     2.5  
     2.6  /*
     2.7 - * Start-of-day memory layout for the initial domain (DOM0):
     2.8 + * Start-of-day memory layout:
     2.9   *  1. The domain is started within contiguous virtual-memory region.
    2.10 - *  2. The contiguous region begins and ends on an aligned 4MB boundary.
    2.11 - *  3. The region start corresponds to the load address of the OS image.
    2.12 - *     If the load address is not 4MB aligned then the address is rounded down.
    2.13 - *  4. This the order of bootstrap elements in the initial virtual region:
    2.14 + *  2. The contiguous region ends on an aligned 4MB boundary.
    2.15 + *  3. This the order of bootstrap elements in the initial virtual region:
    2.16   *      a. relocated kernel image
    2.17   *      b. initial ram disk              [mod_start, mod_len]
    2.18   *      c. list of allocated page frames [mfn_list, nr_pages]
    2.19   *      d. start_info_t structure        [register ESI (x86)]
    2.20   *      e. bootstrap page tables         [pt_base, CR3 (x86)]
    2.21   *      f. bootstrap stack               [register ESP (x86)]
    2.22 - *  5. Bootstrap elements are packed together, but each is 4kB-aligned.
    2.23 - *  6. The initial ram disk may be omitted.
    2.24 - *  7. The list of page frames forms a contiguous 'pseudo-physical' memory
    2.25 + *  4. Bootstrap elements are packed together, but each is 4kB-aligned.
    2.26 + *  5. The initial ram disk may be omitted.
    2.27 + *  6. The list of page frames forms a contiguous 'pseudo-physical' memory
    2.28   *     layout for the domain. In particular, the bootstrap virtual-memory
    2.29   *     region is a 1:1 mapping to the first section of the pseudo-physical map.
    2.30 - *  8. All bootstrap elements are mapped read-writable for the guest OS. The
    2.31 + *  7. All bootstrap elements are mapped read-writable for the guest OS. The
    2.32   *     only exception is the bootstrap page table, which is mapped read-only.
    2.33 - *  9. There is guaranteed to be at least 512kB padding after the final
    2.34 + *  8. There is guaranteed to be at least 512kB padding after the final
    2.35   *     bootstrap element. If necessary, the bootstrap virtual region is
    2.36   *     extended by an extra 4MB to ensure this.
    2.37   */