[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Qemu-devel] QEMU/KVM Call notes for Jan 25, 2011
From: |
Jes Sorensen |
Subject: |
[Qemu-devel] QEMU/KVM Call notes for Jan 25, 2011 |
Date: |
Tue, 25 Jan 2011 17:04:19 +0100 |
User-agent: |
Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101209 Fedora/3.1.7-0.35.b3pre.fc14 Lightning/1.0b3pre Thunderbird/3.1.7 |
Hello,
Please find attached my notes from the weekly QEMU/KVM call January 25,
2011. My apologies if I got something wrong.
Jes
- QEMU 0.14/0.15 releases
- Feb 1st 2011 branch to stable tree for 0.14. Anthony would like to
do a formal release quickly, so hopefully within 1-2 weeks after
snapshot (Feb 15, 2011).
- We should plan a formal release schedule for 0.15
http://wiki.qemu.org/Planning/0.15-example
- coroutines
- Proposal from Stefan Hajnoczi
http://www.mail-archive.com/address@hidden/msg52522.html
- First example is to try and calls to synchronous system calls in
QCOW2 codebase.
- Suggest every image format in block layer have it's own coroutine
layer.
- Long term, can/should we apply this to entire block layer?
Q: Can we go to real threads in the block layer?
A: coroutines are light weight, and we have more control, but it is
an option. Going to threads would require a serious amount of
work making the full QEMU stack thread safe.
Doesn't solve the parallelism problem, so not the final long term
solution to the scalability problem.
Q: Should we do coroutines in the block layer rather than the image
formats? This would provide aio support for formats that do not
currently implement aio calls.
A: Avi suggests mixed approach, to benefit from not having explicit
synchronization points in high performance formats.
Follow-on longer discussion about implementation details, which is
to be followed up in email.
- glib integration
- Proposal from Anthony
http://www.mail-archive.com/address@hidden/msg52798.html
- Provides portable interfaces to threading, data structures, and
utility functions.
- Idea would be to get rid of a lot of duplicated code which we would
get from glib instead.
- Also consider gio and gobject.
- gobject could be a replacement for qdev
- gobject could help make vnc server become standalone
- Not suggesting to convert everything to glib types (gint, guint,
etc). Clarification of which types are recommended will be needed
in CODING_STYLE
Q: Which would be the first subsystem to convert
A: Convert QEMU threads to gthreads
- Comment, doing a conversion of QMP would be good, but Luiz will not
have time to look at this for maybe 2 months.
- Suggestion from Paolo Bonzini to make a standalone library for
JSON, rather than relying on the glib implementation
- Google Summer of Code 2011 - please post suggestions to the list,
and we should revisit this item next week.
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- [Qemu-devel] QEMU/KVM Call notes for Jan 25, 2011,
Jes Sorensen <=