From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Mvu9S-0003qC-7Y for qemu-devel@nongnu.org; Thu, 08 Oct 2009 10:39:30 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Mvu9N-0003nt-O5 for qemu-devel@nongnu.org; Thu, 08 Oct 2009 10:39:29 -0400 Received: from [199.232.76.173] (port=44397 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Mvu9N-0003nn-Dy for qemu-devel@nongnu.org; Thu, 08 Oct 2009 10:39:25 -0400 Received: from mail-fx0-f214.google.com ([209.85.220.214]:44712) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Mvu9M-00026X-Td for qemu-devel@nongnu.org; Thu, 08 Oct 2009 10:39:25 -0400 Received: by fxm10 with SMTP id 10so5615309fxm.8 for ; Thu, 08 Oct 2009 07:39:23 -0700 (PDT) Message-ID: <4ACDF991.7030202@codemonkey.ws> Date: Thu, 08 Oct 2009 09:39:13 -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> <4ACDF69B.5000000@codemonkey.ws> <4ACDF7DD.1010803@redhat.com> In-Reply-To: <4ACDF7DD.1010803@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: Glauber Costa , qemu-devel@nongnu.org, kvm-devel Avi Kivity wrote: >> 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. Not necessarily. If it's a bug fix, we may disable the older versions of savevm (which we have to do from time to time). > That doesn't mean they need to be separate devices. But they are. The in-kernel device models are not mere accelerations. There are features that are only enabled with in-kernel device models (like PCI passthrough). In fact, in-kernel PIT is not at all an acceleration, it's there because it's functionally different. The sync stuff is really ugly too. It would be much cleaner to have a separate state for the in-kernel device models that saved the structures from the kernel directly instead of having to translate between formats. More straight forward code means it's all easier to understand, easier to debug, etc. Regards, Anthony Liguori