| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
Re: [Xen-devel] [RFC] VMI for Xen?
Thanks for the response Ian!
Ian Pratt wrote:
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.
Could you elaborate a little? Do you mean direct access to hardware or
the domain management stuff? I would expect that it's the former since
the later should be well isolated in privcmd.
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.
Ah, excellent, is there code available anywhere? Has there been
progress on microxen?
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.
Excellent. The thing that stuck out to me the most is binary rewriting
for native code. There seems that there has been a bit of performance
work done to suggest that that's the best way to ensure that there's no
different on native.
We've also talking to the VirtualIron team to
make sure we're inclusive as possible.
Sweet.
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.
I hope this doesn't appear too prodding. There seemed to be very little
technical objection on LKML and I fear that Xen is not being represented
well enough. A note on LKML explaining the problems and how Xen solves
them would certainly being really useful.
Regards,
Anthony Liguori
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@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
| |
|
Home