From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Mvvwt-0002tB-GK for qemu-devel@nongnu.org; Thu, 08 Oct 2009 12:34:39 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Mvvwo-0002s1-TY for qemu-devel@nongnu.org; Thu, 08 Oct 2009 12:34:39 -0400 Received: from [199.232.76.173] (port=41648 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Mvvwo-0002rw-Ms for qemu-devel@nongnu.org; Thu, 08 Oct 2009 12:34:34 -0400 Received: from mx1.redhat.com ([209.132.183.28]:41545) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Mvvwo-0000Zn-6c for qemu-devel@nongnu.org; Thu, 08 Oct 2009 12:34:34 -0400 Date: Thu, 8 Oct 2009 18:34:31 +0200 From: Gleb Natapov Subject: Re: [Qemu-devel] Re: [PATCH v2 3/9] provide in-kernel ioapic Message-ID: <20091008163431.GM16702@redhat.com> 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> <4ACE1381.3020804@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4ACE1381.3020804@redhat.com> 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 On Thu, Oct 08, 2009 at 06:29:53PM +0200, Avi Kivity wrote: > 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. > So suppose I have simple watchdog device that required to be poked every second, otherwise it resets a computer. On migration we have to migrate time elapsed since last poke, but if device doesn't expose it to software in any way you are saying we can recreate is some other way? -- Gleb.