[Qemu-devel] QEMU Accel - git tree

[Qemu-devel] QEMU Accel - git tree

[Glauber Costa]

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

and have two branches. The master branch tracks the general, stable
state of the patch. It is meant to be an append-only repository,
and contains what was sent to the list some days ago, plus a few other
bug fixes that happened from that time until now.

I'm also publishing an accel-kvm branch for the brave ones. It will be
frequently rebased, so if you track it, it'll break.
This contains the work towards moving kvm into shape with accel.

Hope you enjoy.

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

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

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

[Carlo Marcelo Arenas Belon]

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?

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.

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?

Carlo

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

[Glauber Costa]

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

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

[Gerd Hoffmann]

Glauber Costa wrote:
> 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
> ;-) )

Especially in case we'll add xen to the picture ...

cheers,
  Gerd

-- 
http://kraxel.fedorapeople.org/xenner/

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

[Jamie Lokier]

Gerd Hoffmann wrote:
> Glauber Costa wrote:
> > 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
> > ;-) )
> 
> Especially in case we'll add xen to the picture ...

However, don't forget that plain QEMU doesn't use a kernel interface.
Does that count as a "different" kernel interface for the purpose of
these hooks? :-)

-- Jamie

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

[Glauber Costa]

On Mon, Jul 7, 2008 at 2:12 PM, Jamie Lokier <jamie@shareable.org> wrote:
> Gerd Hoffmann wrote:
>> Glauber Costa wrote:
>> > 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
>> > ;-) )
>>
>> Especially in case we'll add xen to the picture ...
>
> However, don't forget that plain QEMU doesn't use a kernel interface.
> Does that count as a "different" kernel interface for the purpose of
> these hooks? :-)

I don't think the word "kernel interface" has any need to be involved
whatsoever, but to ilustrate a particular kvm / kqemu issue.
The way it is now, that's just a userspace interface for an an
accelerator, whatever it is.

> -- Jamie
>
>
>



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

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