From mboxrd@z Thu Jan 1 00:00:00 1970 From: Anthony Liguori Subject: Re: [Qemu-devel] KVM call minutes for Feb 8 Date: Wed, 09 Feb 2011 04:43:33 -0600 Message-ID: <4D526FD5.2090404@codemonkey.ws> References: <20110208155557.GM6198@x200.localdomain> <20110208193033.GG16429@hall.aurel32.net> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Cc: Markus Armbruster , Chris Wright , qemu-devel@nongnu.org, kvm@vger.kernel.org To: Aurelien Jarno Return-path: Received: from mail-ww0-f44.google.com ([74.125.82.44]:50228 "EHLO mail-ww0-f44.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754207Ab1BIKoz (ORCPT ); Wed, 9 Feb 2011 05:44:55 -0500 Received: by wwa36 with SMTP id 36so23644wwa.1 for ; Wed, 09 Feb 2011 02:44:54 -0800 (PST) In-Reply-To: <20110208193033.GG16429@hall.aurel32.net> Sender: kvm-owner@vger.kernel.org List-ID: On 02/08/2011 01:30 PM, Aurelien Jarno wrote: > On Tue, Feb 08, 2011 at 06:13:53PM +0100, Markus Armbruster wrote: > >> Chris Wright writes: >> >> [...] >> >>> - qdev/vmstate both examples of partially completed work that need more >>> attention >>> >> As far as qdev's concerned, I can see two kinds of to-dos: >> >> * Further develop qdev so that more of the machine init code can becomes >> qdev declarations. Specific ideas welcome. Patches even more, as >> always. >> >> * Convert the remaining devices. They are typically used only with >> oddball machines, which makes the conversion hard to test for anyone >> who's not already using them. >> >> I've said this before: at some point in time (sooner rather than >> later, if you ask me), we need to shoot the stragglers. I'm pretty >> optimistic that any victims worth keeping will receive timely >> attention then. >> >> > For those oddball machines, qdev doesn't really bring anything, that's > why there is so little interest in converting them, and why I prefer to > spend my time on the emulation correctness than converting those > remaining to qdev. Of course I agree it's something to do, and with an > unlimited amount of free time, I'll do them immediately. > > Let's take for example the SH4 target. It's nice to be able to create > the whole machine from a script, except your kernel won't boot if the > machine: > - has a different cpu > - doesn't a SM501 chipset > - has not the correct memory size > - doesn't have 2 serial port > qdev needs a v2. The object model is very difficult to work with and it offers little value for the scenario you describe. A SoC should be modelled as a single object with parameters that can be set. That object will then have other objects embedded through it with composition or reference. So for instance, you might have: class SH4 { SH4CPU cpu[n_vcpus]; SM501 chipset; }; class SM501 : public PCIHostController { PCIDevice *slots[32]; }; Having a script where you describe this is wrong. This ought to be an object. For instance, what we really ought to have on x86 is: qemu -no-machine -device i440fx,id=root -device rtl8139,bus=/root/pci.0,addr=1.0 -device cpu,chipset=/root Part of the problem with qdev v1 is that it doesn't allow for meaningful object composition. The only relationship between devices is through BusState which presents a hierarchical parent/child relationship. We really need a way to do composition and referencing. For instance, if you notice above, SM501 has 32 references to a PCIDevice as opposed to having a linked list of children. The effect is that a PCIDevice does not have the PCIHostController as it's "parent" because there's no intrinsic parent/child hierarchy. So really, we're talking about a device graph here instead of a tree. Regards, Anthony Liguori > That basically only leaves the PCI and USB devices configurable, but > those are already using qdev. > > From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=44898 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Pn7Xc-0001zj-Nc for qemu-devel@nongnu.org; Wed, 09 Feb 2011 05:44:57 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Pn7Xb-0000gp-9X for qemu-devel@nongnu.org; Wed, 09 Feb 2011 05:44:56 -0500 Received: from mail-ww0-f53.google.com ([74.125.82.53]:52430) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Pn7Xb-0000gV-3n for qemu-devel@nongnu.org; Wed, 09 Feb 2011 05:44:55 -0500 Received: by wwi18 with SMTP id 18so19103wwi.10 for ; Wed, 09 Feb 2011 02:44:54 -0800 (PST) Message-ID: <4D526FD5.2090404@codemonkey.ws> Date: Wed, 09 Feb 2011 04:43:33 -0600 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] KVM call minutes for Feb 8 References: <20110208155557.GM6198@x200.localdomain> <20110208193033.GG16429@hall.aurel32.net> In-Reply-To: <20110208193033.GG16429@hall.aurel32.net> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Aurelien Jarno Cc: Chris Wright , Markus Armbruster , kvm@vger.kernel.org, qemu-devel@nongnu.org On 02/08/2011 01:30 PM, Aurelien Jarno wrote: > On Tue, Feb 08, 2011 at 06:13:53PM +0100, Markus Armbruster wrote: > >> Chris Wright writes: >> >> [...] >> >>> - qdev/vmstate both examples of partially completed work that need more >>> attention >>> >> As far as qdev's concerned, I can see two kinds of to-dos: >> >> * Further develop qdev so that more of the machine init code can becomes >> qdev declarations. Specific ideas welcome. Patches even more, as >> always. >> >> * Convert the remaining devices. They are typically used only with >> oddball machines, which makes the conversion hard to test for anyone >> who's not already using them. >> >> I've said this before: at some point in time (sooner rather than >> later, if you ask me), we need to shoot the stragglers. I'm pretty >> optimistic that any victims worth keeping will receive timely >> attention then. >> >> > For those oddball machines, qdev doesn't really bring anything, that's > why there is so little interest in converting them, and why I prefer to > spend my time on the emulation correctness than converting those > remaining to qdev. Of course I agree it's something to do, and with an > unlimited amount of free time, I'll do them immediately. > > Let's take for example the SH4 target. It's nice to be able to create > the whole machine from a script, except your kernel won't boot if the > machine: > - has a different cpu > - doesn't a SM501 chipset > - has not the correct memory size > - doesn't have 2 serial port > qdev needs a v2. The object model is very difficult to work with and it offers little value for the scenario you describe. A SoC should be modelled as a single object with parameters that can be set. That object will then have other objects embedded through it with composition or reference. So for instance, you might have: class SH4 { SH4CPU cpu[n_vcpus]; SM501 chipset; }; class SM501 : public PCIHostController { PCIDevice *slots[32]; }; Having a script where you describe this is wrong. This ought to be an object. For instance, what we really ought to have on x86 is: qemu -no-machine -device i440fx,id=root -device rtl8139,bus=/root/pci.0,addr=1.0 -device cpu,chipset=/root Part of the problem with qdev v1 is that it doesn't allow for meaningful object composition. The only relationship between devices is through BusState which presents a hierarchical parent/child relationship. We really need a way to do composition and referencing. For instance, if you notice above, SM501 has 32 references to a PCIDevice as opposed to having a linked list of children. The effect is that a PCIDevice does not have the PCIHostController as it's "parent" because there's no intrinsic parent/child hierarchy. So really, we're talking about a device graph here instead of a tree. Regards, Anthony Liguori > That basically only leaves the PCI and USB devices configurable, but > those are already using qdev. > >