Xen users - Jun 2009 - RE: Merge Xen (the hypervisor) into Linux

On Tue, 2 Jun 2009, Dan Magenheimer wrote:
> > > On Tue, Jun 02, 2009 at 05:00:21PM -0700, Dan Magenheimer wrote:
> > > > That sound you heard was 10000 xen-users@lists.xensource.com
> > > > all having heart attacks at once.
> > > > 
> > > > Need I say more.
> > > 
> > > So maybe I''m stupid, but why would they be having heart
attacks?
> > 
> > Maybe because they asked for an apple and got an apple pie?
> > 
> > That is, they are pushing hard for an interface for Dom0, and 
> > Ingo just 
> > agreed to take it along with the entire Xen hypervisor ;-)
> 
> Um, no, he did not.  He and Avi suggested that Xen be completely
> rearchitected to suit Linux''s preferences. 
I was being a bit tongue in cheek with that comment too.
> 
> A hypervisor is not an operating system.
You say potato I say potato (Hmm, that doesn''t work in text)
>  Yes there is
> similarity in a number of pieces of code.  But there''s
> some similarity between Java and Linux too...
Java can run on hardware?
> 
> > Perhaps the rightful place for the Xen hypervisor is in 
> > Linux. Xen 
> > is GPL right? Thus we could do this even with out the permission from 
> > Citrix.
> 
> (tongue firmly in cheek in case you might assume otherwise)
> Linux is GPL right?  Perhaps the rightful place for the Linux
> operating system is part of Java.  Thus we could do this even
> with out the permission from Ingo.
If Java became GPL it could very well do that.
> 
> > I just don''t see 
> > the Xen team cooperating with the Linux team.  But maybe those 
> > are the old days. 
> 
> Yes, let''s fix that.  Let''s start turning this discussion
towards
> how we can cooperate better.
Sure.
> 
> > The Dom0 push of Xen just seems too much like Linux being
Xen''s sex
> > slave, when it should be the other way around.
> 
> I can certainly see how it might feel that way, but it needn''t
> be... nor the other way around.  But in the end, only the end users
> matter.  If we can''t cooperate, we simply cede the war to Windows
> and Hyper-V.
When I suggest that Xen be merged into Linux, I did not mean it had to be 
like KVM or lguest where the Linux would boot up and run Xen. I mean that 
Xen could still be a micro kernel. The difference would be that its source 
would live in the kernel proper. linux.git/xen?   This way the ABI between 
Xen and Dom0 would always be in sync.

We could even link it in to the vmlinuz, instead of needing the separate 
xen.gz to load first. The vmlinuz could then expand into a Xen 
hypervisor, and also load the Dom0 with it. One image for both entities.

If you want Dom0 ABI in, you have to expect it to change without notice. 
If this breaks Xen, then we don''t want to hear any complaints. This
means
that users of Xen would need to make sure that they have both the most 
recent on hypervisor and kernel and hope that they match.

With the combined image we then get the two to always be together, and no 
problems with the users.

What''s the issue with this? You get to keep your "micro
hypervisor" design
that has been stated to be the superior method.

-- Steve


_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users

Steven Rostedt wrote:
> What''s the issue with this? You get to keep your "micro
hypervisor" design
> that has been stated to be the superior method.
>   
It is a very interesting idea, but it would still be basically a 
completely new project.  If someone started such a project, they could 
probably cannibalize a lot of Xen''s existing code (a funny boomerang, 
since Xen cannibalized Linux''s code when it started), but it would
still
require a lot of work and re-writing, and the result would be a lot 
different than Xen is now.  It would be years before it was ready to be 
used in a production system.  It''s not really realistic to expect all 
the Xen developers and users to drop Xen development, shift gears into 
this new project, and wait until it''s ready to be used. 
(That''s not to
say that the idea has no merit, just that Xen as it is wouldn''t go away
until it this hypothetical linux hypervisor component was mature enough 
for users and developers to jump onto.)

Yeah, lots of interesting implications for such a project.

Having a separate component to be a hypervisor, even if in the same 
tree, would mean we could have dedicated hypervisor schedulers, &c.  
They could (conceivably) work more closely with the dom0 scheduler to 
make things more efficient.

