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

[Avi Kivity <avi@redhat.com>]

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