From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jan Kiszka Subject: Re: [RFC][PATCH 14/16] kvm: x86: Add user space part for in-kernel i8259 Date: Mon, 05 Dec 2011 14:55:51 +0100 Message-ID: <4EDCCD67.3040105@siemens.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> <4EDCC8DB.7040306@redhat.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: Avi Kivity Return-path: Received: from david.siemens.de ([192.35.17.14]:24220 "EHLO david.siemens.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932151Ab1LEN4D (ORCPT ); Mon, 5 Dec 2011 08:56:03 -0500 In-Reply-To: <4EDCC8DB.7040306@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: On 2011-12-05 14:36, Avi Kivity wrote: > 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. Except that there is a comparably large infrastructure to manage those 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. The problem is configuration. Just by setting ioapic.backend=xxx, we cannot pass down parameters that are backend-specific. We could ignore this issue and make all specific parameters visible via the frontend. Would be slightly ugly. > > 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. I widely agree, except that differentiation (or backend awareness) has to be preserved in the monitor. Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux