[Xen-devel] Proposal for init/kexec/hotplug format for Xen

[Rusty Russell <rusty@xxxxxxxxxxxxxxx>]

Hi all,

        This has a degree of overlap with Jeremy's excellent work: I've been
looking at the bundling of device information passed to guest OSes when
they boot, and future uses for kexec and possibly the implementation of
hotplug.

        For kexec and bare-metal bringup, the PPC64 port uses a fairly simple
header + flattened tree of keyword/value pairs (on PPC64, used to hold
the Open Firmware tree plus Linux extras).  This offers flexibility for
new virtual devices, etc; I propose that we adopt this format or
something very similar for Xen, first by putting a pointer into it in
start_info_t, and then migrate entries across as appropriate.  Here's
the code from PPC64:

/* Definitions used by the flattened device tree */
#define OF_DT_HEADER            0xd00dfeed      /* 4: version, 4: total size */
#define OF_DT_BEGIN_NODE        0x1             /* Start node: full name */
#define OF_DT_END_NODE          0x2             /* End node */
#define OF_DT_PROP              0x3             /* Property: name off, size, 
content */
#define OF_DT_END               0x9

#define OF_DT_VERSION           1

/*
 * This is what gets passed to the kernel by prom_init or kexec
 *
 * The dt struct contains the device tree structure, full pathes and
 * property contents. The dt strings contain a separate block with just
 * the strings for the property names, and is fully page aligned and
 * self contained in a page, so that it can be kept around by the kernel,
 * each property name appears only once in this page (cheap compression)
 *
 * the mem_rsvmap contains a map of reserved ranges of physical memory,
 * passing it here instead of in the device-tree itself greatly simplifies
 * the job of everybody. It's just a list of u64 pairs (base/size) that
 * ends when size is 0
 */
struct boot_param_header
{
        u32     magic;                  /* magic word OF_DT_HEADER */
        u32     totalsize;              /* total size of DT block */
        u32     off_dt_struct;          /* offset to structure */
        u32     off_dt_strings;         /* offset to strings */
        u32     off_mem_rsvmap;         /* offset to memory reserve map */
        u32     version;                /* format version */
        u32     last_comp_version;      /* last compatible version */
        /* version 2 fields below */
        u32     boot_cpuid_phys;        /* Which physical CPU id we're booting 
on */
};

Thoughts?
Rusty.
-- 
A bad analogy is like a leaky screwdriver -- Richard Braakman



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/xen-devel