linux-kernel - Re: Xen is a feature

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20090602224051.GB32428@goodmis.org>
Date:	Tue, 2 Jun 2009 18:40:51 -0400
From:	Steven Rostedt <rostedt@...dmis.org>
To:	George Dunlap <george.dunlap@...citrix.com>
Cc:	David Miller <davem@...emloft.net>,
	"jeremy@...p.org" <jeremy@...p.org>,
	"mingo@...e.hu" <mingo@...e.hu>,
	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: Xen is a feature

On Fri, May 29, 2009 at 01:01:18PM +0100, George Dunlap wrote:
>
> If we take him at his word, that the root issue is that he fundamentally  
> dislikes the design choice of running Linux-as-hypervisor-component,  
> then we have a difference of opinion and we're just going to have to  
> agree to disagree.  But there are reasons to include it anyway,  
> including benefits to existing Xen users and potential Xen users (who  
> have decided not to use KVM for whatever reason), and the idea of  
> survival-of-the-fittest: Xen and KVM have made different design choices,  
> let's let them both grow and see which one thrives.  If KVM's design is  
> unilaterally superior, eventually Xen will die off.  But I suspect that  
> there's significant demand in the OSS virtualization ecology for both  
> approaches, and the world will be the worse for dom0 support being  
> out-of-tree.
>

Three years ago, when I was hired by Red Hat, I was put on the Virt team,
and I had to work on Xen. I found it an awkward community to say the least.
But I'll refrain from talking about that experience.

Before I was hired, I was full time developing the -rt patch. I was accustom
to the way the Linux development worked, and felt comfortable with it. I was
very pleased when I left the virt team to go back to work on the -rt patch.
Just before I left, KVM came out. I started playing with it and I once again
felt comfortable in that development. I probably would not have mind working
in the virt team if it was KVM that I was working on. I guess the point I'm
trying to make here is that KVM is developed in a Linux community, Xen is not.

The major difference between KVM and Xen is that KVM _is_ part of Linux. Xen
is not. The reason that this matters is that if we need to make a change to
the way Linux works we can simply make KVM handle the change. That is, you
could think of it as Dom0 and the hypervisor would always be in sync.

If we were to break an interface with Dom0 for Xen then we would have a bunch
of people crying foul about us breaking a defined API. One of Thomas's complaints
(and a valid one) is that once Linux supports an external API it must always
keep it compatible. This will hamper new development in Linux if the APIs are
scattered throughout the kernel without much thought.

Now here's a crazy solution. Merge the Xen hypervisor into Linux ;-)

Give full ownership of Xen to the Linux community. One of your people could be
a maintainer. This way the API between Dom0 and the hypervisor would be an internal
one. If you needed to upgrade Dom0, you also must upgrade the hypervisor, but that
would be fine since the hypervisor would also be in the Kernel proper.

This may not solve all the issues that the x86 maintainers have with the Dom0
patches, but it may help solve the API one.

Yeah, I know, I'll be having snowball fights with Saddam before that happens.

-- Steve

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