From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jamie Lokier Subject: Re: Configuration vs. compat hints [was Re: [Qemu-devel] [PATCHv3 03/13] qemu: add routines to manage PCI capabilities] Date: Wed, 17 Jun 2009 12:58:41 +0100 Message-ID: <20090617115841.GD27947@shareable.org> References: <1245083229.3222.103.camel@blaa> <4A368F12.2090504@codemonkey.ws> <1245154451.11407.22.camel@blaa> <4A378FE5.5050303@redhat.com> <1245155992.30082.8.camel@blaa> <20090616184404.GJ11893@shareable.org> <1245227632.27028.29.camel@blaa> <4A38B147.1030207@redhat.com> <1245230283.27028.36.camel@blaa> <4A38B6CF.6000503@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Mark McLoughlin , Carsten Otte , dlaor@redhat.com, kvm@vger.kernel.org, "Michael S. Tsirkin" , Glauber Costa , Rusty Russell , qemu-devel@nongnu.org, virtualization@lists.linux-foundation.org, Blue Swirl , Christian Borntraeger , Paul Brook To: Avi Kivity Return-path: Received: from mail2.shareable.org ([80.68.89.115]:53426 "EHLO mail2.shareable.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933253AbZFQL6i (ORCPT ); Wed, 17 Jun 2009 07:58:38 -0400 Content-Disposition: inline In-Reply-To: <4A38B6CF.6000503@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: Avi Kivity wrote: > >If management apps need to hard-code which slots are available on > >different targets and different qemu versions, or restrictions on which > >devices can use which slots, or knowledge that some devices can be > >multi-function, or ... anything like that is just lame. > > > > You can't abstract these things away. If you can't put a NIC in slot 4, > and you have 7 slots, then you cannot have 7 NICs. Having qemu allocate > the slot numbers does not absolve management from knowing this > limitation and preventing the user from creating a machine with 7 slots. > > Likewise, management will have to know which devices are multi-function, > since that affects their hotpluggability. Ditto if some slot if faster > than others, if you want to make use of this information you have to let > the upper layers know. > > It could be done using an elaborate machine description that qemu > exposes to management coupled with a constraint solver that optimizes > the machine layout according to user specifications and hardware > limitations. Or we could take the view that real life is not perfect > (especially where computers are involved), add some machine specific > knowledge, and spend the rest of the summer at the beach. To be honest, an elaborate machine description is probably fine... A fancy constraint solver is not required. A simple one strikes me as about as simple as what you'd hard-code anyway, but with fewer special cases. Note that the result can fail due to things like insufficient address space for all the device BARs even when they _are_ in the right slots. Especially if there are lots of slots, or bridges which can provide unlimited slots. That is arcane: device-dependent, CPU-dependent, machine-dependent, RAM-size dependent (in a non-linear way), device-option-dependent and probably QEMU-version-dependent too. It would be nice if libvirt (et al) would prevent the user from creating a VM with insufficient BAR space for that machine, but I'm not sure how to do it sanely, without arcane knowledge getting about. Maybe that idea of a .so shared by qemu and libvirt, to manipulate device configurations, is a sane one after all. -- Jamie