From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MOoUU-0006uL-KZ for qemu-devel@nongnu.org; Thu, 09 Jul 2009 03:56:26 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MOoUQ-0006r6-QY for qemu-devel@nongnu.org; Thu, 09 Jul 2009 03:56:26 -0400 Received: from [199.232.76.173] (port=45101 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MOoUQ-0006qt-DD for qemu-devel@nongnu.org; Thu, 09 Jul 2009 03:56:22 -0400 Received: from mx2.redhat.com ([66.187.237.31]:56012) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MOoUP-00013j-F7 for qemu-devel@nongnu.org; Thu, 09 Jul 2009 03:56:21 -0400 Message-ID: <4A55A29A.9020202@redhat.com> Date: Thu, 09 Jul 2009 09:56:10 +0200 From: Gerd Hoffmann MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH 3/3 v2] Add a pc-0-10 machine type for compatibility with 0.10.x References: <1244821292.30522.56.camel@blaa> <20090615103249.GB6351@redhat.com> <4A363012.8050409@redhat.com> <20090615114858.GG6351@redhat.com> <4A3636FA.1040609@redhat.com> <20090615124101.GH6351@redhat.com> <4A364381.401@redhat.com> <4A364401.6010500@codemonkey.ws> <4A3647FB.9010808@redhat.com> <4A364B53.9080007@codemonkey.ws> <4A364FE0.40204@redhat.com> <4A3651EB.3070204@codemonkey.ws> <4A36555A.4090303@redhat.com> <4A3659A0.3050108@codemonkey.ws> <4A366348.1030202@redhat.com> <1245083229.3222.103.camel@blaa> <4A368F12.2090504@codemonkey.ws> <1246964898.2836.38.camel@blaa> <1246964950.2836.39.camel@blaa> <1246964998.2836.40.camel@blaa> <1246965054.2836.41.camel@blaa> <4A5338FC.9030301@redhat.com> <1247049984.3270.52.camel@blaa> <1247050083.3270.54.camel@blaa> <4A54986D.301@redhat.com> <4A54A2B0.6050605@codemonk! ey.ws> <4A54A895.5090501@redhat.com> <1247065728.3270.65.camel@blaa> <4A54EE87.2000508@redhat.com> <4A55136E.6050508@codemonkey.ws> In-Reply-To: <4A55136E.6050508@codemonkey.ws> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: Mark McLoughlin , Avi Kivity , qemu-devel@nongnu.org On 07/08/09 23:45, Anthony Liguori wrote: > Gerd Hoffmann wrote: >> On 07/08/09 17:08, Mark McLoughlin wrote: >>> On Wed, 2009-07-08 at 16:09 +0200, Gerd Hoffmann wrote: >>>>> /usr/share/qemu/configs/pc-0-10.dts >>>>> /usr/share/qemu/configs/pc-0-11.dts >>>>> /usr/share/qemu/configs/pc -> /usr/share/qemu/configs/pc-0-11.dts >>>> Doesn't work. Your virtio blk device isn't in there. >>> >>> Right - I had assumed Anthony meant that such a config file would also >>> have details on the defaults used for devices which can be added to that >>> machine. >> >> Could probably be done that way, but that wouldn't be different from a >> global compat variable where the virtio-block-pci driver looks at. >> We have different versions of devices. > > We have options that we can tweak for devices. That doesn't mean they're > versioned. What the default set of options that is turned on for any > given device is determined by the machine type (since the machine init > is what creates the devices to start with). The machine init doesn't create all devices. USB devices are created outside machine init today, and that will become more and more common. I expect long-term we will end up with one of these two models: (1) - machine init creates just the bare devices, i.e. what is there when you specify just '-M pc'. Either hardcoded or from machine config file. - generic code adds devices added by cmd line switches. (2) - command line switches insert additional devices into the bare (-M pc) device tree. - The virtual machine is created from that modified device tree. I both cases it is not clear how the machine init / machine config will handle the versioning of the devices added by command line switches. We could have each machine type register a list of default options. Using qdev properties that should be doable in a fairly generic way, like this: virtio-blk-pci and virtio-console-pci get a "class" property. virtio-net-pci gets a "msi" property. ide-disk+cdrom gets a "fw-version" property (well, not yet, when being converted to qdev). pc-0.10 could then register a list of default properties, i.e. something like "virtio-blk-pci" => "class=0x??" "virtio-console-pci" => "class=0x??" "virtio-net-pci => "msi=0" "ide-disk" => "fw-version=0.10.0" When creating devices qdev would apply them. I can prototype that. comments? Gerd