kvm-14 release

The big news here is the update to qemu 0.9.0.

Changes from kvm-13:
- qemu 0.9.0
- too many goodies to list
- kvm can no longer share qemu's bios on Intel hosts due to real mode
trouble. use the supplied bios.
- migration now based on Anthony Liguori's live migration patches (Uri Lublin)
- currently, only non-live migration is supported under kvm
- handle smi on host on AMD hosts (Joerg Roedel)
- random fixes

Note that if you use the modules from Linux 2.6.20, you need to use kvm-12. You can use kvm-14 with Linux 2.6.20, provided you use the external module included in kvm-14.

Quoted 4 lines

Note that if you use the modules from Linux 2.6.20, you need to use kvm-12. You can use kvm-14 with Linux 2.6.20, provided you use the external module included in kvm-14.

Is there back-compatability in the reverse direction ? ie, will the new kmod from kvm-14 work with the older kvm-12 userspace ?

Quoted 8 lines · Daniel P. Berrange

Quoted 4 lines

Note that if you use the modules from Linux 2.6.20, you need to use kvm-12. You can use kvm-14 with Linux 2.6.20, provided you use the external module included in kvm-14.

Is there back-compatability in the reverse direction ? ie, will the new kmod from kvm-14 work with the older kvm-12 userspace ?

No.

It's traditional for the mainline kernel to maintain backward compatibility with existing userspace ABIs (e.g. syscalls).

The idea of a userspace application breaking because of a mainline kernel upgrade is not acceptable to users and also pretty much unsupportable by distros.

Quoted 3 lines · James Morris

It's traditional for the mainline kernel to maintain backward compatibility with existing userspace ABIs (e.g. syscalls).

Quoted 4 lines

The idea of a userspace application breaking because of a mainline kernel upgrade is not acceptable to users and also pretty much unsupportable by distros.

That is of course very true, and it is a goal of kvm to have a stable userspace interface. I plan to target 2.6.21 as the stable ABI release.

Quoted 6 lines · Avi Kivity

Quoted 5 lines · Daniel P. Berrange

Quoted 4 lines

Note that if you use the modules from Linux 2.6.20, you need to use kvm-12. You can use kvm-14 with Linux 2.6.20, provided you use the external module included in kvm-14.

Quoted 5 lines

Quoted 3 lines

Is there back-compatability in the reverse direction ? ie, will the new kmod from kvm-14 work with the older kvm-12 userspace ?

No.

It's traditional for the mainline kernel to maintain backward compatibility with existing userspace ABIs (e.g. syscalls).

Stable ABIs are hard, and this is CONFIG_EXPERIMENTAL after all. I don't think KVM needs ABI stability until CONFIG_EXPERIMENTAL is removed (of course, sooner is always nice if it doesn't create problems).

The big news here is the update to qemu 0.9.0.

Changes from kvm-13:
- qemu 0.9.0
- too many goodies to list
- kvm can no longer share qemu's bios on Intel hosts due to real mode
trouble. use the supplied bios.
- migration now based on Anthony Liguori's live migration patches (Uri Lublin)
- currently, only non-live migration is supported under kvm
- handle smi on host on AMD hosts (Joerg Roedel)
- random fixes

Note that if you use the modules from Linux 2.6.20, you need to use kvm-12. You can use kvm-14 with Linux 2.6.20, provided you use the external module included in kvm-14.

How are you guys in general dealing with the gcc-3.x requirement? Most distros already use gcc-4.x.

How are you guys in general dealing with the gcc-3.x requirement? Most distros already use gcc-4.x.

Quoted 4 lines · Andreas Hasenack

How are you guys in general dealing with the gcc-3.x requirement? Most distros already use gcc-4.x.

gcc-3.x for qemu? Here is how you can install gcc-3.x without breaking gcc-4.x:

http://en.opensuse.org/Qemu_with_kqemu_kernel_module_support

you can then configure qemu with the appropriate options.

The big news here is the update to qemu 0.9.0.

Changes from kvm-13:
- qemu 0.9.0
- too many goodies to list
- kvm can no longer share qemu's bios on Intel hosts due to real mode
trouble. use the supplied bios.
- migration now based on Anthony Liguori's live migration patches (Uri Lublin)
- currently, only non-live migration is supported under kvm
- handle smi on host on AMD hosts (Joerg Roedel)
- random fixes

