All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jes Sorensen <Jes.Sorensen@redhat.com>
To: QEMU Developers <qemu-devel@nongnu.org>,
	KVM General <kvm@vger.kernel.org>
Cc: Chris Wright <chrisw@redhat.com>
Subject: QEMU/KVM Call notes for Jan 25, 2011
Date: Tue, 25 Jan 2011 17:04:19 +0100	[thread overview]
Message-ID: <4D3EF483.5090308@redhat.com> (raw)

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/qemu-devel@nongnu.org/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/qemu-devel@nongnu.org/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.

WARNING: multiple messages have this Message-ID (diff)
From: Jes Sorensen <Jes.Sorensen@redhat.com>
To: QEMU Developers <qemu-devel@nongnu.org>,
	KVM General <kvm@vger.kernel.org>
Cc: Chris Wright <chrisw@redhat.com>
Subject: [Qemu-devel] QEMU/KVM Call notes for Jan 25, 2011
Date: Tue, 25 Jan 2011 17:04:19 +0100	[thread overview]
Message-ID: <4D3EF483.5090308@redhat.com> (raw)

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/qemu-devel@nongnu.org/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/qemu-devel@nongnu.org/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	other threads:[~2011-01-25 16:04 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-01-25 16:04 Jes Sorensen [this message]
2011-01-25 16:04 ` [Qemu-devel] QEMU/KVM Call notes for Jan 25, 2011 Jes Sorensen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4D3EF483.5090308@redhat.com \
    --to=jes.sorensen@redhat.com \
    --cc=chrisw@redhat.com \
    --cc=kvm@vger.kernel.org \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.