From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:36055) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cAGpm-0001Jw-KH for qemu-devel@nongnu.org; Fri, 25 Nov 2016 08:46:35 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cAGpi-0006Tu-L6 for qemu-devel@nongnu.org; Fri, 25 Nov 2016 08:46:34 -0500 Message-ID: <1480081581.4367.65.camel@redhat.com> From: Andrea Bolognani Date: Fri, 25 Nov 2016 14:46:21 +0100 In-Reply-To: <20161123050049.GD17795@umbus.fritz.box> References: <1477641400-23292-1-git-send-email-aik@ozlabs.ru> <20161028120712.4a911866@bahia> <20161031025314.GJ18226@umbus.fritz.box> <20161101024634.GA14860@umbus.fritz.box> <1479218565.3319.18.camel@redhat.com> <3353ecef-2308-13e3-025d-df41b2e89945@ozlabs.ru> <1479457042.1391.11.camel@redhat.com> <20161123050049.GD17795@umbus.fritz.box> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [Qemu-ppc] [RFC PATCH qemu] spapr_pci: Create PCI-express root bus by default List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: David Gibson Cc: Alexey Kardashevskiy , Greg Kurz , Paolo Bonzini , Alex Williamson , qemu-ppc@nongnu.org, qemu-devel@nongnu.org, libvir-list@redhat.com, Michael Roth On Wed, 2016-11-23 at 16:00 +1100, David Gibson wrote: > > Existing libvirt versions assume that pseries guests have > > a legacy PCI root bus, and will base their PCI address > > allocation / PCI topology decisions on that fact: they > > will, for example, use legacy PCI bridges. >=C2=A0 > Um.. yeah.. trouble is libvirt's PCI-E address allocation probably > won't work for spapr PCI-E either, because of the weird PCI-E without > root complex presentation we get in PAPR. So, would the PCIe Root Bus in a pseries guest behave differently than the one in a q35 or mach-virt guest? Does it have a different number of slots, do we have to plug different controllers into them, ...? Regardless of how we decide to move forward with the PCIe-enabled pseries machine type, libvirt will have to know about this so it can behave appropriately. > > > I believe after we introduced the very first > > > pseries-pcie-X.Y, we will just stop adding new pseries-X.Y. > >=C2=A0 > > Isn't i440fx still being updated despite the fact that q35 > > exists? Granted, there are a lot more differences between > > those two machine types than just the root bus type. >=C2=A0 > Right, there are heaps of differences between i440fx and q35, and > reasons to keep both updated.=C2=A0=C2=A0For pseries we have neither th= e impetus > nor the resources to maintain two different machine type variant, > where the only difference is between legacy PCI and weirdly presented > PCI-E. Calling the PCIe machine type either pseries-2.8 or pseries-pcie-2.8 would result in the very same amount of work, and in both cases it would be understood that the legacy PCI machine type is no longer going to be updated, but can still be used to run existing guests. --=C2=A0 Andrea Bolognani / Red Hat / Virtualization