From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=56514 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1ObE5H-0006yT-F0 for qemu-devel@nongnu.org; Tue, 20 Jul 2010 10:46:32 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1ObE4w-0006gh-Bz for qemu-devel@nongnu.org; Tue, 20 Jul 2010 10:45:58 -0400 Received: from mx1.redhat.com ([209.132.183.28]:43728) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1ObE4w-0006ga-5D for qemu-devel@nongnu.org; Tue, 20 Jul 2010 10:45:54 -0400 Date: Tue, 20 Jul 2010 07:45:51 -0700 From: Chris Wright Message-ID: <20100720144551.GB32665@x200.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Subject: [Qemu-devel] KVM call minutes for July 20 List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: kvm@vger.kernel.org Cc: qemu-devel@nongnu.org 0.12.stable - start w/ git tree + pull requests - release process is separate from commit access - justin will put up a tree for pull requests - there's current backlog, what about that? - anthony's concern with -stable is the testing (upstream tree gets more testing than -stable) - 0.12.5? - planning to do next w/ 0.13 release - aurelien may cut a release - justin will do some sanity testing, most patches are in fedora anyway 0.13 - rc RSN (hopefully this week, top priority for anthony) kvm testsuite - was planning to clean up and contribute to qemu - now thinking perhaps just split it out to its own repo - not really qemu code, not really kvm code, not cross compile, etc.. - could use std serial device - could use vga (needs mmio space) - - would like to add nested svm and (more important) nested vmx - small bit to copy l1 to l2 state, to make guest nested - need framework, can then require nested patches come w/ regression tests - current testsuite failing on qemu (shows softmmu issues, any takers?) fw_cfg issues - mostly on list - concerns about dma interface (too close to use case specific hack) - rep could be optimized in general - each byte == function call - possible pull in 4k (instead of 1k) on each exit - bar for changes should be no new interfaces