From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [PATCH v2 00/17] [uq/master] Prepare for more qemu-kvm merging Date: Mon, 03 Jan 2011 18:09:33 +0200 Message-ID: <4D21F4BD.8040708@redhat.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Marcelo Tosatti , kvm@vger.kernel.org, qemu-devel@nongnu.org To: Jan Kiszka Return-path: Received: from mx1.redhat.com ([209.132.183.28]:52211 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932112Ab1ACQJh (ORCPT ); Mon, 3 Jan 2011 11:09:37 -0500 In-Reply-To: Sender: kvm-owner@vger.kernel.org List-ID: On 01/03/2011 10:32 AM, Jan Kiszka wrote: > All previously sent patches against current uq combined, some smaller > tweaks applied, and 4 new patches added. Major news is support for > using up to 16M BIOSes and optional code dump for cpu_dump_state. Those > features are already present qemu-kvm but were reworked to provide > cleaner upstream versions. > Looks reasonable overall. > Based on this series, I've an experimental tree here where I eliminated > another 1500 LOC from qemu-kvm code. Specifically, that tree sets an end > to duplicate KVM and VCPU initialization functions, KVMState copies, and > redundant state saving/loading functions. Will be rolled out after some > more review and testing. Sounds really frightening... this glue code is a real breeding ground for subtle bugs and merge problems. -- error compiling committee.c: too many arguments to function