The bad news is that kvm-14 seems to be a lot slower than kvm-12 + modules from kernel 2.6.20. This is the case with a GNU/kFreeBSD guest. kvm-12 was about 1.5 time faster than qemu + kqemu. kvm-20 is slower than qemu without kqemu...

Does anybody have an idea about this performance regression?

Quoted 7 lines · Aurelien Jarno

The bad news is that kvm-14 seems to be a lot slower than kvm-12 + modules from kernel 2.6.20. This is the case with a GNU/kFreeBSD guest. kvm-12 was about 1.5 time faster than qemu + kqemu. kvm-20 is slower than qemu without kqemu...

Does anybody have an idea about this performance regression?

What is your workload? How are you measuring performance?

Quoted 7 lines · Avi Kivity

Quoted 5 lines · Aurelien Jarno

The bad news is that kvm-14 seems to be a lot slower than kvm-12 + modules from kernel 2.6.20. This is the case with a GNU/kFreeBSD guest. kvm-12 was about 1.5 time faster than qemu + kqemu. kvm-20 is slower than qemu without kqemu...

Quoted 5 lines

Quoted 3 lines

Does anybody have an idea about this performance regression?

What is your workload? How are you measuring performance?

Sorry to answer only now, it took me some time to do some more measurements and have some numbers. I am simply building a Debian package (simulpic) and measuring the build time. Basically the command is:

apt-get source simulpic
cd simulpic-2005-1-28
time debuild -uc us

It surely not a performance index, but I guess it is ok to compare performances between version. It is also quite representative of my use of the machine.

The guest is Debian GNU/kFreeBSD amd64 (ie FreeBSD kernel + GNU libc). It is accessed via ssh, and kvm is started with -nographic, so there is no influence of xorg.

I am doing my tests on an Athlon X2 3800+ machine, running a 2.6.20 kernel. During all my tests, the machine is not loaded with other tasks (except systems tasks), so qemu or kvm have a full core available. Top shows that the core is used between 95 and 100% during the whole build in all cases.

The tests I have made are presented below. In all cases I have verified that the real time correspond to the time of my wall clock, it is correct in all case given the resolution of my wall clock (1 s):

qemu
----

real    3m16.626s
user    2m22.654s
sys     0m41.738s

qemu + kqemu
------------

real    0m51.529s
user    0m11.775s
sys     0m36.215s

kvm 12 + modules from kernel 2.6.20
-----------------------------------

real    0m30.635s
user    0m16.357s
sys     0m8.511s

kvm 12
------

real    0m25.357s
user    0m16.259s
sys     0m6.496s

kvm 13
------

real    0m23.415s
user    0m15.177s
sys     0m5.811s

kvm 14
------

real    7m47.310s
user    5m17.359s
sys     2m3.184s

Using kvm 14, the system is clearly not responsive at all. You can see that without running a benchmark.

Quoted 18 lines · Aurelien Jarno

Quoted 7 lines · Avi Kivity

Quoted 5 lines · Aurelien Jarno

The bad news is that kvm-14 seems to be a lot slower than kvm-12 + modules from kernel 2.6.20. This is the case with a GNU/kFreeBSD guest. kvm-12 was about 1.5 time faster than qemu + kqemu. kvm-20 is slower than qemu without kqemu...

Quoted 5 lines

Quoted 3 lines

Does anybody have an idea about this performance regression?

What is your workload? How are you measuring performance?

Sorry to answer only now, it took me some time to do some more measurements and have some numbers. I am simply building a Debian package (simulpic) and measuring the build time. Basically the command is:

Quoted 8 lines

apt-get source simulpic
cd simulpic-2005-1-28
time debuild -uc us

It surely not a performance index, but I guess it is ok to compare performances between version. It is also quite representative of my use of the machine.

Real workloads (likr this) are more important than synthetic benchmarks.

Quoted 14 lines

The guest is Debian GNU/kFreeBSD amd64 (ie FreeBSD kernel + GNU libc). It is accessed via ssh, and kvm is started with -nographic, so there is no influence of xorg.

I am doing my tests on an Athlon X2 3800+ machine, running a 2.6.20 kernel. During all my tests, the machine is not loaded with other tasks (except systems tasks), so qemu or kvm have a full core available. Top shows that the core is used between 95 and 100% during the whole build in all cases.

