Message-ID: <20090603085905.0d773cb7@lxorguk.ukuu.org.uk>
Date:	Wed, 3 Jun 2009 08:59:05 +0100
From:	Alan Cox <alan@...rguk.ukuu.org.uk>
To:	Joel Becker <Joel.Becker@...cle.com>
Cc:	Ingo Molnar <mingo@...e.hu>, Steven Rostedt <rostedt@...dmis.org>,
	George Dunlap <george.dunlap@...citrix.com>,
	David Miller <davem@...emloft.net>,
	"jeremy@...p.org" <jeremy@...p.org>,
	Dan Magenheimer <dan.magenheimer@...cle.com>,
	"avi@...hat.com" <avi@...hat.com>,
	"xen-devel@...ts.xensource.com" <xen-devel@...ts.xensource.com>,
	"x86@...nel.org" <x86@...nel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Keir Fraser <Keir.Fraser@...citrix.com>,
	"torvalds@...ux-foundation.org" <torvalds@...ux-foundation.org>,
	"gregkh@...e.de" <gregkh@...e.de>,
	"kurt.hackel@...cle.com" <kurt.hackel@...cle.com>,
	Ian Pratt <Ian.Pratt@...citrix.com>,
	"xen-users@...ts.xensource.com" <xen-users@...ts.xensource.com>,
	ksrinivasan <ksrinivasan@...ell.com>,
	"EAnderson@...ell.com" <EAnderson@...ell.com>,
	"wimcoekaerts@...mekes.net" <wimcoekaerts@...mekes.net>,
	Stephen Spector <stephen.spector@...rix.com>,
	"jens.axboe@...cle.com" <jens.axboe@...cle.com>,
	"npiggin@...e.de" <npiggin@...e.de>
Subject: Re: Merge Xen (the hypervisor) into Linux

> 	The biggest reason I personally want Xen to be in mainline is
> PVM.  Dropping PVM is, to me, pretty much saying "let's merge Xen
> without taking the useful parts."

PVM is and has been for a long time a messaging parallel machine. Can you
not misuse the abbreviation in confusing ways (especially in email I read
in the morning ;))

Merging just hardware assisted vm support initially might be a perfectly
sensible path.

> 	Like Chris said, if we have technical hurdles for Xen to cross,
> let's get them out in the open and fixed.  If previous Xen developer
> interaction has left a bad taste in people's mouths, then the current
> crew has to make it up to us.  But we have to be willing to notice
> they're doing so.

Start by changing the mentality. Right now much of the patched code looks
like  "We made a decision years ago when creating Xen. Now we need to
force that code we wrote into Linux somehow".

Stuff gets merged a lot better if the thinking is "how do we make the
minimal changes to the existing kernel, cleanly and with minimal
inter-relationships". Only after that do you worry about whether
the existing in kernel interfaces are right.

There is a simple reason for this: Changing an interface in the kernel is
a consensus finding process around all visible users of the interface.
It's much easier to do that as a follow up. That way you can bench
alternatives, test if it harms any of the users and merge change sets
that span all the various users of the interface in one go.

It's also frequently the case that when you have a simple clean interface
that doesn't fit some in tree users it becomes blindly obvious what it
should look like.

So I would suggest the path is
- Use existing interfaces
- Merge chunks of the Xen code without worrying too much about performance
  in Xen but worry in detail about bare metal performance
- Don't worry about "hard" problems initially - eg with PAE just use the
  paravirt CPUID hook and deny having PAE to begin with
- Where there isn't a clean simple interface try as hard as possible to
  build some glue code using existing interfaces in the kernel

When it works, doesn't harm bare metal performance and is merged then go
back and worry about the harder stuff, optimisation and fine tuning. It
doesn't even need to be able to run all guests or all configurations
initially.

Also please can folks get out of the "how do we merge Xen" mentality into
the "How do we create dom0 functionality for Xen in Linux" - don't
pre-suppose the existing implementation is right.

Alan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists