From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:46529) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RXDk4-0003pm-Bw for qemu-devel@nongnu.org; Sun, 04 Dec 2011 10:12:37 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RXDk3-0008NV-5K for qemu-devel@nongnu.org; Sun, 04 Dec 2011 10:12:36 -0500 Received: from mx1.redhat.com ([209.132.183.28]:37049) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RXDk2-0008NP-Sa for qemu-devel@nongnu.org; Sun, 04 Dec 2011 10:12:35 -0500 Message-ID: <4EDB8DDE.5040402@redhat.com> Date: Sun, 04 Dec 2011 17:12:30 +0200 From: Avi Kivity MIME-Version: 1.0 References: <4EDB762C.7090909@redhat.com> <4EDB78DE.6000109@web.de> <4EDB7A74.4060804@redhat.com> <4EDB7ADC.50906@web.de> <4EDB7DE2.2050301@redhat.com> <4EDB7E62.7090909@web.de> In-Reply-To: <4EDB7E62.7090909@web.de> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [RFC][PATCH 14/16] kvm: x86: Add user space part for in-kernel i8259 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jan Kiszka Cc: Anthony Liguori , kvm@vger.kernel.org, "Michael S. Tsirkin" , Marcelo Tosatti , qemu-devel , Blue Swirl On 12/04/2011 04:06 PM, Jan Kiszka wrote: > On 2011-12-04 15:04, Avi Kivity wrote: > > On 12/04/2011 03:51 PM, Jan Kiszka wrote: > >>> > >>> But the name becomes part of the save/restore ABI, so you can't. > >> > >> Nope, the vmstate names are identical. That would ruin migration > >> otherwise. It's just the output of info qtree & co. that changes. > > > > Oh, okay. I still think it's wrong, but now it's just a matter of > > taste, and I can live with it. > > Wrong in what sense? In the sense that kernel-apic is just an accelerated apic. From the guest point of view, there's no difference, and that should be reflected in the device model. If I'm reading an apic register, either from the guest or via a monitor debug interface, I shouldn't care whether it's accelerated or not. The guest part already holds, of course. > I think the way of merging kvm support into the user space models in > qemu-kvm is not particularly beautiful. But that's my taste, and > therefore I modeled the upstream proposal differently. :) Oh, qemu-kvm was not meant to be an example of engineering elegance, just minimal changes. -- error compiling committee.c: too many arguments to function