The tests I have made are presented below. In all cases I have verified that the real time correspond to the time of my wall clock, it is correct in all case given the resolution of my wall clock (1 s):

Quoted 6 lines

qemu
----

real    3m16.626s
user    2m22.654s
sys     0m41.738s

Is this qemu 0.8.2 or qemu 0.9.0?

Quoted 18 lines

qemu + kqemu
------------

real    0m51.529s
user    0m11.775s
sys     0m36.215s

kvm 12 + modules from kernel 2.6.20
-----------------------------------

real    0m30.635s
user    0m16.357s
sys     0m8.511s

kvm 12
------

real    0m25.357s
user    0m16.259s
sys     0m6.496s

Quoted 6 lines

kvm 13
------

real    0m23.415s
user    0m15.177s
sys     0m5.811s

So far so good. Steady improvement. The low system time indicates a lot of I/O and inefficiency in the qemu device emulation (guest time is charged as system time).

Quoted 7 lines

kvm 14
------

real    7m47.310s
user    5m17.359s
sys     2m3.184s

Quoted 3 lines

Using kvm 14, the system is clearly not responsive at all. You can see that without running a benchmark.

kvm-14 is mostly qemu 0.9.0. Do you get the same results with kvm-14 -no-kvm?

What is your disk image file format, or are you using a partition?

Do the results change (on kvm-14) if you pin the guest to a core with 'taskset 1 qemu ...'

Thank you for taking the time to do real measurements and report the results clearly. That makes it possible (I hope) to find the cause and fix it.

Quoted 3 lines

What is your disk image file format, or are you using a partition?

I am using a raw image file on an ext3 partition.

Quoted 3 lines

Do the results change (on kvm-14) if you pin the guest to a core with 'taskset 1 qemu ...'

Bingo. It now works even faster than kvm-13!

real    0m22.307s
user    0m13.935s
sys     0m4.720

Quoted 5 lines

Thank you for taking the time to do real measurements and report the results clearly. That makes it possible (I hope) to find the cause and fix it.

Thanks for your help! Do you think this problem is fixable? On my final machine, I have a dozen of qemu/kvm running, and when I start them I don't know how they will be used, and so how to pin them on the two cores.

Quoted 6 lines · Aurelien Jarno

Quoted 3 lines

What is your disk image file format, or are you using a partition?

I am using a raw image file on an ext3 partition.

Quoted 10 lines

Quoted 3 lines

Do the results change (on kvm-14) if you pin the guest to a core with 'taskset 1 qemu ...'

Bingo. It now works even faster than kvm-13!

real    0m22.307s
user    0m13.935s
sys     0m4.720

I'm guessing this is due to the glibc aio implementation, which uses threads instead of true aio. The threads may cause the vcpu to migrate frequently from one code to another.

There are two possible solutions:

- use native aio from http://www.bullopensource.org/posix/. I think
the aio signal patches are not yet in, so this may not work.
- teach the scheduler about the cost of migrating vcpus
The first approach will solve itself eventually, though slowly if the current slow rate of aio merging continues. We'll have to do the second.

Quoted 27 lines · Avi Kivity

Quoted 13 lines · Aurelien Jarno

Quoted 5 lines

What is your disk image file format, or are you using a partition?

I am using a raw image file on an ext3 partition.

Quoted 4 lines

Do the results change (on kvm-14) if you pin the guest to a core with 'taskset 1 qemu ...'

Quoted 8 lines

Bingo. It now works even faster than kvm-13!

real    0m22.307s
user    0m13.935s
sys     0m4.720

I'm guessing this is due to the glibc aio implementation, which uses threads instead of true aio. The threads may cause the vcpu to migrate frequently from one code to another.

Quoted 9 lines

There are two possible solutions:

- use native aio from http://www.bullopensource.org/posix/. I think
the aio signal patches are not yet in, so this may not work.
- teach the scheduler about the cost of migrating vcpus
The first approach will solve itself eventually, though slowly if the current slow rate of aio merging continues. We'll have to do the second.

if you prefer the first one, Sébastien will release very soon aio patches for 2.6.20 with an up-to-date libposix-aio.

[advertising] Keep an eye on the bullopensource website. [/advertising] :-P

Regards,
Laurent

------------------------------------------------------------------------

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
------------------------------------------------------------------------

