From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:38818) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1c7eMW-00030n-U8 for qemu-devel@nongnu.org; Fri, 18 Nov 2016 03:17:35 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1c7eMS-0006Xk-08 for qemu-devel@nongnu.org; Fri, 18 Nov 2016 03:17:32 -0500 Message-ID: <1479457042.1391.11.camel@redhat.com> From: Andrea Bolognani Date: Fri, 18 Nov 2016 09:17:22 +0100 In-Reply-To: <3353ecef-2308-13e3-025d-df41b2e89945@ozlabs.ru> 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> 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: Alexey Kardashevskiy , David Gibson Cc: Greg Kurz , Paolo Bonzini , Alex Williamson , qemu-ppc@nongnu.org, qemu-devel@nongnu.org, libvir-list@redhat.com, Michael Roth On Thu, 2016-11-17 at 13:02 +1100, Alexey Kardashevskiy wrote: > > That said, considering that a big part of the PCI address > > allocation logic is based off whether the specific machine > > type exposes a legay PCI Root Bus or a PCI Express Root Bus, > > libvirt will need a way to be able to tell which one is which. > >=C2=A0 > > Version checks are pretty much out of the question, as they > > fail as soon as downstream releases enter the picture. A > > few ways we could deal with the situation: > >=C2=A0 > >=C2=A0=C2=A0=C2=A01) switch to PCI Express on newer machine types, and > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0expose some sort of capability thr= ough QMP so that > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0libvirt can know about the switch [...] > > Option 1) would break horribly with existing libvirt > > versions, and so would Option 2) if we default to using >=C2=A0 > How exactly 1) will break libvirt? Migrating from pseries-2.7 to > pseries-2.8 does not work anyway, and machines are allowed to behave > different from version to version, what distinct difference will using > "pseries-pcie-X.Y" make? 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. So if you used a new QEMU binary with a libvirt version that doesn't know about the change, new guests would end up using the wrong controllers. Existing guests would not be affected as they would stick with the older machine types, of course. > I believe after we introduced the very first > pseries-pcie-X.Y, we will just stop adding new pseries-X.Y. 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. Even if no newer pseries-x.y were to be added after introducing pseries-pcie, you could still easily create guests that use either root bus, so no loss in functionality. --=C2=A0 Andrea Bolognani / Red Hat / Virtualization