From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:48602) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bkSCB-0005tO-3h for qemu-devel@nongnu.org; Thu, 15 Sep 2016 04:39:04 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bkSC5-0003VL-Vg for qemu-devel@nongnu.org; Thu, 15 Sep 2016 04:38:57 -0400 Received: from mx1.redhat.com ([209.132.183.28]:46848) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bkSC5-0003Uj-MY for qemu-devel@nongnu.org; Thu, 15 Sep 2016 04:38:53 -0400 Date: Thu, 15 Sep 2016 10:38:48 +0200 From: Andrew Jones Message-ID: <20160915083848.ovjwgwbtjv33ia3g@kamzik.localdomain> References: <1472736127-18137-1-git-send-email-marcel@redhat.com> <6c9103e7-70ad-55c6-5533-d6d9bbaa39b4@redhat.com> <739af9d6-2382-c4bd-679d-87b153124491@redhat.com> <1473229310.28663.14.camel@redhat.com> <3ed4337a-f53a-a148-88d6-a3d35ffeca79@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Subject: Re: [Qemu-devel] [PATCH RFC] docs: add PCIe devices placement guidelines List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Marcel Apfelbaum Cc: Laine Stump , qemu-devel@nongnu.org, Peter Maydell , mst@redhat.com, Andrea Bolognani , Alex Williamson , Gerd Hoffmann , Laszlo Ersek On Wed, Sep 07, 2016 at 10:39:28PM +0300, Marcel Apfelbaum wrote: > On 09/07/2016 08:55 PM, Laine Stump wrote: > > On 09/07/2016 04:06 AM, Marcel Apfelbaum wrote: [snip] > > > Good point, maybe libvirt can avoid adding switches unless the user > > > explicitly > > > asked for them. I checked and it a actually works fine in QEMU. > > > > I'm just now writing the code that auto-adds *-ports as they are needed, and doing it this way simplifies it *immensely*. > > > > When I had to think about the possibility of needing upstream/downstream switches, as an endpoint device was added, I would need to check if a (root|downstream)-port was available and if not I might > > be able to just add a root-port, or I might have to add a downstream-port; if the only option was a downstream port, then *that* might require adding a new *upstream* port. > > > > If I can limit libvirt to only auto-adding root-ports (and if there is no downside to putting multiple root ports on a single root bus port), then I just need to find an empty function of an empty > > slot on the root bus, add a root-port, and I'm done (and since 224 is *a lot*, I think at least for now it's okay to punt once they get past that point). > > > > So, *is* there any downside to doing this? > > > > No downside I can think of. > Just be sure to emphasize the auto-add mechanism stops at 'x' devices. If the user needs more, > he should manually add switches and manually assign the devices to the Downstream Ports. > Just catching up on mail after vacation and read this thread. Thanks Marcel for writing this document (I guess a v1 is coming soon). This will be very useful for determining the best default configuration of a virtio-pci mach-virt. FWIW, here is the proposal that I started formulating when I experimented with this several months ago; - PCIe-only (disable-modern=off, disable-legacy=on) - No legacy PCI support, i.e. no bridges (yup, I'm a PCIe purist, but don't have a leg to stand on if push came to shove) - use one or more ports for virtio-scsi controllers for disks, one is probably enough - use one or more ports with multifunction, allowing up to 8 functions, for virtio-net, one port is probably enough - Add N extra ports for hotplug, N defaulting to 2 - hotplug devices to first N-1 ports, reserving last for a switch - if switch is needed, hotplug it with M downstream ports (M defaulting to 2*(N-1)+1) - Encourage somebody to develop generic versions of ports and switches, hi Marcel :-), and exclusively use those in the configuration Thanks, drew