From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Nu3a6-0001xp-69 for qemu-devel@nongnu.org; Tue, 23 Mar 2010 08:51:38 -0400 Received: from [199.232.76.173] (port=53250 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Nu3a5-0001xK-D2 for qemu-devel@nongnu.org; Tue, 23 Mar 2010 08:51:37 -0400 Received: from Debian-exim by monty-python.gnu.org with spam-scanned (Exim 4.60) (envelope-from ) id 1Nu3a4-0004RR-Jg for qemu-devel@nongnu.org; Tue, 23 Mar 2010 08:51:37 -0400 Received: from mx1.redhat.com ([209.132.183.28]:41866) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Nu3a4-0004RJ-6b for qemu-devel@nongnu.org; Tue, 23 Mar 2010 08:51:36 -0400 Message-ID: <4BA8B954.8010907@redhat.com> Date: Tue, 23 Mar 2010 14:51:32 +0200 From: Avi Kivity MIME-Version: 1.0 References: <20100323061140.GN29498@x200.localdomain> <4BA88A6F.2050703@web.de> <4BA88F5D.6040008@redhat.com> <4BA8B7FB.2050103@codemonkey.ws> In-Reply-To: <4BA8B7FB.2050103@codemonkey.ws> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Subject: [Qemu-devel] Re: KVM call agenda for Mar 23 List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: Chris Wright , Jan Kiszka , qemu-devel@nongnu.org, kvm@vger.kernel.org On 03/23/2010 02:45 PM, Anthony Liguori wrote: > On 03/23/2010 04:52 AM, Avi Kivity wrote: >> On 03/23/2010 11:31 AM, Jan Kiszka wrote: >>> Chris Wright wrote: >>>> Please send in any agenda items you are interested in covering. >>>> >>>> Yes, usability is a valid topic esp. if you promise to come w/ GUI >>>> patches. >>>> >>> - state and roadmap for upstream merge of in-kernel device models >>> (looks to me like this central merge effort is stalled ATM) >> >> - alternative path of merging qemu-kvm.git's implementation as is and >> cleaning it up in qemu.git. >> >> For kvm.git, I wouldn't dream of merging something with outstanding >> issues and cleaning them up "later", but the situation is somewhat >> different with qemu vs qemu-kvm. > > I don't think we can pull in: > > - extboot > - ia64 > - in-kernel pit[1] > - associated command line options > - device passthrough I'm not proposing these for merge, except [1]. > The question is, if we dropped those things, would people actually use > qemu.git instead of qemu-kvm.git. If the answer is "no", what set of > things do we need in order for people to focus on qemu.git instead of > qemu-kvm.git. Device passthrough is sufficiently obscure that most people could use qemu.git (not distributions, though). ia64 is dead. Command line options would need to be cleaned up. We'd need an extboot replacement, people do boot from virtio. > > [1] I'd like to revisit this discussion. We originally went the > in-kernel pit route because of difficulties changing qemu. That's a > bad reason to put something in the kernel. I'd prefer to see us fix > qemu. After that, we can look at in-kernel pit and see if there are > any remaining advantages (like performance). If it's significant, we > can still merge in-kernel pit. The reason was drift compensation IIRC. Also, some guests read the time back from the PIT. Perhaps that's no longer the case with hpet enabled by default. Drift compensation can be done in qemu by exposing ack notifiers to userspace; that's also needed for rtc drift compensation for Windows. -- error compiling committee.c: too many arguments to function