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 13:47:34 +0100 Message-ID: <4EDCBD66.6010100@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> 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: In-Reply-To: <4EDCBAB8.10307@redhat.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 2011-12-05 13:36, Avi Kivity wrote: > On 12/05/2011 01:37 PM, Jan Kiszka wrote: >> On 2011-12-05 11:01, Avi Kivity wrote: >>> On 12/04/2011 11:38 PM, Jan Kiszka wrote: >>>>> >>>>> It should be also possible to migrate from non-KVM device to KVM >>>>> version, different names would prevent that for ever. >>>> >>>> It is (theoretically) possible with these patches as the vmstate names >>>> are the same. KVM to TCG migration does not work right now, so I was >>>> only able to test in-kernel <-> user space irqchip model migrations. >>> >>> btw, for the next-gen migration protocol, we'd probably be using QOM >>> paths, not vmstate names; the QOM paths would include the device name? >> >> That would be a very bad idea IMHO. Every refactoring of your device >> tree, e.g. to model CPU hotplug and the ICC bus more accurately, would >> risk to create a migration crack. > > At some point, something has to be stable. We can't have an infinite > number of layers giving names to things. I propose we have just one layer. > >> At least we would need some stable >> naming and/or alias concept then. > > We should be able to transform a path to backward compatible names, > yes. But if something has an unstable name, let's omit it in the first > place. > > (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. 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. Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux