From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Mvtxa-0007Qx-1T for qemu-devel@nongnu.org; Thu, 08 Oct 2009 10:27:14 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MvtxU-0007PE-G5 for qemu-devel@nongnu.org; Thu, 08 Oct 2009 10:27:12 -0400 Received: from [199.232.76.173] (port=46071 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MvtxU-0007P5-9O for qemu-devel@nongnu.org; Thu, 08 Oct 2009 10:27:08 -0400 Received: from fg-out-1718.google.com ([72.14.220.156]:45926) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MvtxT-0007kv-Nm for qemu-devel@nongnu.org; Thu, 08 Oct 2009 10:27:07 -0400 Received: by fg-out-1718.google.com with SMTP id e21so1139900fga.10 for ; Thu, 08 Oct 2009 07:27:06 -0700 (PDT) Message-ID: <4ACDF69B.5000000@codemonkey.ws> Date: Thu, 08 Oct 2009 09:26:35 -0500 From: Anthony Liguori 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> In-Reply-To: <4ACDF297.9010303@redhat.com> 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: Avi Kivity Cc: Anthony Liguori , Glauber Costa , kvm-devel , qemu-devel@nongnu.org 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. 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. Regards, Anthony Liguori