From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [RFC][PATCH 14/16] kvm: x86: Add user space part for in-kernel i8259 Date: Mon, 05 Dec 2011 15:36:27 +0200 Message-ID: <4EDCC8DB.7040306@redhat.com> References: <4EDB762C.7090909@redhat.com> <4EDB78DE.6000109@web.de> <4EDB7A74.4060804@redhat.com> <4EDB7ADC.50906@web.de> <4EDB7DE2.2050301@redhat.com> <4EDB7E62.7090909@web.de> <4EDB8DDE.5040402@redhat.com> <4EDB8F7C.1070602@web.de> <4EDBA15E.3060309@redhat.com> <4EDBE865.6000907@web.de> <4EDC9680.2070305@redhat.com> <4EDCAD01.2010608@web.de> <4EDCBAB8.10307@redhat.com> <4EDCBD66.6010100@siemens.com> <4EDCC3B8.9020203@redhat.com> <4EDCC725.7090808@siemens.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Anthony Liguori , kvm@vger.kernel.org, "Michael S. Tsirkin" , Marcelo Tosatti , qemu-devel , Blue Swirl To: Jan Kiszka Return-path: In-Reply-To: <4EDCC725.7090808@siemens.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: qemu-devel-bounces+gceq-qemu-devel=gmane.org@nongnu.org Sender: qemu-devel-bounces+gceq-qemu-devel=gmane.org@nongnu.org List-Id: kvm.vger.kernel.org On 12/05/2011 03:29 PM, Jan Kiszka wrote: > On 2011-12-05 14:14, Avi Kivity wrote: > > On 12/05/2011 02:47 PM, Jan Kiszka wrote: > >>> > >>> (the memory API added unstable names, hopefully the QOM can take over > >>> the stable ones and we'll have a good way to denote the unstable ones). > >>> > >> > >> OK, maybe - or likely - we should make those device models have the same > >> names in QOM once instantiated. But I'm still convinced they should > >> remain separated models in contrast to a single model with a property. > > > > What do you mean by separate models? You share all the code you can, > > and don't share the code you can't. To me, single model == single name. > > But different configuration. Right, just like IDE with different backends. > > > >> The kvm ioapic, e.g., requires an additional property (gsi_base) that is > >> meaningless for user space devices. And its interrupts have to be > >> wired&configured differently at board model level. So, from the QEMU > >> POV, it is a very different device. Just the guest does not notice. > > > > It's like qcow2 and raw/native IO are wire differently, or virtio-net > > and vhost-net. But it's the same IDE device or virtio NIC. > > That would mean introducing a backend/frontend concept for irqchips. We could do it, have one ioapic model with ioapic_ops->eoi_broadcast(). Most of the interfaces already dispatch dynamically (qdev gpio/irq) so there wouldn't be much more there. To me, how it's actually implemented is not important. What is important is that save/restore, the monitor, and the guest don't notice any changes. -- error compiling committee.c: too many arguments to function From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:46713) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RXYim-0006WA-8v for qemu-devel@nongnu.org; Mon, 05 Dec 2011 08:36:44 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RXYif-0008Eu-0c for qemu-devel@nongnu.org; Mon, 05 Dec 2011 08:36:40 -0500 Received: from mx1.redhat.com ([209.132.183.28]:14532) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RXYie-0008Di-NW for qemu-devel@nongnu.org; Mon, 05 Dec 2011 08:36:32 -0500 Message-ID: <4EDCC8DB.7040306@redhat.com> Date: Mon, 05 Dec 2011 15:36:27 +0200 From: Avi Kivity MIME-Version: 1.0 References: <4EDB762C.7090909@redhat.com> <4EDB78DE.6000109@web.de> <4EDB7A74.4060804@redhat.com> <4EDB7ADC.50906@web.de> <4EDB7DE2.2050301@redhat.com> <4EDB7E62.7090909@web.de> <4EDB8DDE.5040402@redhat.com> <4EDB8F7C.1070602@web.de> <4EDBA15E.3060309@redhat.com> <4EDBE865.6000907@web.de> <4EDC9680.2070305@redhat.com> <4EDCAD01.2010608@web.de> <4EDCBAB8.10307@redhat.com> <4EDCBD66.6010100@siemens.com> <4EDCC3B8.9020203@redhat.com> <4EDCC725.7090808@siemens.com> In-Reply-To: <4EDCC725.7090808@siemens.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [RFC][PATCH 14/16] kvm: x86: Add user space part for in-kernel i8259 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jan Kiszka Cc: Anthony Liguori , kvm@vger.kernel.org, "Michael S. Tsirkin" , Marcelo Tosatti , qemu-devel , Blue Swirl On 12/05/2011 03:29 PM, Jan Kiszka wrote: > On 2011-12-05 14:14, Avi Kivity wrote: > > On 12/05/2011 02:47 PM, Jan Kiszka wrote: > >>> > >>> (the memory API added unstable names, hopefully the QOM can take over > >>> the stable ones and we'll have a good way to denote the unstable ones). > >>> > >> > >> OK, maybe - or likely - we should make those device models have the same > >> names in QOM once instantiated. But I'm still convinced they should > >> remain separated models in contrast to a single model with a property. > > > > What do you mean by separate models? You share all the code you can, > > and don't share the code you can't. To me, single model == single name. > > But different configuration. Right, just like IDE with different backends. > > > >> The kvm ioapic, e.g., requires an additional property (gsi_base) that is > >> meaningless for user space devices. And its interrupts have to be > >> wired&configured differently at board model level. So, from the QEMU > >> POV, it is a very different device. Just the guest does not notice. > > > > It's like qcow2 and raw/native IO are wire differently, or virtio-net > > and vhost-net. But it's the same IDE device or virtio NIC. > > That would mean introducing a backend/frontend concept for irqchips. We could do it, have one ioapic model with ioapic_ops->eoi_broadcast(). Most of the interfaces already dispatch dynamically (qdev gpio/irq) so there wouldn't be much more there. To me, how it's actually implemented is not important. What is important is that save/restore, the monitor, and the guest don't notice any changes. -- error compiling committee.c: too many arguments to function