* Avi Kivity<avi@xxxxxxxxxx> wrote:
On 03/18/2010 01:48 PM, Ingo Molnar wrote:So is your point that the development process and basic code structure does
Where people sent patches, it doesn't suck (or sucks less). Where theyIt's not inevitable, if the projects are badly run, you'll have highSo the 64K dollar question is, why does Qemu still suck?
latencies, but projects don't have to be badly run.
don't, it still sucks. [...]
not matter at all, it's just a matter of people sending patches? I beg to
differ ...
[...] And it cost way more than $64K.Those bits of Fedora which deeply relate to the kernel - yes.
If moving things to tools/ helps, let's move Fedora to tools/.
Those bits that are arguably separate - nope.
Actually, it works much better if, contrary to your proposal it ends up in aAnd it works well when I have patches that change x86 core and kvm. ButHow is a patch for the qemu GUI eject button and the kvm shadow mmuWe have co-maintainers for perf that have a different focus. It works
related? Should a single maintainer deal with both?
pretty well.
that's no longer a single repository and we have to coordinate.
single repo. Last i checked both of us really worked on such a project, run by
some guy. (Named Linus or so.)
You are obviously arguing for something like UML. Fortunately KVM is not that.Look at git log tools/perf/ and how user-space and kernel-space componentsBoth implement the same spec. One is be a code derivative of the other (via
interact in practice. You'll patches that only impact one side, but you'll
see very big overlap both in contributor identity and in patches as well.
Also, let me put similar questions in a bit different way:
- ' how is an in-kernel PIT emulation connected to Qemu's PIT emulation? '
Xen).
- ' how is the in-kernel dynticks implementation related to Qemu'sThe quality of host kernel timers directly determines the quality of
implementation of hardware timers? '
qemu's timer emulation.
- ' how is an in-kernel event for a CD-ROM eject connected to an in-QemuBoth implement the same spec. The kernel of course needs to handle
eject event? '
all implementation variants, while qemu only needs to implement it
once.
- ' how is a new hardware virtualization feature related to being able toMost features (example: npt) are transparent to userspace, some are
configure and use it via Qemu? '
not. When they are not, we introduce an ioctl() to kvm for
controlling the feature, and a command-line switch to qemu for
calling it.
- ' how is the in-kernel x86 decoder/emulator related to the Qemu x86Both implement the same spec. Note qemu is not an emulator but a
emulator? '
binary translator.
- ' how is the performance of the qemu GUI related to the way VGA buffers arekvm needs to support direct mapping when possible and efficient data
mapped and accelerated by KVM? '
transfer when not. The latter will obviously be much slower. When
direct mapping is possible, kvm needs to track pages touched by the
guest to avoid full screen redraws. The rest (interfacing to X or
vnc, implementing emulated hardware acceleration, full-screen mode,
etc.) are unrelated.
They are obviously deeply related.Not at all. [...]
Or i hope it isnt.
[...] kvm in fact knows nothing about vga, to take your lastLook at the VGA dirty bitmap optimization a'ka the KVM_GET_DIRTY_LOG ioctl.
example. [...]
See qemu/kvm-all.c's kvm_physical_sync_dirty_bitmap().
It started out as a VGA optimization (also used by live migration) and even
today it's mostly used by the VGA drivers - albeit a weak one.
I wish there were stronger VGA optimizations implemented, copying the dirty
bitmap is not a particularly performant solution.
(although it's certainly
better than full emulation) Graphics performance is one of the more painful
aspects of KVM usability today.
[...] To suggest that qemu needs to be close to the kernel to benefit fromThat is not what i said. I said they are closely related, and where
the kernel's timer implementation means we don't care about providing
quality timing except to ourselves, which luckily isn't the case.
technologies are closely related, project proximity turns into project
unification at a certain stage.
Some time ago the various desktops needed directory changeYou are misconstruing and misrepresenting my argument - i'd expect better.
notification, and people implemented inotify (or whatever it's
called today). No one suggested tools/gnome/ and tools/kde/.
Gnome and KDE runs on other kernels as well and is generally not considered
close to the kernel.
Do you seriously argue that Qemu has nothing to do with KVM these days?
That was not what i suggested. They would be solved by what i proposed:The quality of a development process is not defined by the easy casesThat's true, but we don't have issues at the qemu/kvm boundary. Note we do
where no project unification is needed. The quality of a development
process is defined by the _difficult_ cases.
have issues at the qemu/aio interfaces and qemu/net interfaces (out of which
vhost-net was born) but these wouldn't be solved by tools/qemu/.
tools/kvm/, right?