From mboxrd@z Thu Jan  1 00:00:00 1970
From: Jamie Lokier <jamie@shareable.org>
Subject: Re: [Qemu-devel] Re: [PATCH v2 3/9] provide in-kernel ioapic
Date: Fri, 9 Oct 2009 17:49:55 +0100
Message-ID: <20091009164955.GC7393@shareable.org>
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> <20091009143225.GV8092@mothafucka.localdomain>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Cc: Gleb Natapov <gleb@redhat.com>, Avi Kivity <avi@redhat.com>,
	Anthony Liguori <aliguori@us.ibm.com>, qemu-devel@nongnu.org,
	kvm-devel <kvm@vger.kernel.org>
To: Glauber Costa <glommer@redhat.com>
Return-path: <kvm-owner@vger.kernel.org>
Received: from mail2.shareable.org ([80.68.89.115]:34144 "EHLO
	mail2.shareable.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S1750966AbZJIQuo (ORCPT <rfc822;kvm@vger.kernel.org>);
	Fri, 9 Oct 2009 12:50:44 -0400
Content-Disposition: inline
In-Reply-To: <20091009143225.GV8092@mothafucka.localdomain>
Sender: kvm-owner@vger.kernel.org
List-ID: <kvm.vger.kernel.org>

Glauber Costa wrote:
> On Thu, Oct 08, 2009 at 06:22:48PM +0200, 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?
> Most specifications leaves a lot as implementation specific.
> 
> It's not hard to imagine a case in which both devices will follow
> the spec correctly, (no bugs involved), and yet differ in the
> implementation.

Avi's not saying the implementations won't differ.  I believe he's
saying that implementation-specific states don't need to be saved if
they have no effect on guest visible behaviour.

-- Jamie