WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] Xen at scale

To: Christian Limpach <chris@xxxxxx>
Subject: Re: [Xen-devel] Xen at scale
From: Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>
Date: Wed, 24 Mar 2004 10:49:35 +0000
Cc: Kip Macy <kmacy@xxxxxxxxxxx>, "MAGENHEIMER,DAN (HP-FtCollins, ex1)" <dan.magenheimer@xxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxxxx
Delivery-date: Wed, 24 Mar 2004 10:58:19 +0000
Envelope-to: steven.hand@xxxxxxxxxxxx
In-reply-to: Your message of "Wed, 24 Mar 2004 11:31:29 +0100." <0aee01c4118b$2c1beb10$070414ac@pin>
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>
Sender: xen-devel-admin@xxxxxxxxxxxxxxxxxxxxx
> > > Maybe there's a simpler solution?
> >
> > I don't think passing an array is more complicated.
> 
> It's more complicated because you need to put it somewhere and then most
> guests have to possibly move it around because they don't like where it was
> put by the builder.  But most of all I think that it's a bad idea to use two
> different interfaces to pass the same kind of data and that we should try to
> keep the amount of pre-initialized data to a minimum.
> 
> It might still be time to switch to using an array but the sooner the better
> and then we should stick with whatever we choose...

It needs to be something other than page tables, really. I'm inclined
to pass the new domain a preinitialised 'phys->machine' translation
table, and only create initial page tables large enough to contain the
kernel image, initial page tables, and the translation table. 16MB of
VA space would be plenty.

At that point the interface is basically "We're giving you just enough
MMU state to bootstrap yourself. Here's a list of the frames that
belong to you -- set up the pagetable structure that you'd like."

Yes, the guest may possibly end up copying the 'phys->mach' table to a
more convenient place. But at worst it will be a few megabytes.

As for breaking the interface to other types of guest OS
(ie. non-Linux) -- they can implement their own domain builder that
sets memory out just as they like.

I'm rewriting the event-callback interface at the moment, but I'll
take a look at MMU bootstrap once that's done (hopefully later
today).

 -- Keir


-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/xen-devel

<Prev in Thread] Current Thread [Next in Thread>