qemu-devel
[Top][All Lists]
Advanced

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]