On 03/18/2010 03:00 PM, Ingo Molnar wrote:
quoted text
> * Avi Kivity<avi@redhat.com>  wrote:
>
>    
>> 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. [...]
>>      
> So is your point that the development process and basic code structure does
> not matter at all, it's just a matter of people sending patches? I beg to
> differ ...
>    

The development process of course matters, and we have worked hard to 
fix qemu's.  Basic code structure also matters, but you don't fix that 
with cp.

quoted text
>> [...]  And it cost way more than K.
>>
>> If moving things to tools/ helps, let's move Fedora to tools/.
>>      
> Those bits of Fedora which deeply relate to the kernel - yes.
> Those bits that are arguably separate - nope.
>    

A qemu GUI is not deeply related to the kernel.  Or at all.

quoted text
>>>> 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.
>>      
> Actually, it works much better if, contrary to your proposal it ends up in a
> single repo. Last i checked both of us really worked on such a project, run by
> some guy. (Named Linus or so.)
>    

Well, when last I sent x86 patches, they went to you and hpa, applied to 
tip, from which I had to merge them back.  Two repositories.  After 
several weeks they did end up in a third repository, Linus'.  The 
process isn't trivial or fast, but it works.

quoted text
>>> 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. [...]
>>      
> You are obviously arguing for something like UML. Fortunately KVM is not that.
> Or i hope it isnt.
>    

I am not arguing for UML and don't understand why you think so.

quoted text
>> [...]  kvm in fact knows nothing about vga, to take your last
>> example. [...]
>>      
> Look at the VGA dirty bitmap optimization a'ka the KVM_GET_DIRTY_LOG ioctl.
>
> 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.

The VGA dirty bitmap is 256 bytes in length.  Copying it doesn't take 
any time at all.

People are in fact working on a copy-less dirty bitmap solution, for 
live migration of very large memory guests.  Expect set_bit_user() 
patches for tip.git.

quoted text
>   (although it's certainly
> better than full emulation) Graphics performance is one of the more painful
> aspects of KVM usability today.
>    

If you have suggestions for further optimizations (or even patches) I'd 
love to hear them.

One solution we are working on is QXL, a framebuffer-less graphics card 
designed for spice.  The use case is again server based (hosted 
desktops) but may be adapted for desktop-on-desktop use.

quoted text
>> [...]  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.
>>      
> That is not what i said. I said they are closely related, and where
> technologies are closely related, project proximity turns into project
> unification at a certain stage.
>    

I really don't see how.  So what if both qemu and kvm implement an 
i8254?  They can't share any code since the internal APIs are so 
different.  Even worse for the x86 emulator as qemu and kvm are 
fundamentally different.  Even more with the qemu timers and kernel 
dyntick code.

quoted text
>> 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/.
>>      
> You are misconstruing and misrepresenting my argument - i'd expect better.
> Gnome and KDE runs on other kernels as well and is generally not considered
> close to the kernel.
>    

qemu runs on other kernels (including Windows), just without kvm.

quoted text
> Do you seriously argue that Qemu has nothing to do with KVM these days?
>    

The vast majority of qemu has nothing to do with kvm, all the kvm 
interface bits are in two files.  Things like the GUI, the VNC server, 
IDE emulation, the management interface (the monitor), live migration, 
qcow2 and ~15 other file format drivers, chipset emulation, USB 
controller emulation, snapshot support, slirp, serial port emulation, 
and a zillion other details have nothing to do with kvm.

quoted text
>>> 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/.
>>      
> That was not what i suggested. They would be solved by what i proposed:
> tools/kvm/, right?
>    

If they were, it would be worth it.

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

--
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/