From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MGD72-0000vG-HF for qemu-devel@nongnu.org; Mon, 15 Jun 2009 10:24:40 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MGD6y-0000sR-S8 for qemu-devel@nongnu.org; Mon, 15 Jun 2009 10:24:40 -0400 Received: from [199.232.76.173] (port=32812 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MGD6y-0000s7-GO for qemu-devel@nongnu.org; Mon, 15 Jun 2009 10:24:36 -0400 Received: from mail-gx0-f207.google.com ([209.85.217.207]:36817) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MGD6y-0004yR-3L for qemu-devel@nongnu.org; Mon, 15 Jun 2009 10:24:36 -0400 Received: by gxk3 with SMTP id 3so17792416gxk.10 for ; Mon, 15 Jun 2009 07:24:35 -0700 (PDT) Message-ID: <4A3659A0.3050108@codemonkey.ws> Date: Mon, 15 Jun 2009 09:24:32 -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> In-Reply-To: <4A36555A.4090303@redhat.com> 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: dlaor@redhat.com Cc: Carsten Otte , kvm@vger.kernel.org, Mark McLoughlin , Glauber Costa , Rusty Russell , qemu-devel@nongnu.org, virtualization@lists.linux-foundation.org, Blue Swirl , Christian Borntraeger , "Michael S. Tsirkin" , Avi Kivity , Paul Brook Dor Laor wrote: > Libvirt does not support r2d. I hope it won't start to support it. It supports mips, sparc, and ppc machines now. I don't see why it wouldn't support r2d. For ppcemb, I expect this same problem to occur. This sort of restriction is going to be common with embedded boards. > We can have default values for these types of devices or something > like pci_addr=auto. Why wouldn't libvirt always use pci_addr=auto? If the only argument for having libvirt do pci slot allocation is error messages, can't we find a nice way to allow libvirt to create friendly error messages when QEMU fails? >> If you let QEMU allocate which PCI slot a device goes in, we can hide >> this detail from libvirt. If you have libvirt do PCI slot allocation >> by default, it has to know about this restriction in the r2d board >> unless you have a clever way to express this sort of information. >> >> Once QEMU has allocated a device to a slot, libvirt can do a good job >> maintaining that relationship. >> > > The end user should have a mechanism to control device slot > positioning. For example, if you have several pci devices, some > get high rate of interrupts and some not, if you want to optimize you > guest you should isolate the high rate 'interesting' devices. > This is something the user will need to do. I agree that the default > behavior might be 'auto' 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. Regards, Anthony Liguori