All of lore.kernel.org
 help / color / mirror / Atom feed
* [RFC] VMI for Xen?
@ 2006-03-14 22:01 Anthony Liguori
  2006-03-16 20:08 ` Anthony Liguori
  0 siblings, 1 reply; 14+ messages in thread
From: Anthony Liguori @ 2006-03-14 22:01 UTC (permalink / raw)
  To: xen-devel, Ian Pratt, Keir Fraser

I'm sure everyone has seen the drop of VMI patches for Linux at this 
point, but just in case, the link is included below.

I've read this version of the VMI spec and have made my way through most 
of the patches.  While I wasn't really that impressed with the first 
spec wrt Xen, the second version seems to be much more palatable.  
Specifically, the code inlining and afterburner-style padding seems like 
a really promising approach to native-speed single kernel images.  Also, 
this version seems much more friendly to p2m.

There are still a few things missing (like guest DMA support) but I 
think the basic ideas are pretty sane.  So what does everyone else 
think?  Is there anything within VMI that would inhibit some of Xen's 
optimizations?  Are there any disadvantages to a VMI-style approach to 
the subarch changes?

How close are we to being able to merge our stuff with mainline?  Have 
we gotten feedback yet on how hard this is going to be?  Would VMI be an 
easier approach to inclusion in mainline?

Just thought it would be prudent to start a discussion here, at least, 
about it...

http://lkml.org/lkml/2006/3/13/140

Regards,

Anthony Liguori

^ permalink raw reply	[flat|nested] 14+ messages in thread
* RE: [RFC] VMI for Xen?
@ 2006-03-16 23:11 Ian Pratt
  2006-03-16 23:24 ` Anthony Liguori
                   ` (2 more replies)
  0 siblings, 3 replies; 14+ messages in thread
From: Ian Pratt @ 2006-03-16 23:11 UTC (permalink / raw)
  To: Anthony Liguori; +Cc: xen-devel

> Just some food for thought,  I did a simple analysis of the 
> size of Xen Linux patches verses the VMI patches.  To make 
> things more fair, I removed everything from the XenoLinux 
> port accept for the i386 xen subarch (so no drivers and no 
> support for other architectures).

Your analysis is still taking all the patches to make dom0 functionality
work, which accounts for a lot of changes and is totally outside of the
scope of VMI.

We've been working with a bunch of RH/Novell folks to create a stripped
down domU-only Xen patch that would be a fairer comparison.

We're currently looking though the new VMI patchset to see whether
there's anything worth having, in particular, if there's anything that
should be added to our patch to support what we can deduce that their
hypervisor probably needs. We've also talking to the VirtualIron team to
make sure we're inclusive as possible.

The current VMI patchset couldn't support Xen's direct-mode (non shadow)
MMU virtualization, and hasn't really been thought through properly for
SMP. I'm sure we'll get something worked out that keeps everyone happy.

Ian
 
> VMI:
> 
> 124 files changed, 4964 insertions(+), 623 deletions(-)
> 
> Xen:
> 
> 185 files changed, 31586 insertions(+), 142 deletions(-)
> 
> So the Xen port adds 6 times more code than VMI.  I certainly 
> don't think VMI for Xen is going to be as fast as native Xen 
> but I don't know of anything that would cause a substantial 
> change in VMI to add the necessary optimizations that would 
> result in a massive change in the size of the patches.
> 
> I should also mention that one should also consider the size 
> of the VMI Xen ROM too.  For the L4-based ROM that's going to 
> be ~10k lines but I expect that if the Xen hypercalls were 
> adjusted a little bit, it would drop much less.  For 
> instance, Xen already does platform device emulation in the 
> hypervisor for HVM domains so if that were reused it would 
> knock out a fair amount of the ROM code.
> 
> It seems like there are some merits to the VMI approach.  Is 
> there something I'm missing?  I admit I don't understand the 
> XenoLinux changes well enough to know with certainity if 
> there's something major that justifies the difference in 
> size.  I'm hoping someone can hit me with a clue stick though 
> if there is :-)
> 
> Regards,
> 
> Anthony Liguori
> 
> Anthony Liguori wrote:
> > I'm sure everyone has seen the drop of VMI patches for 
> Linux at this 
> > point, but just in case, the link is included below.
> >
> > I've read this version of the VMI spec and have made my way through 
> > most of the patches.  While I wasn't really that impressed with the 
> > first spec wrt Xen, the second version seems to be much more 
> > palatable.  Specifically, the code inlining and afterburner-style 
> > padding seems like a really promising approach to 
> native-speed single 
> > kernel images.  Also, this version seems much more friendly to p2m.
> >
> > There are still a few things missing (like guest DMA support) but I 
> > think the basic ideas are pretty sane.  So what does everyone else 
> > think?  Is there anything within VMI that would inhibit 
> some of Xen's 
> > optimizations?  Are there any disadvantages to a VMI-style 
> approach to 
> > the subarch changes?
> >
> > How close are we to being able to merge our stuff with 
> mainline?  Have 
> > we gotten feedback yet on how hard this is going to be?  
> Would VMI be 
> > an easier approach to inclusion in mainline?
> >
> > Just thought it would be prudent to start a discussion 
> here, at least, 
> > about it...
> >
> > http://lkml.org/lkml/2006/3/13/140
> >
> > Regards,
> >
> > Anthony Liguori
> >
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xensource.com
> > http://lists.xensource.com/xen-devel
> 
> 

^ permalink raw reply	[flat|nested] 14+ messages in thread
[parent not found: <4419F36A.6070906@vmware.com>]

end of thread, other threads:[~2006-03-19 15:51 UTC | newest]

Thread overview: 14+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2006-03-14 22:01 [RFC] VMI for Xen? Anthony Liguori
2006-03-16 20:08 ` Anthony Liguori
2006-03-19 15:51   ` Anthony Liguori
  -- strict thread matches above, loose matches on Subject: below --
2006-03-16 23:11 Ian Pratt
2006-03-16 23:24 ` Anthony Liguori
2006-03-16 23:33 ` Anthony Liguori
2006-03-17 10:42   ` Keir Fraser
2006-03-17 14:39     ` Anthony Liguori
2006-03-17 18:19     ` Zachary Amsden
2006-03-16 23:55 ` Chris Wright
2006-03-17  0:10   ` Anthony Liguori
2006-03-17  8:53     ` Keir Fraser
2006-03-17  8:59       ` Keir Fraser
     [not found] <4419F36A.6070906@vmware.com>
2006-03-17  0:09 ` Daniel Arai

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.