From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:35354)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <pbonzini@redhat.com>) id 1VW49E-0002YI-9J
	for qemu-devel@nongnu.org; Tue, 15 Oct 2013 08:54:58 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <pbonzini@redhat.com>) id 1VW496-0002T2-6N
	for qemu-devel@nongnu.org; Tue, 15 Oct 2013 08:54:52 -0400
Received: from mx1.redhat.com ([209.132.183.28]:25747)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <pbonzini@redhat.com>) id 1VW495-0002Su-UR
	for qemu-devel@nongnu.org; Tue, 15 Oct 2013 08:54:44 -0400
Message-ID: <525D3B0E.9040304@redhat.com>
Date: Tue, 15 Oct 2013 14:54:38 +0200
From: Paolo Bonzini <pbonzini@redhat.com>
MIME-Version: 1.0
References: <1381416174-5110-1-git-send-email-armbru@redhat.com>
	<1381416174-5110-9-git-send-email-armbru@redhat.com>
	<87wqlehfg9.fsf_-_@blackfin.pond.sub.org>
In-Reply-To: <87wqlehfg9.fsf_-_@blackfin.pond.sub.org>
Content-Type: text/plain; charset=ISO-8859-15
Content-Transfer-Encoding: 7bit
Subject: Re: [Qemu-devel] Should the i8259 devices remain no-user?
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Markus Armbruster <armbru@redhat.com>
Cc: qemu-devel@nongnu.org, Anthony Liguori <aliguori@amazon.com>, =?ISO-8859-15?Q?Andreas_F=E4rber?= <afaerber@suse.de>

Il 15/10/2013 14:43, Markus Armbruster ha scritto:
> Paolo, or maybe Andreas,
> 
> To go beyond RFC with this series, I need to explain why isa-i8259 and
> kvm-i8259 cannot_instantiate_with_device_add_yet, or drop that.  I'd
> appreciate your help.
> 
> Both are derived from TYPE_PIC_COMMON, which is derived from
> TYPE_ISA_DEVICE.
> 
> I figure isa-i8259 cannot_instantiate_with_device_add_yet, because it
> sets global isa_pic and slave_pic.  slave_pic appears to be a lame way
> to wire the slave PIC to the master PIC behind QOM's back.  isa_pic
> appears to be a lame way to wire the master PIC to whatever it needs to
> be wired to.  Is that a fair description?

Yes.

> If yes, is it sufficient reason for
> cannot_instantiate_with_device_add_yet?
> 
> kvm-i8259 is the same device implemented with kernel support.  Does it
> have its own reason for cannot_instantiate_with_device_add_yet?
> 
> If not, should it keep cannot_instantiate_with_device_add_yet for
> symmetry with isa-i8259?

Both i8259 implementations have to be matched with an appropriate array
of qemu_irqs, such as the one returned by kvm_i8259_init.  I think this
is the reason why kvm-i8259 cannot be instantiated from the command-line.

Paolo