public inbox for kvm@vger.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.

                 reply	other threads:[~2011-01-25 16:04 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox