From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MGGfn-00025Q-Ko for qemu-devel@nongnu.org; Mon, 15 Jun 2009 14:12:47 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MGGfi-00023v-24 for qemu-devel@nongnu.org; Mon, 15 Jun 2009 14:12:46 -0400 Received: from [199.232.76.173] (port=46296 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MGGfh-00023s-UW for qemu-devel@nongnu.org; Mon, 15 Jun 2009 14:12:41 -0400 Received: from qw-out-1920.google.com ([74.125.92.146]:50204) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MGGfh-0007wB-Li for qemu-devel@nongnu.org; Mon, 15 Jun 2009 14:12:41 -0400 Received: by qw-out-1920.google.com with SMTP id 4so1896013qwk.4 for ; Mon, 15 Jun 2009 11:12:40 -0700 (PDT) Message-ID: <4A368F12.2090504@codemonkey.ws> Date: Mon, 15 Jun 2009 13:12:34 -0500 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: Configuration vs. compat hints [was Re: [Qemu-devel] [PATCHv3 03/13] qemu: add routines to manage PCI capabilities] References: <1244821292.30522.56.camel@blaa> <4A327E4A.7010300@codemonkey.ws> <1244825303.26769.19.camel@blaa> <20090614095016.GA7560@redhat.com> <1245056916.6891.31.camel@blaa> <4A3613EC.6030608@redhat.com> <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> In-Reply-To: <1245083229.3222.103.camel@blaa> 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: Mark McLoughlin Cc: 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 , Avi Kivity , Paul Brook Mark McLoughlin wrote: > So long as the restrictions would be known to the management app via > some "what slots are available" mechanism in qemu, that sounds fine. > I'm not sure a "what slots are available" mechanism is as straight forward as has been claimed. It doesn't matter though because it's orthogonal to the current proposal. >>> I'm not at all arguing against pci_addr. I'm arguing about how >>> libvirt should use it with respect to the "genesis" use-case where >>> libvirt has no specific reason to choose one PCI slot over another. >>> In that case, I'm merely advocating that we want to let QEMU make the >>> decision. >>> >> However this may end up, isn't it offtopic? Whatever we do we have to >> support both pci_addr= and default placement, so we can push this >> discussion to livirt-devel and bid them godspeed. >> > > Presumably you're not proposing that qemu-devel completely ignore the > typical requirements of management apps? > This is a happy case where the current proposals allow both usages to occur. Which one libvirt chooses it up to it. To summarize, I think we have: 1) Introduce addressing to all host device configurations - Either in the canonical form "pci_addr=bus:dev.fn or target=3,lun=1" or in flattened form "addr=bus:dev.fn or addr=target.lun". I prefer the later form but I think either would be acceptable. 2) Whenever the default machine type changes in a guest-visible way, introduce a new machine type - Use explicit versions in name: pc-v1, pc-v2 or use more descriptive names pc-with-usb - Easily transitions to device config files Regards, Anthony Liguori