From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Mvu2J-0000o1-JK for qemu-devel@nongnu.org; Thu, 08 Oct 2009 10:32:07 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Mvu2E-0000m4-V3 for qemu-devel@nongnu.org; Thu, 08 Oct 2009 10:32:07 -0400 Received: from [199.232.76.173] (port=35355 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Mvu2E-0000m1-Qe for qemu-devel@nongnu.org; Thu, 08 Oct 2009 10:32:02 -0400 Received: from mx1.redhat.com ([209.132.183.28]:61873) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Mvu2E-0000Yh-8F for qemu-devel@nongnu.org; Thu, 08 Oct 2009 10:32:02 -0400 Message-ID: <4ACDF7DD.1010803@redhat.com> Date: Thu, 08 Oct 2009 16:31:57 +0200 From: Avi Kivity MIME-Version: 1.0 Subject: Re: [Qemu-devel] Re: [PATCH v2 4/9] provide in-kernel apic References: <1254953315-5761-1-git-send-email-glommer@redhat.com> <1254953315-5761-2-git-send-email-glommer@redhat.com> <1254953315-5761-3-git-send-email-glommer@redhat.com> <1254953315-5761-4-git-send-email-glommer@redhat.com> <1254953315-5761-5-git-send-email-glommer@redhat.com> <4ACDEF42.6020706@us.ibm.com> <4ACDF297.9010303@redhat.com> <4ACDF69B.5000000@codemonkey.ws> In-Reply-To: <4ACDF69B.5000000@codemonkey.ws> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: Anthony Liguori , Glauber Costa , kvm-devel , qemu-devel@nongnu.org On 10/08/2009 04:26 PM, Anthony Liguori wrote: > Avi Kivity wrote: >> On 10/08/2009 03:55 PM, Anthony Liguori wrote: >>> >>> You should probably just setup VMState such that it directly saves >>> kvm_lapic_state and then have the pre/post functions call the kernel >>> ioctls to sync it. There's not a whole lot of point switching the >>> state between two different structures. >> >> It ensures the two models are compatible. Since they're the same >> device from the point of view of the guest, there's no reason for >> them to have different representations or to be incompatible. > > The problem is, the in-kernel apic is not part of the qemu source > tree. If we add a field to the qemu apic, then we would break the > in-kernel apic and vice-versa. It's far easier to just have the > in-kernel apic as a separate model. > You need to handle it anyway due to save/restore; that is the new field and whatever functionality it has must be optional. > Most importantly though, the code should reflect how things behave. > It's extremely difficult to look at the apic code and figure out what > bits are used and what bits aren't used when the in-kernel apic is > enabled. That doesn't mean they need to be separate devices. -- error compiling committee.c: too many arguments to function