qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH RFC] docs: add PCIe devices placement guidelines


From: Andrew Jones
Subject: Re: [Qemu-devel] [PATCH RFC] docs: add PCIe devices placement guidelines
Date: Thu, 15 Sep 2016 10:38:48 +0200
User-agent: Mutt/1.6.0.1 (2016-04-01)

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]