All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrew Jones <drjones@redhat.com>
To: Marcel Apfelbaum <marcel@redhat.com>
Cc: Laine Stump <laine@redhat.com>,
	qemu-devel@nongnu.org, Peter Maydell <peter.maydell@linaro.org>,
	mst@redhat.com, Andrea Bolognani <abologna@redhat.com>,
	Alex Williamson <alex.williamson@redhat.com>,
	Gerd Hoffmann <kraxel@redhat.com>,
	Laszlo Ersek <lersek@redhat.com>
Subject: Re: [Qemu-devel] [PATCH RFC] docs: add PCIe devices placement guidelines
Date: Thu, 15 Sep 2016 10:38:48 +0200	[thread overview]
Message-ID: <20160915083848.ovjwgwbtjv33ia3g@kamzik.localdomain> (raw)
In-Reply-To: <e263e665-fb8f-04ae-6b1d-bb5c48d5b39d@redhat.com>

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

  parent reply	other threads:[~2016-09-15  8:39 UTC|newest]

Thread overview: 52+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-09-01 13:22 [Qemu-devel] [PATCH RFC] docs: add PCIe devices placement guidelines Marcel Apfelbaum
2016-09-01 13:27 ` Peter Maydell
2016-09-01 13:51   ` Marcel Apfelbaum
2016-09-01 17:14     ` Laszlo Ersek
2016-09-05 16:24 ` Laszlo Ersek
2016-09-05 20:02   ` Marcel Apfelbaum
2016-09-06 13:31     ` Laszlo Ersek
2016-09-06 14:46       ` Marcel Apfelbaum
2016-09-07  6:21       ` Gerd Hoffmann
2016-09-07  8:06         ` Laszlo Ersek
2016-09-07  8:23           ` Marcel Apfelbaum
2016-09-07  8:06         ` Marcel Apfelbaum
2016-09-07 16:08           ` Alex Williamson
2016-09-07 19:32             ` Marcel Apfelbaum
2016-09-07 17:55           ` Laine Stump
2016-09-07 19:39             ` Marcel Apfelbaum
2016-09-07 20:34               ` Laine Stump
2016-09-15  8:38               ` Andrew Jones [this message]
2016-09-15 14:20                 ` Marcel Apfelbaum
2016-09-16 16:50                   ` Andrea Bolognani
2016-09-08  7:33             ` Gerd Hoffmann
2016-09-06 11:35   ` Gerd Hoffmann
2016-09-06 13:58     ` Laine Stump
2016-09-07  7:04       ` Gerd Hoffmann
2016-09-07 18:20         ` Laine Stump
2016-09-08  7:26           ` Gerd Hoffmann
2016-09-06 14:47     ` Marcel Apfelbaum
2016-09-07  7:53     ` Laszlo Ersek
2016-09-07  7:57       ` Marcel Apfelbaum
2016-10-04 14:59   ` Daniel P. Berrange
2016-10-04 15:40     ` Laszlo Ersek
2016-10-04 16:10       ` Laine Stump
2016-10-04 16:43         ` Laszlo Ersek
2016-10-04 18:08           ` Laine Stump
2016-10-04 18:52             ` Alex Williamson
2016-10-10 12:02               ` Andrea Bolognani
2016-10-10 14:36                 ` Marcel Apfelbaum
2016-10-11 15:37                   ` Andrea Bolognani
2016-10-04 18:56             ` Laszlo Ersek
2016-10-04 17:54         ` Laine Stump
2016-10-05  9:17           ` Marcel Apfelbaum
2016-10-10 11:09             ` Andrea Bolognani
2016-10-10 14:15               ` Marcel Apfelbaum
2016-10-11 13:30                 ` Andrea Bolognani
2016-10-04 15:45     ` Alex Williamson
2016-10-04 16:25       ` Laine Stump
2016-10-05 10:03         ` Marcel Apfelbaum
2016-09-06 15:38 ` Alex Williamson
2016-09-06 18:14   ` Marcel Apfelbaum
2016-09-06 18:32     ` Alex Williamson
2016-09-06 18:59       ` Marcel Apfelbaum
2016-09-07  7:44       ` Laszlo Ersek

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20160915083848.ovjwgwbtjv33ia3g@kamzik.localdomain \
    --to=drjones@redhat.com \
    --cc=abologna@redhat.com \
    --cc=alex.williamson@redhat.com \
    --cc=kraxel@redhat.com \
    --cc=laine@redhat.com \
    --cc=lersek@redhat.com \
    --cc=marcel@redhat.com \
    --cc=mst@redhat.com \
    --cc=peter.maydell@linaro.org \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.