As others have said, it would limit the ability of such a hypervisor to 
be used with other dom0 operatings systems.  Fixing the ABI sufficiently 
so that others can use it might be possible, but it seems to me unlikely 
to meet with much success without a lot of committment on both sides 
(i.e., w/in Linux and within other OS communities).

I''m not sure that it would turn out quite the way some people expect, 
though.  From a technical perspective, I''m not sure getting rid of the 
"ring 1 hack" or requiring HVM support would be the best design choice
for such a project.  And it''s hard to predict what kinds of technical, 
political, or cultural issues, directions, or potential dead-ends a 
project might take. 

 From all angles, it''s too risky to just abandon the current Xen 
codebase until this hypothetical linux hypervisor component has shown 
itself to be viable.

-George

_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users

On Wed, Jun 03, 2009 at 01:03:51PM +0100, George Dunlap
wrote:
> It is a very interesting idea, but it would still be basically a  
> completely new project.  If someone started such a project, they could  
> probably cannibalize a lot of Xen''s existing code (a funny
boomerang,
> since Xen cannibalized Linux''s code when it started), but it would
still
> require a lot of work and re-writing, and the result would be a lot  
> different than Xen is now.  It would be years before it was ready to be  
> used in a production system.  
You might be surprised; if we started with a working dom0/xen pair,
and there were people working on it to clean up dom0/xen interface,
treating it as an internal Linux interface with an eye towards
minimizing contamination of core kernel code, the Linux model of
development can go pretty fast.  Compare and contrast it with the
***years*** of calendar time and decades of wasted man-years of
engineering effort needed to port and backport and maintain dom0
support with Linux.  Given that experience, I could easily see how
some might assume that it would take years to significantly improve
things, but I suspect if xen were merged into mainline with the
assumption that it could be arbitrarily changed to make things sane,
with the primary interface that needed backwards compatibility care
being the xen/domU interface, I expect things would go pretty fast.

What would be lost is dom0 support for other OS''s, but really, is that
such a major loss?  Linux has far better device driver support than
Solaris or FreeBSD, so there is really that much gain in using some
other OS for dom0?

						- Ted

_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users

Theodore Tso, le Wed 03 Jun 2009 15:05:21 -0400, a écrit
:
> What would be lost is dom0 support for other OS''s, but really, is
that
> such a major loss?
Yes.
> Linux has far better device driver support than Solaris or FreeBSD, so
> there is really that much gain in using some other OS for dom0?
Yes.

Thanks for taking that into account.
Samuel

_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users

So first in short, merging xen into a part of linux negates one of the 
central ideas, to focus developer power of different OS''s to one 
compatible hypervisor.

Am 03.06.2009 21:05, schrieb Theodore Tso:
>
> What would be lost is dom0 support for other OS''s, but really, is
that
> such a major loss?
(all is based on my personal feelings and information!)
So my two cents here:

Yes, as for example Sun is one of the most active partys in the Xen 
community at all. They are going to make xvm (the name of xen in 
solaris) a real competitor with VmWare ESX.
Even more Sun is responsible for a lot of cleanup and improvement on the 
hypervisor over the last years.
So to kick Solaris out might be a lot more than just the first nail...

On the other side why use linux as dom0?
just take a second to mind about OpenSolaris as dom0 (release state 
would close up soon to current state of xen), it gifts you zfs.

Florian

   Linux has far better device driver support than
> Solaris or FreeBSD, so there is really that much gain in using some
> other OS for dom0?
>
> 						- Ted
>
> _______________________________________________
> Xen-users mailing list
> Xen-users@lists.xensource.com
> http://lists.xensource.com/xen-users
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On Thu, 4 Jun 2009, Florian Manschwetus wrote:
> 
> On the other side why use linux as dom0?
> just take a second to mind about OpenSolaris as dom0 (release state would
> close up soon to current state of xen), it gifts you zfs.
Let''s turn this around a bit. Can we get Xen to keep a rock solid
stable
ABI?  Where the interface to Xen from Dom0 is never expected to break? All 
old Dom0''s will always work on Xen?

Document this interface, and that it will always work. If it is a clean 
interface, then perhaps Linux could work with it. But it would need to be 
non intrusive. I''ll have to take some time to look at the Dom0 patches
to
see what exactly it requires. Perhaps there''s better ways to accomplish
what is being asked for.

-- Steve


_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users