[Qemu-devel] Re: QEMU Accel - git tree

["Glauber Costa" <glommer@gmail.com>]

On Fri, Jul 4, 2008 at 6:38 PM, Carlo Marcelo Arenas Belon
<carenas@sajinet.com.pe> wrote:
> On Fri, Jul 04, 2008 at 05:40:03PM -0300, Glauber Costa wrote:
>> Hey Folks
>>
>> I'm publishing a git repository for the QEMU Accel patches. It lives at
>>
>> git://git.kernel.org/pub/scm/virt/qemu/glommer/qemu-accel.git
>
> for the few of us that had been living under a rock, could you give an
> explanation on what is QEMU Accel and why we need one?

Sure.

Currently, kqemu and kvm (not to mention xen, about which I don't
really know about in this case), use a different user <-> kernel
interface. Support for them in qemu requires all of them to spread
code throughout core qemu, negatively affecting readability,
maintainability, all the other sorts of *bilities. One of the sad
aspects of it, is that it makes an possible inclusion of kvm in the
qemu code base much harder to happen, making us maintain our own
"fork" tree. (Xen has the same issue).

The QEMUAccel patchset is an effort to put wrappers in strategic
places throughout qemu code, so any accelerator (kqemu, kvm, xen,
yourown) can register itself, and tell qemu how to do specific
operations.

Talking to hollis last week, he pointed out that a better solution
would be to make all of them to use the same kernel interface. It's a
valid approach, but I believe an user-space interface would be more
flexible. That's why I'm still maintaining this set (now in tree-form
;-) )

(sorry hollis, should have cc'd you in the first message here, but forgot).

> google bounced me back to the a broken link in the qemu homepage that  doesn't
> have a reference to it, and also showed some patches which seem to be trying
> to abstract kqemu and kvm which I presume are part of this git tree.
Yes, exactly.

>
> how is this mean to fit on a qemu or kvm installation, and if its main
> objective is to be able to have a version of qemu compiled with support for
> both kvm and kqemu accelerators, is it at least feature complete enough to
> have that working and let you select which one to use?, under which
> circumstances?

As I said, the kvm code is PoC. I don't plan to start working
seriously on it until there's agreement on the interfaces here, at
least a basic one. kqemu should be running fine. (WFM)

The kvm code, however, do work with limited functionality. The
functionalities it lacks are:
* stability ;-)
* smp
* userspace pit and irqchip

-- 
Glauber Costa.
"Free as in Freedom"
http://glommer.net

"The less confident you are, the more serious you have to act."