Subject: Re: bouyer-xenamd64 merge (xen roadmap)
To: Petar Bogdanovic <firstname.lastname@example.org>
From: Christoph Egger <Christoph_Egger@gmx.de>
Date: 11/19/2007 10:39:04
On Monday 19 November 2007 09:47:05 Petar Bogdanovic wrote:
> On Sat, Nov 17, 2007 at 09:15:47PM +0000, Alistair Crooks wrote:
> > On Sat, Nov 17, 2007 at 06:21:12PM +0100, Manuel Bouyer wrote:
> > > Hi,
> > > bouyer-xenamd64 is now in quite good shape: a amd64 domU kernel runs
> > > stable, and a dom0 kernel boots and can start a domU (I've still a bug
> > > to track down which cause dom0 to panic under paging activity when
> > > there are domUs running , but it shouldn't be too hard to track down).
> > > The remaining item I want to do before merging to HEAD is investigate
> > > whenever it's possible to use the new config(5) ifdef blocks to merge
> > > back\ arch/xenamd64/conf to arch/amd64/conf and get rid of
> > > arch/xenamd64 entirely. If it's possible some files would have to move,
> > > but nothing much should change in C files.
How about moving the files from arch/xenamd64/ to arch/xen/amd64/ and placing
files.xen_x86 in arch/xen/x86/, files.xen_xen in arch/xen/xen/, files.xen_i386
in arch/xen/i386 and files.xen_amd64 in arch/xen/amd64/ and so on and so
forth. This should allow you to share a lot of entries for xen-i386 and
Then what about arch/xenamd64/include/hypercalls.h ? It looks to be completely
unused to me. Only arch/xenamd64/include/vmparam.h seems to be really needed.
Can't the small hunk be merged into <xen/vmparam.h> ?
Then you are close to get rid of arch/xenamd64/.
> > > As I'd like to get this branch merged in HEAD ASAP after looking at
> > > this last item, please start looking at the changes made to x86 and
> > > amd64 and complain now if you find some part unacceptable.
> > >
> > > Once bouyer-xenamd64 is merged, I'll start a new branch to work on
> > > switching xeni386 to the new x86 pmap and xenamd64 bootstrap codes, and
> > > merge back code from xen/i386 to i386/i386. I'll also look at x86pae
> > > support in Xen, as using the x86 pmap should make this much easier.
> > This is way cool, Manuel - thanks for all your work on this!
> While we are at it: I would like to thank Manuel for all those very
> informative messages/replies in the port-xen archive. They have been
> extremely helpful for me as the average user.
Xen 3.2 is coming up soon. It is already in feature freeze and only fixes get
in. *BSD support has been vastly improved over Xen 3.1. I made most (but not
all) patches from pkgsrc going upstream and additional fixes for them are
there. For example, lock_pages() in
pkgsrc/sysutils/xentools3/patches/patch-ad is 64bit safe in Xen 3.2.
Also you can use xenmon and xentrace now, which are not available
for BSD in Xen 3.1.
I need some feedback, in what is still missing from pkgsrc to get guests
running out-of-the box - I expect this impacts almost all python patches.
To get the Xen 3.2 sources, install pkgsrc/devel/mercurial and run
hg clone http://xenbits.xensource.com/staging/xen-unstable.hg/
Fee free to ask me, if you need some guidance.