_______________________________________________
kvm-devel mailing list [email protected]
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Quoted 38 lines · Laurent Vivier

Quoted 36 lines · Avi Kivity

Quoted 13 lines · Aurelien Jarno

Quoted 5 lines

What is your disk image file format, or are you using a partition?

I am using a raw image file on an ext3 partition.

Quoted 4 lines

Do the results change (on kvm-14) if you pin the guest to a core with 'taskset 1 qemu ...'

Quoted 8 lines

Bingo. It now works even faster than kvm-13!

real    0m22.307s
user    0m13.935s
sys     0m4.720

I'm guessing this is due to the glibc aio implementation, which uses threads instead of true aio. The threads may cause the vcpu to migrate frequently from one code to another.

There are two possible solutions:

- use native aio from http://www.bullopensource.org/posix/. I think
the aio signal patches are not yet in, so this may not work.
- teach the scheduler about the cost of migrating vcpus
The first approach will solve itself eventually, though slowly if the current slow rate of aio merging continues. We'll have to do the second.

Quoted 3 lines

if you prefer the first one, Sébastien will release very soon aio patches for 2.6.20 with an up-to-date libposix-aio.

Hi Laurent,

I gave that a shot a little bit ago. Ran into two problems.

1) Couldn't avoid linking to -lrt as QEMU uses time functions from it.
2) While I could get things compiling (with patches), QEMU would SEGV almost immediately.

Could you guys maybe give compiling QEMU w/libposix-aio a shot? I'm really interested to see if it makes a difference.

Quoted 38 lines · Laurent Vivier

Quoted 27 lines · Avi Kivity

Quoted 13 lines · Aurelien Jarno

Quoted 5 lines

What is your disk image file format, or are you using a partition?

I am using a raw image file on an ext3 partition.

Quoted 4 lines

Do the results change (on kvm-14) if you pin the guest to a core with 'taskset 1 qemu ...'

Quoted 8 lines

Bingo. It now works even faster than kvm-13!

real    0m22.307s
user    0m13.935s
sys     0m4.720

I'm guessing this is due to the glibc aio implementation, which uses threads instead of true aio. The threads may cause the vcpu to migrate frequently from one code to another.

Quoted 9 lines

There are two possible solutions:

- use native aio from http://www.bullopensource.org/posix/. I think
the aio signal patches are not yet in, so this may not work.
- teach the scheduler about the cost of migrating vcpus
The first approach will solve itself eventually, though slowly if the current slow rate of aio merging continues. We'll have to do the second.

Quoted 3 lines

if you prefer the first one, Sébastien will release very soon aio patches for 2.6.20 with an up-to-date libposix-aio.

Hi Laurent,

I gave that a shot a little bit ago. Ran into two problems.

1) Couldn't avoid linking to -lrt as QEMU uses time functions from it.
2) While I could get things compiling (with patches), QEMU would SEGV almost immediately.

Could you guys maybe give compiling QEMU w/libposix-aio a shot? I'm really interested to see if it makes a difference.

Regards,

Anthony Liguori

Quoted 5 lines

[advertising] Keep an eye on the bullopensource website. [/advertising] :-P

Regards,
Laurent

There are remaining issues : libposix-aio uses kernel AIO, so files must be opened using O_DIRECT and buffers must be aligned. libposix-aio is able to manage other cases but this has a performance cost.

Quoted 7 lines · Laurent Vivier

There are remaining issues : libposix-aio uses kernel AIO, so files must be
opened using O_DIRECT and buffers must be aligned. libposix-aio is able to
manage other cases but this has a performance cost.

Because the guest is also doing dma, the buffers are expected to be aligned (it might be different if using pio, but unlikely).

Quoted 9 lines · Avi Kivity

Quoted 7 lines · Laurent Vivier

There are remaining issues : libposix-aio uses kernel AIO, so files must be
opened using O_DIRECT and buffers must be aligned. libposix-aio is able to
manage other cases but this has a performance cost.

Quoted 2 lines

Because the guest is also doing dma, the buffers are expected to be aligned (it might be different if using pio, but unlikely).

The IDE emulation always uses a temporary buffer. This is partially because you cannot always rely on being able to use an offset on phys_ram_base (when doing user only emulation).

