On 03/18/2010 11:28 AM, Ingo Molnar wrote:
There are all kernel space projects, going through Xorg would be a
horrible waste of performance for full-screen virtualization. It's fine
for the windowed or networked case (and good as a compatibility fallback),
but very much not fine for local desktop use.
For the full-screen case (which is a very common mode of using a guest OS on
the desktop) there's not much of window management needed. You need to
save/restore as you switch in/out.
I don't think I've ever used full-screen mode with my VMs and I use
virtualization on a daily basis.
We hear very infrequently from users using full screen mode.
3D graphics virtualization is extremely difficult in the non-passthrough
case. It really requires hardware support that isn't widely available today
(outside a few NVIDIA chipsets).
Granted it's difficult in the general case.
Xorg framebuffer driver doesn't implement any of the optimizations that the
Linux framebuffer supports and the Xorg driver does not provide use the
kernel's interfaces for providing update regions.
Of course, we need to pull in X into the kernel to fix this, right?
FYI, this part of X has already been pulled into the kernel, it's called
DRM. If then it's being expanded.
It doesn't provide the things we need to a good user experience. You need
things like an absolute input device, host driven display resize, RGBA
hardware cursors. None of these go through DRI and it's those things that
really provide the graphics user experience.
With KSM the display resize is in the kernel.
KMS
Cursor management is not. Yet: i
think it would be a nice feature as the cursor could move even if Xorg is
blocked or busy with other things.
If it was all in the kernel, we'd try to support it.
Any sufficiently complicated piece of software is going to interact with
a lot of other projects. The solution is not to pull it all into one
massive repository. It's to build relationships and to find ways to
efficiently work with the various communities.
That's my whole point with this thread: the kernel side of KVM and qemu,
but all practical purposes should not be two 'separate communities'. They
should be one and the same thing.
I don't know why you keep saying this. The people who are in these
"separate communities" keep claiming that they don't feel this way.
If you are not two separate communities but one community, then why do you go
through the (somewhat masochistic) self-punishing excercise of keeping the
project in two different pieces?
I don't see any actual KVM developer complaining about this so I'm not
sure why you're describing it like this.
In a distant past Qemu was a separate project and KVM was just a newcomer who
used it for fancy stuff. Today as you say(?) the two communities are one and
the same. Why not bring it to its logical conclusion?
We lose a huge amount of users and contributors if we put QEMU in the
Linux kernel. As I said earlier, a huge number of our contributions
come from people not using KVM.
I'm not just saying this to be argumentative. Many of the people in the
community have thought this same thing, and tried it themselves, and we've
all come to the same conclusion.
It's certainly possible that we just missed the obvious thing to do but
we'll never know that unless someone shows us.
I'm not aware of anyone in the past having attempted to move qemu to
tools/kvm/ in the uptream kernel repo, and having reported on the experiences
with such a contribution setup. (obviously it's not possible at all without
heavy cooperation and acceptance from you and Avi, so this will probably
remain a thought experiment forever)
We've tried to create a "clean" version of QEMU specifically for KVM.
Moving it into tools/kvm would be the second step. We've all failed on
the firs step.
If then you must refer to previous attempts to 'strip down' Qemu, right? Those
attempts didnt really solve the fundamental problem of project code base
separation.
If the problem is combining the two, I've sent you a patch that you can
put into tip.git if you're so inclined.
Regards,
Anthony Liguori
Ingo
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
