From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MvvsS-0008JA-Jj for qemu-devel@nongnu.org; Thu, 08 Oct 2009 12:30:05 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MvvsM-0008Cb-BQ for qemu-devel@nongnu.org; Thu, 08 Oct 2009 12:30:02 -0400 Received: from [199.232.76.173] (port=40259 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MvvsK-0008BP-N5 for qemu-devel@nongnu.org; Thu, 08 Oct 2009 12:29:58 -0400 Received: from mx1.redhat.com ([209.132.183.28]:64875) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MvvsK-0008Gp-5r for qemu-devel@nongnu.org; Thu, 08 Oct 2009 12:29:56 -0400 Message-ID: <4ACE1381.3020804@redhat.com> Date: Thu, 08 Oct 2009 18:29:53 +0200 From: Avi Kivity MIME-Version: 1.0 Subject: Re: [Qemu-devel] Re: [PATCH v2 3/9] provide in-kernel ioapic 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> <4ACDEDEC.60706@us.ibm.com> <4ACDEF03.6010406@redhat.com> <20091008160726.GD29691@shareable.org> <4ACE10B5.3080509@redhat.com> <20091008162248.GK16702@redhat.com> In-Reply-To: <20091008162248.GK16702@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: Gleb Natapov Cc: Anthony Liguori , Glauber Costa , kvm-devel , qemu-devel@nongnu.org On 10/08/2009 06:22 PM, Gleb Natapov wrote: > On Thu, Oct 08, 2009 at 06:17:57PM +0200, Avi Kivity wrote: > >> On 10/08/2009 06:07 PM, Jamie Lokier wrote: >> >>> Haven't we already confirmed that it *isn't* just an ioapic accelerator >>> because you can't migrate between in-kernel iopic and qemu's ioapic? >>> >> We haven't confirmed it. Both implement the same spec, and if you >> can't migrate between them, one of them has a bug (for example, qemu >> ioapic doesn't implement polarity - but it's still just a bug). >> >> > Are you saying that HW spec (that only describes software visible behavior) > completely defines implementation? No other internal state is needed > that may be done differently by different implementations? > It may be done differently (for example, selecting the cpu to deliver the interrupt to), but as the guest cannot rely on the differences, there's no need to save the state that can cause these differences. -- error compiling committee.c: too many arguments to function