We can pretty easily patch this code though to use the DMA address directly instead of the temporary buffer in the non PIO case. We still have to define a raw_pread() that is capable of emulating sector alignment though since Linux will use PIO at first.

Quoted 10 lines · Anthony Liguori

Quoted 9 lines · Avi Kivity

Quoted 7 lines · Laurent Vivier

There are remaining issues : libposix-aio uses kernel AIO, so files must be
opened using O_DIRECT and buffers must be aligned. libposix-aio is able to
manage other cases but this has a performance cost.

Quoted 6 lines

Quoted 2 lines

Because the guest is also doing dma, the buffers are expected to be aligned (it might be different if using pio, but unlikely).

The IDE emulation always uses a temporary buffer. This is partially because you cannot always rely on being able to use an offset on phys_ram_base (when doing user only emulation).

Why is that?

Quoted 6 lines

We can pretty easily patch this code though to use the DMA address directly instead of the temporary buffer in the non PIO case. We still have to define a raw_pread() that is capable of emulating sector alignment though since Linux will use PIO at first.

Sure. It seems worthwhile for mainline qemu too.

Quoted 10 lines · Avi Kivity

Quoted 9 lines · Anthony Liguori

Quoted 8 lines · Avi Kivity

Quoted 7 lines · Laurent Vivier

There are remaining issues : libposix-aio uses kernel AIO, so files must be
opened using O_DIRECT and buffers must be aligned. libposix-aio is able to
manage other cases but this has a performance cost.

Quoted 6 lines

Quoted 5 lines

Quoted 2 lines

Because the guest is also doing dma, the buffers are expected to be aligned (it might be different if using pio, but unlikely).

The IDE emulation always uses a temporary buffer. This is partially because you cannot always rely on being able to use an offset on phys_ram_base (when doing user only emulation).

Why is that?

Well, user won't do IDE emulation, but cpu_physical_memory_rw has to jump through more hoops for IDE.

What's more relevant though, is it's possible for the guest to setup DMA to device memory, in which case, you need to route the IO to callbacks. That's pretty unlikely though so I think we can stream line it so that we maintain correctness while also getting less copies.

Quoted 50 lines · Anthony Liguori

Quoted 38 lines · Laurent Vivier

Quoted 27 lines · Avi Kivity

Quoted 13 lines · Aurelien Jarno

Quoted 5 lines

What is your disk image file format, or are you using a partition?

I am using a raw image file on an ext3 partition.

Quoted 4 lines

Do the results change (on kvm-14) if you pin the guest to a core with 'taskset 1 qemu ...'

Quoted 8 lines

Bingo. It now works even faster than kvm-13!

real    0m22.307s
user    0m13.935s
sys     0m4.720

I'm guessing this is due to the glibc aio implementation, which uses threads instead of true aio. The threads may cause the vcpu to migrate frequently from one code to another.

Quoted 9 lines

There are two possible solutions:

- use native aio from http://www.bullopensource.org/posix/. I think
the aio signal patches are not yet in, so this may not work.
- teach the scheduler about the cost of migrating vcpus
The first approach will solve itself eventually, though slowly if the current slow rate of aio merging continues. We'll have to do the second.

Quoted 3 lines

if you prefer the first one, Sébastien will release very soon aio patches for 2.6.20 with an up-to-date libposix-aio.

Hi Laurent,

I gave that a shot a little bit ago. Ran into two problems.

1) Couldn't avoid linking to -lrt as QEMU uses time functions from it.
2) While I could get things compiling (with patches), QEMU would SEGV almost immediately.

Quoted 12 lines

Could you guys maybe give compiling QEMU w/libposix-aio a shot? I'm really interested to see if it makes a difference.

Regards,

Anthony Liguori

Quoted 5 lines

[advertising] Keep an eye on the bullopensource website. [/advertising] :-P

Regards,
Laurent

OK, I didn' have time to test the performance of the result, but you can find attached some patches to enable libposix-aio with kvm-14.

first take last patches for linux-2.6.20 and libposix-aio-.0.8.2 from website :

http://sourceforge.net/projects/paiol

if you are using AMD64, you must patch libposix-aio because there is a little problem remaining to detect lio_submit syscall (first attachment)

then apply following patch to kvm-14 (second attachment).

