[Qemu-devel] Re: [PATCH] remove pieces of source code

[Andreas Färber]

Am 31.05.2009 um 11:15 schrieb Jan Kiszka:

> Andreas Färber wrote:
> > KVM is no alternative either for us because nobody really maintains
> > documentation of what interface and functionality we'd have to  
> > implement
> > on Solaris, Windows, Mac OS X etc. where no KVM is available today.
> >
> > I'd expect some documentation here:
> > http://www.linux-kvm.org/page/Documents -- but no luck. No "Porting  
> > KVM
> > For Dummies". ;(
>
> There was and likely will never be any documentation for kqemu either.

And I'm not complaining about kqemu. No one has suggested me to start  
new ports of kqemu.

> But having worked on both, I can say that kvm is by an order of
> magnitude easier to understand from its sources than kqemu.
>
> Sorry, but if you are really interested in such a port, having to dig
> through source code and ask questions to the community if something
> remains unclear should not be the actual problem.

It is. My using the kqemu accelerator neither makes me an expert on  
x86 architecture nor on any sort of kernel modules. (Just like some  
understanding of TCG and certain other instruction sets doesn't make  
me too knowledgeable about IRQ, DMA, MMU, TLB and all the other TLAs)

The porting issues start with very basic considerations: IIUC the  
relevant part of KVM porting-wise is the kernel side (assuming that  
sufficient userspace code has arrived in upstream QEMU already), which  
by nature of Linux and according to the FAQ is GPL'ed. Meaning that if  
I attempted to port KVM to a new platform, the kernel module, Kernel  
Extension, daemon, Service, driver or whatever form of implementation  
may be needed on the target OS would be required to be GPL'ed as well.  
Can I create a GPL'ed Kernel Extension for Mac OS X? Questionable,  
since it would probably end up in the same address space as  
proprietary/non-GPL code. Similar potential issues with CDDL'ed  
(Open)Solaris kernel, BSD kernels, MIT/X11'ed Haiku kernel and fully  
closed-source Windows. So, to be on the safe side, I can't start  
implementing KVM by reading the KVM source code but would need  
documentation of the interface that needs to be implemented (cf.  
virtio drivers). If KVM wants to be the one standardized interface  
instead of one of three implementations then it needs formalization.  
There are contradicting answers on whether non-GPL code may legally  
dynamically load GPL code, making code and inline comments not  
necessarily a sufficient replacement for proper documentation.  
Especially if it's not my personal wish, but KVM developers trying to  
force people to port their software in order to make their life easier.

Arguing about Open Source, you are forgetting that not everyone gets  
paid for their Open Source contributions to QEMU. If you work on KVM/ 
QEMU for a living and have the time to work on large'ish porting or  
refactoring projects, that's one facet of Open Source only.
Many other people aren't selling but merely using QEMU, be it as a  
tool for (Open Source) application or operating system development or  
for research, because they favor it as a FOSS solution, contributing  
bugfixes and to ongoing platform support. These are often not the same  
people building QEMU on a per-commit basis, testing every apparently  
unrelated patch before it gets committed and breaks things for them,  
and are thus hit the most when some member of the now highly active  
KVM community decides to shuffle features around or to drop something  
in some upcoming release for valid reasons. Are they really "bad"  
community members? Should they better get lost, let you do your KVM  
work and go buy closed-source VMware instead? Or let partially open  
source VirtualBox freeze their system and ruin their Superdrive? I  
don't think so. Having flourishing KVM code inside QEMU is totally  
fine, but pointing the pistol at others, asking to port KVM to a new  
platform with a fixed timeframe and without documentation, even if KVM  
developers happen to dislike kqemu hooks in the sources and QEMU  
maintainers - being on Linux mainly - have turned to KVM, is not okay.  
The problem is not unwillingness, but rather time, information,  
skills, communicativeness and politeness. It makes a major difference  
if someone steps up and posts on qemu-devel, "hey, we'd like to  
replace kqemu with KVM, let's talk about how and when we can make this  
happen", rather than submitting a patch rendering the kqemu kernel  
module unusable, leaving the majority of its current users standing in  
the rain without replacement accelerator. That's got little to do with  
the spirit of Open Source.

I have a dream of something like the Open Group specification, which  
describes a virtualization standard in terms of required C types,  
preprocessor defines, functions, valid parameters, expected return  
values etc. It would allow multiple source-compatible but differing  
implementations and would in theory even allow to consolidate the  
current virtualization island solutions into sane, interoperable  
solutions. Is this too far from KVM reality?

Andreas

P.S. The "KVM on BSD" page (http://www.linux-kvm.org/page/BSD) does in  
fact instruct people to use kqemu!