[PATCH] domain builder for ReactOS

[PATCH] domain builder for ReactOS

[Ge van Geldorp]

As announced earlier (http://lists.xensource.com/archives/html/xen-devel/2005-03/msg01160.html)
I'm working on porting ReactOS to Xen. The first stage, getting our bootloader
running, is complete now. Progress report and a screenshot on
http://reactos.com/wiki/index.php/Xen_port

To start ReactOS in a Xen domain, a ReactOS domain builder is needed. Patches
to implement that are included below. I'm not sure about the Signed-Off-By
stuff, is just including the line below enough or is some paperwork required?

Ge van Geldorp.

Signed-Off-By: Ge van Geldorp <gvg@reactos.com>

--- orig/tools/libxc/xc.h	2005-06-02 23:26:10.000000000 +0200
+++ reactos/tools/libxc/xc.h	2005-06-02 23:23:10.000000000 +0200
@@ -273,6 +273,15 @@
                  unsigned int control_evtchn,
                  unsigned long flags);
 
+int xc_reactos_build(int xc_handle,
+                     u32 domid,
+                     const char *image_name,
+                     const char *module_name,
+                     const char *cmdline,
+                     unsigned int control_evtchn,
+                     unsigned long flags,
+                     unsigned int vcpus);
+
 int xc_bvtsched_global_set(int xc_handle,
                            unsigned long ctx_allow);
 
--- orig/tools/python/xen/lowlevel/xc/xc.c	2005-06-02 23:26:10.000000000 +0200
+++ reactos/tools/python/xen/lowlevel/xc/xc.c	2005-06-02 23:23:07.000000000 +0200
@@ -391,6 +391,33 @@
     return zero;
 }
 
+static PyObject *pyxc_reactos_build(PyObject *self,
+                                    PyObject *args,
+                                    PyObject *kwds)
+{
+    XcObject *xc = (XcObject *)self;
+
+    u32   dom;
+    char *image, *module = NULL, *cmdline = "";
+    int   control_evtchn, flags = 0, vcpus = 1;
+
+    static char *kwd_list[] = { "dom", "control_evtchn", 
+                                "image", "ramdisk", "cmdline", "flags", "vcpus",
+                                NULL };
+
+    if ( !PyArg_ParseTupleAndKeywords(args, kwds, "iis|ssii", kwd_list, 
+                                      &dom, &control_evtchn, 
+                                      &image, &module, &cmdline, &flags, &vcpus) )
+        return NULL;
+
+    if ( xc_reactos_build(xc->xc_handle, dom, image,
+                          module, cmdline, control_evtchn, flags, vcpus) != 0 )
+        return PyErr_SetFromErrno(xc_error);
+    
+    Py_INCREF(zero);
+    return zero;
+}
+
 static PyObject *pyxc_bvtsched_global_set(PyObject *self,
                                           PyObject *args,
                                           PyObject *kwds)
@@ -942,6 +969,17 @@
       " cmdline [str, n/a]: Kernel parameters, if any.\n\n"
       "Returns: [int] 0 on success; -1 on error.\n" },
 
