Xen 
 
Home About Xen.org Xen Xen Summit Wiki Mailing List Bug Tracker Xen Downloads
 
   
 

xen-devel

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

To: Rusty Russell <rusty@xxxxxxxxxxxxxxx>
Subject: Re: [Xen-devel] Proposal for init/kexec/hotplug format for Xen
From: Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>
Date: Sun, 27 Feb 2005 10:53:34 +0000
Cc: Jeremy Katz <katzj@xxxxxxxxxx>, Xen Mailing List <xen-devel@xxxxxxxxxxxxxxxxxxxxx>
Delivery-date: Sun, 27 Feb 2005 10:57:10 +0000
Envelope-to: xen+James.Bulpin@xxxxxxxxxxxx
In-reply-to: <1109451460.32219.11.camel@xxxxxxxxxxxxxxxxxxxxx>
List-archive: <http://sourceforge.net/mailarchive/forum.php?forum=xen-devel>
List-help: <mailto:xen-devel-request@lists.sourceforge.net?subject=help>
List-id: List for Xen developers <xen-devel.lists.sourceforge.net>
List-post: <mailto:xen-devel@lists.sourceforge.net>
List-subscribe: <https://lists.sourceforge.net/lists/listinfo/xen-devel>, <mailto:xen-devel-request@lists.sourceforge.net?subject=subscribe>
List-unsubscribe: <https://lists.sourceforge.net/lists/listinfo/xen-devel>, <mailto:xen-devel-request@lists.sourceforge.net?subject=unsubscribe>
References: <1109451460.32219.11.camel@xxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-admin@xxxxxxxxxxxxxxxxxxxxx

On 26 Feb 2005, at 20:57, Rusty Russell wrote:

        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.

I like the idea of bringing out device discovery, bringup, teardown, recovery all into its own driver or subsystem -- it seems the obvious way to go. But I think the 'device tree' should be in the to-be-designed persistent store, and we publish an interface to allow guests to peek/poke that store.

 -- Keir



-------------------------------------------------------
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