It works fine on my system except when I use "-hda /dev/sdb" : qemu crashes just after mounting filesystems when "init" tries to set kernel parameters with "sysctl" (I use a debian 4.0). If I boot in emergency mode, mounting manually filesystems and running manually sysctl, all works fine. It looks like a synchronization problem.

There are remaining issues : libposix-aio uses kernel AIO, so files must be opened using O_DIRECT and buffers must be aligned. libposix-aio is able to manage other cases but this has a performance cost.

Aurélien, do you have any time to test this on your system ?

Quoted 81 lines · Laurent Vivier

Quoted 50 lines · Anthony Liguori

Quoted 38 lines · Laurent Vivier

Quoted 27 lines · Avi Kivity

Quoted 13 lines · Aurelien Jarno

Quoted 5 lines

What is your disk image file format, or are you using a partition?

I am using a raw image file on an ext3 partition.

Quoted 4 lines

Do the results change (on kvm-14) if you pin the guest to a core with 'taskset 1 qemu ...'

Quoted 8 lines

Bingo. It now works even faster than kvm-13!

real    0m22.307s
user    0m13.935s
sys     0m4.720

I'm guessing this is due to the glibc aio implementation, which uses threads instead of true aio. The threads may cause the vcpu to migrate frequently from one code to another.

Quoted 9 lines

There are two possible solutions:

- use native aio from http://www.bullopensource.org/posix/. I think
the aio signal patches are not yet in, so this may not work.
- teach the scheduler about the cost of migrating vcpus
The first approach will solve itself eventually, though slowly if the current slow rate of aio merging continues. We'll have to do the second.

Quoted 3 lines

if you prefer the first one, Sébastien will release very soon aio patches for 2.6.20 with an up-to-date libposix-aio.

Hi Laurent,

I gave that a shot a little bit ago. Ran into two problems.

1) Couldn't avoid linking to -lrt as QEMU uses time functions from it.
2) While I could get things compiling (with patches), QEMU would SEGV almost immediately.

Quoted 12 lines

Could you guys maybe give compiling QEMU w/libposix-aio a shot? I'm really interested to see if it makes a difference.

Regards,

Anthony Liguori

Quoted 5 lines

[advertising] Keep an eye on the bullopensource website. [/advertising] :-P

Regards,
Laurent

OK, I didn' have time to test the performance of the result, but you can find attached some patches to enable libposix-aio with kvm-14.

first take last patches for linux-2.6.20 and libposix-aio-.0.8.2 from website :

http://sourceforge.net/projects/paiol

if you are using AMD64, you must patch libposix-aio because there is a little problem remaining to detect lio_submit syscall (first attachment)

then apply following patch to kvm-14 (second attachment).

It works fine on my system except when I use "-hda /dev/sdb" : qemu crashes just after mounting filesystems when "init" tries to set kernel parameters with "sysctl" (I use a debian 4.0). If I boot in emergency mode, mounting manually filesystems and running manually sysctl, all works fine. It looks like a synchronization problem.

Quoted 5 lines

There are remaining issues : libposix-aio uses kernel AIO, so files must be opened using O_DIRECT and buffers must be aligned. libposix-aio is able to manage other cases but this has a performance cost.

Aurélien, do you have any time to test this on your system ?

It took me some time to test it, I was not at home and I prefer to be near the machine when I change the kernel!

I have just tried your patches, and I can say it works. I get the same times (minor measurement issues) as when using kvm without your patches and with taskset. Thanks a lot!

Would it be possible to merge the kvm part, and maybe to send it to the qemu mailing list?

Regards,
Aurelien

Quoted 4 lines

Would it be possible to merge the kvm part, and maybe to send it to the qemu mailing list?

I can try to send it to qemu mailing list but I think it is not useful for pure qemu. It seems to improve performance only with kvm.

Avi, your opinion ?

Quoted 10 lines · Laurent Vivier

Quoted 4 lines

Would it be possible to merge the kvm part, and maybe to send it to the qemu mailing list?

I can try to send it to qemu mailing list but I think it is not useful for pure
qemu. It seems to improve performance only with kvm.

Avi, your opinion ?

As it doesn't involve code changes, I see no reason why it can't be merged into qemu. The case would probably be stronger if distributions carried libposix-aio -- do they?

What are the long term plans for libposix-aio? Do you plan to contribute it into glibc?

Also, it probably relies on kernel patches to get signal notification to work. When are these patches going to be merged?