+    { "reactos_build", 
+      (PyCFunction)pyxc_reactos_build, 
+      METH_VARARGS | METH_KEYWORDS, "\n"
+      "Build a new ReactOS guest OS.\n"
+      " dom     [int]:      Identifier of domain to build into.\n"
+      " image   [str]:      Name of kernel image file. May be gzipped.\n"
+      " ramdisk [str, n/a]: Name of ramdisk file, if any.\n"
+      " cmdline [str, n/a]: Kernel parameters, if any.\n\n"
+      " vcpus   [int, 1]:   Number of Virtual CPUS in domain.\n\n"
+      "Returns: [int] 0 on success; -1 on error.\n" },
+
     { "bvtsched_global_set",
       (PyCFunction)pyxc_bvtsched_global_set,
       METH_VARARGS | METH_KEYWORDS, "\n"
--- orig/tools/python/xen/xend/XendDomainInfo.py	2005-06-02 23:26:10.000000000 +0200
+++ reactos/tools/python/xen/xend/XendDomainInfo.py	2005-06-02 23:23:01.000000000 +0200
@@ -1167,6 +1167,24 @@
     vm.create_domain("vmx", kernel, ramdisk, cmdline, memmap)
     return vm
 
+def vm_image_reactos(vm, image):
+    """Create a VM for a ReactOS image.
+
+    @param name:      vm name
+    @param memory:    vm memory
+    @param image:     image config
+    @return: vm
+    """
+    kernel = sxp.child_value(image, "kernel")
+    cmdline = ""
+    args = sxp.child_value(image, "args")
+    if args:
+        cmdline += " " + args
+    ramdisk = sxp.child_value(image, "ramdisk", '')
+    log.debug("creating reactos domain with cmdline: %s" %(cmdline,))
+    vm.create_domain("reactos", kernel, ramdisk, cmdline)
+    return vm
+
 def vm_field_ignore(vm, config, val, index):
     """Dummy config field handler used for fields with built-in handling.
 
@@ -1196,9 +1214,10 @@
 
 #============================================================================
 # Register image handlers.
-add_image_handler('linux', vm_image_linux)
-add_image_handler('plan9', vm_image_plan9)
-add_image_handler('vmx',   vm_image_vmx)
+add_image_handler('linux',   vm_image_linux)
+add_image_handler('plan9',   vm_image_plan9)
+add_image_handler('vmx',     vm_image_vmx)
+add_image_handler('reactos', vm_image_reactos)
 
 # Ignore the fields we already handle.
 add_config_handler('name',       vm_field_ignore)
--- orig/tools/libxc/Makefile	2005-05-25 00:20:35 +02:00
+++ reactos/tools/libxc/Makefile	2005-06-01 11:51:19 +02:00
@@ -28,6 +28,7 @@
 SRCS     += xc_private.c
 SRCS     += xc_ptrace.c
 SRCS     += xc_ptrace_core.c
+SRCS     += xc_reactos_build.c
 SRCS     += xc_vmx_build.c
 
 CFLAGS   += -Wall
--- /dev/null	2005-06-02 12:46:09.470000000 +0200
+++ reactos/tools/libxc/xc_reactos_build.c	2005-06-02 23:23:10.000000000 +0200
@@ -0,0 +1,652 @@
+/******************************************************************************
+ * xc_reactos_build.c
+ *
+ * Based on xc_linux_build.c
+ *
+ * An executable to be loaded by the reactos domain builder is a simple binary
+ * image. It's like a .COM file in MS-DOS. No headers are present.
+ * The only requirement is that it must have a xen_reactos table somewhere in
+ * the first 8192 bytes, starting on a 32-bit aligned address. Those familiar
+ * with the multiboot specification should recognize this, it's (almost) the
+ * same as the multiboot header.
+ * The layout of the xen_reactos table is:
+ *
+ * Offset Type Name          Note
+ * 0      u32  magic         required
+ * 4      u32  flags         required
+ * 8      u32  checksum      required
+ * 12     u32  header_addr   required
+ * 16     u32  load_addr     required
+ * 20     u32  load_end_addr required
+ * 24     u32  bss_end_addr  required
+ * 28     u32  entry_addr    required
+ *
+ * - magic
+ *   Magic number identifying the table. For images to be loaded by Xen 3, the
+ *   magic value is 0x336ec578 ("xEn3" with the 0x80 bit of the "E" set).
+ * - flags
+ *   bit 0: indicates whether the image needs to be loaded on a page boundary
+ *   bit 1: reserved, must be 0 (the multiboot spec uses this bit to indicate
+ *          that memory info should be passed to the image)
+ *   bit 2: reserved, must be 0 (the multiboot spec uses this bit to indicate
+ *          that the bootloader should pass video mode info to the image)
+ *   bit 16: reserved, must be 1 (the multiboot spec uses this bit to indicate
+ *           that the values in the fields header_addr - entry_addr are
+ *           valid)
+ *   All other bits should be set to 0.
+ * - checksum
+ *   When added to "magic" and "flags", the resulting value should be 0.
+ * - header_addr
+ *   Contains the virtual address corresponding to the beginning of the
+ *   table - the memory location at which the magic value is supposed to be
+ *   loaded. This field serves to synchronize the mapping between OS image
+ *   offsets and virtual memory addresses.
+ * - load_addr
+ *   Contains the virtual address of the beginning of the text segment. The
+ *   offset in the OS image file at which to start loading is defined by the
+ *   offset at which the table was found, minus (header addr - load addr).
+ *   load addr must be less than or equal to header addr.
+ * - load_end_addr
+ *   Contains the virtual address of the end of the data segment.
+ *   (load_end_addr - load_addr) specifies how much data to load. This implies
+ *   that the text and data segments must be consecutive in the OS image. If
+ *   this field is zero, the domain builder assumes that the text and data
+ *   segments occupy the whole OS image file.
+ * - bss_end_addr
+ *   Contains the virtual address of the end of the bss segment. The domain
+ *   builder initializes this area to zero, and reserves the memory it occupies
+ *   to avoid placing boot modules and other data relevant to the loaded image
+ *   in that area. If this field is zero, the domain builder assumes that no bss
+ *   segment is present.
+ * - entry_addr
+ *   The virtual address at which to start execution of the loaded image.
+ *
+ * Some of the field descriptions were copied from "The Multiboot
+ * Specification", Copyright 1995, 96 Bryan Ford <baford@cs.utah.edu>,
+ * Erich Stefan Boleyn <erich@uruk.org> Copyright 1999, 2000, 2001, 2002
+ * Free Software Foundation, Inc.
+ */
+
+#include "xc_private.h"
+#include <stdlib.h>
+
+#define L1_PROT (_PAGE_PRESENT|_PAGE_RW|_PAGE_ACCESSED)
+#define L2_PROT (_PAGE_PRESENT|_PAGE_RW|_PAGE_ACCESSED|_PAGE_DIRTY|_PAGE_USER)
+
+#define round_pgup(_p)    (((_p)+(PAGE_SIZE-1))&PAGE_MASK)
+#define round_pgdown(_p)  ((_p)&PAGE_MASK)
+
+struct xen_reactos_table
+{
+    unsigned long magic;
+    unsigned long flags;
+    unsigned long checksum;
+    unsigned long header_addr;
+    unsigned long load_addr;
+    unsigned long load_end_addr;
+    unsigned long bss_end_addr;
+    unsigned long entry_addr;
+};
+
+#define XEN_REACTOS_MAGIC3 0x336ec578
+
+#define XEN_REACTOS_FLAG_ALIGN4K     0x00000001
+#define XEN_REACTOS_FLAG_NEEDMEMINFO 0x00000002
+#define XEN_REACTOS_FLAG_NEEDVIDINFO 0x00000004
+#define XEN_REACTOS_FLAG_ADDRSVALID  0x00010000
+
+/* Flags we test for */
+#define FLAGS_MASK     ((~ 0) & (~ XEN_REACTOS_FLAG_ALIGN4K))
+#define FLAGS_REQUIRED XEN_REACTOS_FLAG_ADDRSVALID
+
+static int
+parsereactosimage(
+    char *base, unsigned long size, struct xen_reactos_table **table);
+static int
+loadreactosimage(
+    char *image_base, unsigned long image_size, int xch, u32 dom,
+    unsigned long *parray, struct xen_reactos_table *image_info);
+
+static int setup_guest(int xc_handle,
+                         u32 dom,
+                         char *image, unsigned long image_size,
+                         int module_fd, unsigned long module_len,
+                         unsigned long nr_pages,
+                         unsigned long *pvsi, unsigned long *pvke,
+                         vcpu_guest_context_t *ctxt,
+                         const char *cmdline,
+                         unsigned long shared_info_frame,
+                         unsigned int control_evtchn,
+                         unsigned long flags,
+                         unsigned int vcpus)
+{
+    l1_pgentry_t *vl1tab=NULL, *vl1e=NULL;
+    l2_pgentry_t *vl2tab=NULL, *vl2e=NULL;
+    unsigned long *page_array = NULL;
+    unsigned long l2tab;
+    unsigned long l1tab;
+    unsigned long count, i;
+    start_info_t *start_info;
+    shared_info_t *shared_info;
+    mmu_t *mmu = NULL;
+    int rc;
+
+    unsigned long nr_pt_pages;
+    unsigned long ppt_alloc;
+    unsigned long *physmap, *physmap_e, physmap_pfn;
+
+    struct xen_reactos_table *image_info;
+    unsigned long vimage_end;
+    unsigned long vmodule_start;
+    unsigned long vmodule_end;
+    unsigned long vphysmap_start;
+    unsigned long vphysmap_end;
+    unsigned long vstartinfo_start;
+    unsigned long vstartinfo_end;
+    unsigned long vstack_start;
+    unsigned long vstack_end;
+    unsigned long vpt_start;
+    unsigned long vpt_end;
+    unsigned long v_end;
+
+    rc = parsereactosimage(image, image_size, &image_info);
+    if ( rc != 0 )
+        goto error_out;
+
+    if ( (image_info->load_addr & (PAGE_SIZE-1)) != 0 )
+    {
+        PERROR("Guest OS must load to a page boundary.\n");
+        goto error_out;
+    }
+
+    /*
+     * Why do we need this? The number of page-table frames depends on the 
+     * size of the bootstrap address space. But the size of the address space 
+     * depends on the number of page-table frames (since each one is mapped 
+     * read-only). We have a pair of simultaneous equations in two unknowns, 
+     * which we solve by exhaustive search.
+     */
+    if ( 0 != image_info->bss_end_addr )
+    {
+        vimage_end = image_info->bss_end_addr;
+    }
+    else if ( 0 != image_info->load_end_addr )
+    {
+        vimage_end = image_info->load_end_addr;
+    }
+    else 
+    {
+        vimage_end = image_info->load_addr + image_size;
+    }
+    vmodule_start    = round_pgup(vimage_end);
+    vmodule_end      = vmodule_start + module_len;
+    vphysmap_start   = round_pgup(vmodule_end);
+    vphysmap_end     = vphysmap_start + (nr_pages * sizeof(unsigned long));
+    vpt_start        = round_pgup(vphysmap_end);
+    for ( nr_pt_pages = 2; ; nr_pt_pages++ )
+    {
+        vpt_end          = vpt_start + (nr_pt_pages * PAGE_SIZE);
+        vstartinfo_start = vpt_end;
+        vstartinfo_end   = vstartinfo_start + PAGE_SIZE;
+        vstack_start     = vstartinfo_end;
+        vstack_end       = vstack_start + PAGE_SIZE;
+        v_end            = (vstack_end + (1<<22)-1) & ~((1<<22)-1);
+        if ( (v_end - vstack_end) < (512 << 10) )
+            v_end += 1 << 22; /* Add extra 4MB to get >= 512kB padding. */
+        if ( (((v_end - image_info->load_addr + ((1<<L2_PAGETABLE_SHIFT)-1)) >> 
+               L2_PAGETABLE_SHIFT) + 1) <= nr_pt_pages )
+            break;
+    }
+
+    printf("VIRTUAL MEMORY ARRANGEMENT:\n"
+           " Loaded image:  %08lx->%08lx\n"
+           " Module:        %08lx->%08lx\n"
+           " Phys-Mach map: %08lx->%08lx\n"
+           " Page tables:   %08lx->%08lx\n"
+           " Start info:    %08lx->%08lx\n"
+           " Boot stack:    %08lx->%08lx\n"
+           " TOTAL:         %08lx->%08lx\n",
+           image_info->load_addr, vimage_end, 
+           vmodule_start, vmodule_end,
+           vphysmap_start, vphysmap_end,
+           vpt_start, vpt_end,
+           vstartinfo_start, vstartinfo_end,
+           vstack_start, vstack_end,
+           image_info->load_addr, v_end);
+    printf(" ENTRY ADDRESS: %08lx\n", image_info->entry_addr);
+
+    if ( (v_end - image_info->load_addr) > (nr_pages * PAGE_SIZE) )
+    {
+        printf("Initial guest OS requires too much space\n"
+               "(%luMB is greater than %luMB limit)\n",
+               (v_end-image_info->load_addr)>>20, (nr_pages<<PAGE_SHIFT)>>20);
+        goto error_out;
+    }
+
+    if ( (page_array = malloc(nr_pages * sizeof(unsigned long))) == NULL )
+    {
+        PERROR("Could not allocate memory");
+        goto error_out;
+    }
+
+    if ( xc_get_pfn_list(xc_handle, dom, page_array, nr_pages) != nr_pages )
+    {
+        PERROR("Could not get the page frame list");
+        goto error_out;
+    }
+
+    loadreactosimage(image, image_size, xc_handle, dom, page_array, image_info);
+
+    /* Load the initial ramdisk image. */
+    if ( module_len != 0 )
+    {
+        for ( i = (vmodule_start - image_info->load_addr); 
+              i < (vmodule_end - image_info->load_addr); i += PAGE_SIZE )
+        {
+            char page[PAGE_SIZE];
+            if ( read(module_fd, page, PAGE_SIZE) == -1 )
+            {
+                PERROR("Error reading module image, could not");
+                goto error_out;
+            }
+            xc_copy_to_domain_page(xc_handle, dom,
+                                page_array[i>>PAGE_SHIFT], page);
+        }
+    }
+
+    if ( (mmu = init_mmu_updates(xc_handle, dom)) == NULL )
+        goto error_out;
+
+    /* First allocate page for page dir. */
+    ppt_alloc = (vpt_start - image_info->load_addr) >> PAGE_SHIFT;
+    l2tab = page_array[ppt_alloc++] << PAGE_SHIFT;
+    ctxt->pt_base = l2tab;
+
+    /* Initialise the page tables. */
+    if ( (vl2tab = xc_map_foreign_range(xc_handle, dom, PAGE_SIZE, 
+                                        PROT_READ|PROT_WRITE, 
+                                        l2tab >> PAGE_SHIFT)) == NULL )
+        goto error_out;
+    memset(vl2tab, 0, PAGE_SIZE);
+    vl2e = &vl2tab[l2_table_offset(image_info->load_addr)];
+    for ( count = 0; count < ((v_end-image_info->load_addr)>>PAGE_SHIFT); count++ )
+    {    
+        if ( ((unsigned long)vl1e & (PAGE_SIZE-1)) == 0 )
+        {
+            l1tab = page_array[ppt_alloc++] << PAGE_SHIFT;
+            if ( vl1tab != NULL )
+                munmap(vl1tab, PAGE_SIZE);
+            if ( (vl1tab = xc_map_foreign_range(xc_handle, dom, PAGE_SIZE,
+                                                PROT_READ|PROT_WRITE,
+                                                l1tab >> PAGE_SHIFT)) == NULL )
+            {
+                munmap(vl2tab, PAGE_SIZE);
+                goto error_out;
+            }
+            memset(vl1tab, 0, PAGE_SIZE);
+            vl1e = &vl1tab[l1_table_offset(image_info->load_addr + (count<<PAGE_SHIFT))];
+            *vl2e++ = l1tab | L2_PROT;
+        }
+
+        *vl1e = (page_array[count] << PAGE_SHIFT) | L1_PROT;
+        if ( (count >= ((vpt_start-image_info->load_addr)>>PAGE_SHIFT)) && 
+             (count <  ((vpt_end  -image_info->load_addr)>>PAGE_SHIFT)) )
+            *vl1e &= ~_PAGE_RW;
+        vl1e++;
+    }
+    munmap(vl1tab, PAGE_SIZE);
+    munmap(vl2tab, PAGE_SIZE);
+
+    /* Write the phys->machine and machine->phys table entries. */
+    physmap_pfn = (vphysmap_start - image_info->load_addr) >> PAGE_SHIFT;
+    physmap = physmap_e = xc_map_foreign_range(
+        xc_handle, dom, PAGE_SIZE, PROT_READ|PROT_WRITE,
+        page_array[physmap_pfn++]);
+    for ( count = 0; count < nr_pages; count++ )
+    {
+        if ( add_mmu_update(xc_handle, mmu,
+                            (page_array[count] << PAGE_SHIFT) | 
+                            MMU_MACHPHYS_UPDATE, count) )
+        {
+            munmap(physmap, PAGE_SIZE);
+            goto error_out;
+        }
+        *physmap_e++ = page_array[count];
+        if ( ((unsigned long)physmap_e & (PAGE_SIZE-1)) == 0 )
+        {
+            munmap(physmap, PAGE_SIZE);
+            physmap = physmap_e = xc_map_foreign_range(
+                xc_handle, dom, PAGE_SIZE, PROT_READ|PROT_WRITE,
+                page_array[physmap_pfn++]);
+        }
+    }
+    munmap(physmap, PAGE_SIZE);
+    
+    /*
+     * Pin down l2tab addr as page dir page - causes hypervisor to provide
+     * correct protection for the page
+     */ 
+    if ( pin_table(xc_handle, MMUEXT_PIN_L2_TABLE, l2tab>>PAGE_SHIFT, dom) )
+        goto error_out;
+
+    start_info = xc_map_foreign_range(
+        xc_handle, dom, PAGE_SIZE, PROT_READ|PROT_WRITE,
+        page_array[(vstartinfo_start-image_info->load_addr)>>PAGE_SHIFT]);
+    memset(start_info, 0, sizeof(*start_info));
+    start_info->nr_pages     = nr_pages;
+    start_info->shared_info  = shared_info_frame << PAGE_SHIFT;
+    start_info->flags        = flags;
+    start_info->pt_base      = vpt_start;
+    start_info->nr_pt_frames = nr_pt_pages;
+    start_info->mfn_list     = vphysmap_start;
+    start_info->domain_controller_evtchn = control_evtchn;
+    if ( module_len != 0 )
+    {
+        start_info->mod_start    = vmodule_start;
+        start_info->mod_len      = module_len;
+    }
+    strncpy((char *)start_info->cmd_line, cmdline, MAX_CMDLINE);
+    start_info->cmd_line[MAX_CMDLINE-1] = '\0';
+    munmap(start_info, PAGE_SIZE);
+
+    /* shared_info page starts its life empty. */
+    shared_info = xc_map_foreign_range(
+        xc_handle, dom, PAGE_SIZE, PROT_READ|PROT_WRITE, shared_info_frame);
+    memset(shared_info, 0, sizeof(shared_info_t));
+    /* Mask all upcalls... */
+    for ( i = 0; i < MAX_VIRT_CPUS; i++ )
+        shared_info->vcpu_data[i].evtchn_upcall_mask = 1;
+
+    shared_info->n_vcpu = vcpus;
+    printf(" VCPUS:         %d\n", shared_info->n_vcpu);
+
+    munmap(shared_info, PAGE_SIZE);
+
+    /* Send the page update requests down to the hypervisor. */
+    if ( finish_mmu_updates(xc_handle, mmu) )
+        goto error_out;
+
+    free(mmu);
+    free(page_array);
+
+    *pvsi = vstartinfo_start;
+    *pvke = image_info->entry_addr;
+
+    return 0;
+
+ error_out:
+    if ( mmu != NULL )
+        free(mmu);
+    if ( page_array != NULL )
+        free(page_array);
+    return -1;
+}
+
+int xc_reactos_build(int xc_handle,
+                     u32 domid,
+                     const char *image_name,
+                     const char *module_name,
+                     const char *cmdline,
+                     unsigned int control_evtchn,
+                     unsigned long flags,
+                     unsigned int vcpus)
+{
+    dom0_op_t launch_op, op;
+    int module_fd = -1;
+    int rc, i;
+    vcpu_guest_context_t st_ctxt, *ctxt = &st_ctxt;
+    unsigned long nr_pages;
+    char         *image = NULL;
+    unsigned long image_size, module_size=0;
+    unsigned long vstartinfo_start, vkern_entry;
+
+    if ( (nr_pages = xc_get_tot_pages(xc_handle, domid)) < 0 )
+    {
+        PERROR("Could not find total pages for domain");
+        goto error_out;
+    }
+
+    if ( (image = xc_read_kernel_image(image_name, &image_size)) == NULL )
+        goto error_out;
+
+    if ( (module_name != NULL) && (strlen(module_name) != 0) )
+    {
+        if ( (module_fd = open(module_name, O_RDONLY)) < 0 )
+        {
+            PERROR("Could not open the module image");
+            goto error_out;
+        }
+
+        module_size = xc_get_filesz(module_fd);
+    }
+
+    if ( mlock(&st_ctxt, sizeof(st_ctxt) ) )
+    {   
+        PERROR("Unable to mlock ctxt");
+        return 1;
+    }
+
+    op.cmd = DOM0_GETDOMAININFO;
+    op.u.getdomaininfo.domain = (domid_t)domid;
+    if ( (do_dom0_op(xc_handle, &op) < 0) || 
+         ((u16)op.u.getdomaininfo.domain != domid) )
+    {
+        PERROR("Could not get info on domain");
+        goto error_out;
+    }
+
+    if ( xc_domain_get_vcpu_context(xc_handle, domid, 0, ctxt) )
+    {
+        PERROR("Could not get vcpu context");
+        goto error_out;
+    }
+
+    if ( !(op.u.getdomaininfo.flags & DOMFLAGS_PAUSED) ||
+         (ctxt->pt_base != 0) )
+    {
+        ERROR("Domain is already constructed");
+        goto error_out;
+    }
+
+    if ( setup_guest(xc_handle, domid, image, image_size, 
+                       module_fd, module_size, nr_pages, 
+                       &vstartinfo_start, &vkern_entry,
+                       ctxt, cmdline,
+                       op.u.getdomaininfo.shared_info_frame,
+                       control_evtchn, flags, vcpus) < 0 )
+    {
+        ERROR("Error constructing guest OS");
+        goto error_out;
+    }
+
+    if ( module_fd >= 0 )
+        close(module_fd);
+    if ( image != NULL )
+        free(image);
+
+    ctxt->flags = 0;
+
+    /*
+     * Initial register values:
+     *  DS,ES,FS,GS = FLAT_KERNEL_DS
+     *       CS:EIP = FLAT_KERNEL_CS:start_pc
+     *       SS:ESP = FLAT_KERNEL_DS:start_stack
+     *          ESI = start_info
+     *  [EAX,EBX,ECX,EDX,EDI,EBP are zero]
+     *       EFLAGS = IF | 2 (bit 1 is reserved and should always be 1)
+     */
+    ctxt->user_regs.ds = FLAT_KERNEL_DS;
+    ctxt->user_regs.es = FLAT_KERNEL_DS;
+    ctxt->user_regs.fs = FLAT_KERNEL_DS;
+    ctxt->user_regs.gs = FLAT_KERNEL_DS;
+    ctxt->user_regs.ss = FLAT_KERNEL_DS;
+    ctxt->user_regs.cs = FLAT_KERNEL_CS;
+    ctxt->user_regs.eip = vkern_entry;
+    ctxt->user_regs.esp = vstartinfo_start + 2*PAGE_SIZE;
+    ctxt->user_regs.esi = vstartinfo_start;
+    ctxt->user_regs.eflags = 1 << 9; /* Interrupt Enable */
+
+    /* FPU is set up to default initial state. */
+    memset(&ctxt->fpu_ctxt, 0, sizeof(ctxt->fpu_ctxt));
+
+    /* Virtual IDT is empty at start-of-day. */
+    for ( i = 0; i < 256; i++ )
+    {
+        ctxt->trap_ctxt[i].vector = i;
+        ctxt->trap_ctxt[i].cs     = FLAT_KERNEL_CS;
+    }
+
+    /* No LDT. */
+    ctxt->ldt_ents = 0;
+    
+    /* Use the default Xen-provided GDT. */
+    ctxt->gdt_ents = 0;
+
+    /* Ring 1 stack is the initial stack. */
+    ctxt->kernel_ss = FLAT_KERNEL_DS;
+    ctxt->kernel_sp = vstartinfo_start + 2*PAGE_SIZE;
+
+    /* No debugging. */
+    memset(ctxt->debugreg, 0, sizeof(ctxt->debugreg));
+
+    /* No callback handlers. */
+#if defined(__i386__)
+    ctxt->event_callback_cs     = FLAT_KERNEL_CS;
+    ctxt->event_callback_eip    = 0;
+    ctxt->failsafe_callback_cs  = FLAT_KERNEL_CS;
+    ctxt->failsafe_callback_eip = 0;
+#elif defined(__x86_64__)
+    ctxt->event_callback_eip    = 0;
+    ctxt->failsafe_callback_eip = 0;
+    ctxt->syscall_callback_eip  = 0;
+#endif
+
+    memset( &launch_op, 0, sizeof(launch_op) );
+
+    launch_op.u.setdomaininfo.domain = (domid_t)domid;
+    launch_op.u.setdomaininfo.vcpu   = 0;
+    launch_op.u.setdomaininfo.ctxt   = ctxt;
+
+    launch_op.cmd = DOM0_SETDOMAININFO;
+    rc = do_dom0_op(xc_handle, &launch_op);
+    
+    return rc;
+
+ error_out:
+    if ( module_fd >= 0 )
+        close(module_fd);
+    if ( image != NULL )
+        free(image);
+
+    return -1;
+}
+
+static int parsereactosimage(char *base, 
+                             unsigned long size,
+                             struct xen_reactos_table **table)
+{
+    unsigned long *probe_ptr;
+    unsigned probe_index;
+    unsigned probe_count;
+
+    /* Don't go outside the image */
+    if ( size < sizeof(struct xen_reactos_table) )
+    {
+        ERROR("Image does not have a valid xen_reactos table.");
+        return -EINVAL;
+    }
+    probe_count = size;
+    /* Restrict to first 8k */
+    if ( 8192 < probe_count )
+    {
+        probe_count = 8192;
+    }
+    probe_count = (probe_count - sizeof(struct xen_reactos_table)) /
+                  sizeof(unsigned long);
+
+    /* Search for the magic header */
+    probe_ptr = (unsigned long *) base;
+    *table = NULL;
+    for ( probe_index = 0; probe_index < probe_count; probe_index++ )
+    {
+        if ( XEN_REACTOS_MAGIC3 == *probe_ptr )
+        {
+            *table = (struct xen_reactos_table *) probe_ptr;
+            /* Checksum correct? */
+            if ( 0 == (*table)->magic + (*table)->flags + (*table)->checksum )
+            {
+                break;
+            }
+            *table = NULL;
+        }
+        probe_ptr++;
+    }
+    if ( NULL == *table )
+    {
+        ERROR("Image does not have a valid xen_reactos table.");
+        return -EINVAL;
+    }
+    if ( FLAGS_REQUIRED != ((*table)->flags & FLAGS_MASK) )
+    {
+        ERROR("xen_reactos flags required 0x%08x found 0x%08lx", FLAGS_REQUIRED,
+              (*table)->flags & FLAGS_MASK);
+        return -EINVAL;
+    }
+
+    return 0;
+}
+
+static int
+loadreactosimage(
+    char *image_base, unsigned long image_size, int xch, u32 dom,
+    unsigned long *parray, struct xen_reactos_table *image_info)
+{
+    unsigned long size;
+    char         *va;
+    unsigned long done, chunksz;
+
+    /* Determine image size */
+    if ( 0 == image_info->load_end_addr )
+    {
+        size = image_size  - (((char *) image_info - image_base) -
+                              (image_info->header_addr -
+                               image_info->load_addr));
+    }
+    else
+    {
+        size = image_info->load_end_addr - image_info->load_addr;
+    }
+
+    /* It's possible that we need to skip the first part of the image */
+    image_base += ((char *)image_info - image_base) -
+                  (image_info->header_addr - image_info->load_addr);
+
+    for ( done = 0; done < size; done += chunksz )
+    {
+        va = xc_map_foreign_range(
+            xch, dom, PAGE_SIZE, PROT_WRITE, parray[done>>PAGE_SHIFT]);
+        chunksz = size - done;
+        if ( chunksz > PAGE_SIZE )
+            chunksz = PAGE_SIZE;
+        memcpy(va, image_base + done, chunksz);
+        munmap(va, PAGE_SIZE);
+    }
+
+    if ( 0 != image_info->bss_end_addr &&
+         image_info->load_addr + size < image_info->bss_end_addr )
+    {
+        size = image_info->bss_end_addr - image_info->load_addr;
+    }
+    for ( ; done < size; done += chunksz )
+    {
+        va = xc_map_foreign_range(
+            xch, dom, PAGE_SIZE, PROT_WRITE, parray[done>>PAGE_SHIFT]);
+        chunksz = size - done;
+        if ( chunksz > (PAGE_SIZE - (done & (PAGE_SIZE-1))) )
+            chunksz = PAGE_SIZE - (done & (PAGE_SIZE-1));
+        memset(va + (done & (PAGE_SIZE-1)), 0, chunksz);
+        munmap(va, PAGE_SIZE);
+    }
+
+    return 0;
+}

Re: [PATCH] domain builder for ReactOS

[Christian Limpach]

On 6/2/05, Ge van Geldorp <gvg@reactos.com> wrote:
> As announced earlier (http://lists.xensource.com/archives/html/xen-devel/2005-03/msg01160.html)
> I'm working on porting ReactOS to Xen. The first stage, getting our bootloader
> running, is complete now. Progress report and a screenshot on
> http://reactos.com/wiki/index.php/Xen_port
> 
> To start ReactOS in a Xen domain, a ReactOS domain builder is needed. Patches
> to implement that are included below.

I'm not too keen on this approach:  we try to keep the number of
domain builders small.  Ideally we'd only want one builder for
paravirtualized guests and one for hardware assisted guests.  For
paravirtualized guests, this is the mis-named "linux builder".  We
have a plan9 specific builder because plan9 uses a.out, but I think it
would be preferable to support additional file format loaders within
the linux builder.

Why do you think that you need a different builder?  Especially since
you're going to use a bootloader anyway, your actual kernel image file
can be of whatever format you like...  If your main/only struggle is
with the ELF format, then please consider adding support for
additional loaders in the existing builder.

    christian

RE: [PATCH] domain builder for ReactOS

[Ge van Geldorp]

> From: Christian Limpach 
>
> Why do you think that you need a different builder?  
> Especially since you're going to use a bootloader anyway, 
> your actual kernel image file can be of whatever format you 
> like...  If your main/only struggle is with the ELF format, 
> then please consider adding support for additional loaders in 
> the existing builder.

Yes, the reason for the different builder is that our bootloader is not in
ELF format. I'm not sure the linux ELF loader and my loader are going to
have much code in common, which is why I opted for a different builder.
However, I don't see major problems adding the code to the Linux builder, so
if that's what you prefer, that's how I'll do it.

Gé van Geldorp.

Re: [PATCH] domain builder for ReactOS

[Christian Limpach]

On Fri, Jun 03, 2005 at 12:51:09AM +0200, Ge van Geldorp wrote:
> > From: Christian Limpach 
> >
> > Why do you think that you need a different builder?  
> > Especially since you're going to use a bootloader anyway, 
> > your actual kernel image file can be of whatever format you 
> > like...  If your main/only struggle is with the ELF format, 
> > then please consider adding support for additional loaders in 
> > the existing builder.
> 
> Yes, the reason for the different builder is that our bootloader is not in
> ELF format.

Well, your webpage says that right now you're building your loader as an
ELF image and I guess use the linux builder?  Can't you stick with that?
Even if it's inconvenient to only being able to build the loader on Linux,
how often does the loader need to be rebuilt?

> I'm not sure the linux ELF loader and my loader are going to
> have much code in common, which is why I opted for a different builder.

The elf loading functions in xc_linux_build make up less than half of
the file -- ideally you should be able to use the setup_guest and
xc_linux_build functions without too many changes.

I'd suggest that you move the elf loading functions into a separate
file (xc_load_elf.c) and put your load functions in a different file.

You'll also need to add a probe function to identify the type of the
image, which could then return a pointer to a struct with function
pointers to parseelfimage/loadelfimage in the elf case and then call
these through the pointers.

> However, I don't see major problems adding the code to the Linux builder, so
> if that's what you prefer, that's how I'll do it.

The other question is whether it makes much sense to add a loader/builder
before there's a kernel?

    christian

RE: [PATCH] domain builder for ReactOS

[Ge van Geldorp]

> From: Christian Limpach 
> 
> Well, your webpage says that right now you're building your 
> loader as an ELF image and I guess use the linux builder?  

Correct.

> Can't you stick with that?
> Even if it's inconvenient to only being able to build the 
> loader on Linux, how often does the loader need to be rebuilt?

No, building as an ELF image is only possible as long as I'm using a branch
for development. Most of our developers are building on Windows, not on
Linux, so the question "how often" becomes kind of moot. They would simply
be unable to build the bootloader, ever. We see the bootloader as an
integrated part of our project, so that would not be acceptable.

Perhaps a little more background on the bootloader and why we need it: it is
normally built as a binary (unstructured) image, which is loaded by the
partition bootsector. It is also multiboot-compliant, so another way to load
it is using Grub. The bootloader will load the kernel and the infamous
registry. The registry contains (amongst a lot of other stuff) a list of
boot-time drivers. The bootloader will parse the registry and load the
required drivers. It will then do some hardware detection and transfer
control to the kernel. The tricky part is that it's the bootloader which
determines which drivers to load.
I estimate that about 80% of our users (testers really) are not using Grub
but are using the bootsector method of getting the loader into memory. This
implies the binary format, there simply isn't enough space in the bootsector
to parse ELF headers. So we're stuck with the binary format.

> The other question is whether it makes much sense to add a 
> loader/builder before there's a kernel?

The reason I'm submitting a Xen patch at this point is that I've completed a
well-defined task now (getting the bootloader to run under Xen) and it's a
good point to merge the development branch into the main trunk. However, I
do need to get rid of the ELF format to do that. And that in turn means I
can no longer use the current linux builder/loader in Xen.

Ge van Geldorp.

Re: [PATCH] domain builder for ReactOS

[Jacob Gorm Hansen]

Ge van Geldorp wrote:

> The reason I'm submitting a Xen patch at this point is that I've completed a
> well-defined task now (getting the bootloader to run under Xen) and it's a
> good point to merge the development branch into the main trunk. However, I
> do need to get rid of the ELF format to do that. And that in turn means I
> can no longer use the current linux builder/loader in Xen.

Xen domUs need to have a bios, so we do not need to have domain-specific
stuff like ELF-parsing in dom0. I will post to source to my 'mstrap'
attempt at this tomorrow for people to comment on.

Jacob

Re: [PATCH] domain builder for ReactOS

[Christian Limpach]

On 6/6/05, Jacob Gorm Hansen <jacobg@diku.dk> wrote:
> Xen domUs need to have a bios, so we do not need to have domain-specific
> stuff like ELF-parsing in dom0. I will post to source to my 'mstrap'
> attempt at this tomorrow for people to comment on.

This is an option, but definitely not appropriate for every environment.

    christian

Re: [PATCH] domain builder for ReactOS

[Jacob Gorm Hansen]

Christian Limpach wrote:
> On 6/6/05, Jacob Gorm Hansen <jacobg@diku.dk> wrote:
> 
>>Xen domUs need to have a bios, so we do not need to have domain-specific
>>stuff like ELF-parsing in dom0. I will post to source to my 'mstrap'
>>attempt at this tomorrow for people to comment on.
> 
> 
> This is an option, but definitely not appropriate for every environment.

Seems to work well for VMWare. Could you give an example of an
environment where this would not be appropriate?

Jacob

Re: [PATCH] domain builder for ReactOS

[Christian Limpach]

On 6/6/05, Jacob Gorm Hansen <jacobg@diku.dk> wrote:
> Christian Limpach wrote:
> > On 6/6/05, Jacob Gorm Hansen <jacobg@diku.dk> wrote:
> >
> >>Xen domUs need to have a bios, so we do not need to have domain-specific
> >>stuff like ELF-parsing in dom0. I will post to source to my 'mstrap'
> >>attempt at this tomorrow for people to comment on.
> >
> >
> > This is an option, but definitely not appropriate for every environment.
> 
> Seems to work well for VMWare. Could you give an example of an
> environment where this would not be appropriate?

The model you suggest requires you to install the kernel such that it
is accessible from within the guest environment.  This is not always
desirable nor practical.
[some off-list exchange skipped]
I like the loader + "ramdisk" solution.  Can you reuse the code we
have in the builder now to load elf, elf w/ symtab and bin images? 
Isn't the development environment for the loader too hostile?  I
implemented a similar loader for NetBSD when the linux dom0 loader
didn't support elf yet -- it was quite tedious to relocate stuff in
memory so that the layout would be the same for the loader and the
image it would execute...

    christian

Re: [PATCH] domain builder for ReactOS

[Jacob Gorm Hansen]

Christian Limpach wrote:
> On 6/6/05, Jacob Gorm Hansen <jacobg@diku.dk> wrote:
> 
> The model you suggest requires you to install the kernel such that it
> is accessible from within the guest environment.  This is not always
> desirable nor practical.
> [some off-list exchange skipped]
> I like the loader + "ramdisk" solution.  Can you reuse the code we
> have in the builder now to load elf, elf w/ symtab and bin images? 
> Isn't the development environment for the loader too hostile?  I
> implemented a similar loader for NetBSD when the linux dom0 loader
> didn't support elf yet -- it was quite tedious to relocate stuff in
> memory so that the layout would be the same for the loader and the
> image it would execute...

My code is a port of the loader as per last autumn (I forward-ported my
old code to the new Xen), so right now it only loads ELF, I guess I
could work in later changes as well.

You are right that developing stage2 loaders is harder than writing
Linux binaries, though with a serial cable things are not too bad. The
worst part is turning over control to the OS itself, because you need a
temporary overlap of address spaces, and you would like to free some of
the original domain memory, or at least hand it over the OS.

Jacob