Re: [RFC] Unify KVM kernel-space and user-space code into a single project

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 03/18/2010 01:48 PM, Ingo Molnar wrote:

It's not inevitable, if the projects are badly run, you'll have high
latencies, but projects don't have to be badly run.
So the 64K dollar question is, why does Qemu still suck?

Where people sent patches, it doesn't suck (or sucks less). Where they don't, it still sucks. And it cost way more than $64K.

If moving things to tools/ helps, let's move Fedora to tools/.

How is a patch for the qemu GUI eject button and the kvm shadow mmu related?
Should a single maintainer deal with both?
We have co-maintainers for perf that have a different focus. It works pretty
well.

And it works well when I have patches that change x86 core and kvm. But that's no longer a single repository and we have to coordinate.

Look at git log tools/perf/ and how user-space and kernel-space components
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? '

Both implement the same spec. One is be a code derivative of the other (via Xen).

  - ' how is the in-kernel dynticks implementation related to Qemu's
      implementation of hardware timers? '

The quality of host kernel timers directly determines the quality of qemu's timer emulation.

  - ' how is an in-kernel event for a CD-ROM eject connected to an in-Qemu
      eject event? '

Both implement the same spec. The kernel of course needs to handle all implementation variants, while qemu only needs to implement it once.

  - ' how is a new hardware virtualization feature related to being able to
      configure and use it via Qemu? '

Most features (example: npt) are transparent to userspace, some are 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 x86
      emulator? '

Both implement the same spec. Note qemu is not an emulator but a binary translator.

  - ' how is the performance of the qemu GUI related to the way VGA buffers are
      mapped and accelerated by KVM? '

kvm needs to support direct mapping when possible and efficient data 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. kvm in fact knows nothing about vga, to take your last example. To suggest that qemu needs to be close to the kernel to benefit from the kernel's timer implementation means we don't care about providing quality timing except to ourselves, which luckily isn't the case.

Some time ago the various desktops needed directory change notification, and people implemented inotify (or whatever it's called today). No one suggested tools/gnome/ and tools/kde/.

The quality of a development process is not
defined by the easy cases where no project unification is needed. The quality
of a development process is defined by the _difficult_ cases.

That's true, but we don't have issues at the qemu/kvm boundary. Note we do 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/.

--
error compiling committee.c: too many arguments to function

--
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

[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux