From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:45689) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cAHcC-0006fA-52 for qemu-devel@nongnu.org; Fri, 25 Nov 2016 09:36:37 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cAHc8-0001dR-7Z for qemu-devel@nongnu.org; Fri, 25 Nov 2016 09:36:36 -0500 Message-ID: <1480084585.4367.69.camel@redhat.com> From: Andrea Bolognani Date: Fri, 25 Nov 2016 15:36:25 +0100 In-Reply-To: <20161123050214.GE17795@umbus.fritz.box> References: <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> <1479733731.4367.4.camel@redhat.com> <98244c30-1397-5a1b-eb9a-446f41e9890e@ozlabs.ru> <20161123050214.GE17795@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 , Alexey Kardashevskiy Cc: 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:02 +1100, David Gibson wrote: > > > The change from OHCI to XHCI only affected the *default* USB > > > controller, which libvirt tries its best not to use anyway: > > > instead, it will prefer to use '-M ...,usb=3Doff' along with > > > '-device ...' and set both the controller model and its PCI > > > address explicitly, partially to shield its users from such > > > changes in QEMU. > >=C2=A0 > > Ok. Always likes this approach really. We should start moving to this > > direction with PHB - stop adding the default PHB at all when -nodefau= lts is > > passed (or -machine pseries,pci=3Doff ?) and let libvirt manage PHBs = itself > > (and provide another spapr-phb type like spapr-pcie-host-bridge or ad= d a > > "pcie_root_bus_type" property to the existing PHB type). > >=C2=A0 > > What will be wrong with this approach? >=C2=A0 > Hm, that's a good point.=C2=A0=C2=A0If were removing the default PHB en= tirely, > that I would consider a possible case for a new machine type.=C2=A0=C2=A0= Putting > construction of the PHBs into libvirt's hand could make life simpler > there.=C2=A0=C2=A0Although it would make it a bit of a pain for people = starting > qemu by hand. >=C2=A0 > I think this option is worth some thought. Note that libvirt always runs QEMU with -nodefaults, so we could just remove the default PHB if that flag is present, and leave it in if that's not the case. The idea itself sounds good, but of course it will require more work from the libvirt side than simply making the PCIe machine type behave like q35 and mach-virt. Moreover, we already have an RFE for supporting additional PHBs, we could solve both issues in one fell swoop and have the libvirt guest XML be a more faithful representation of the actual virtual hardware, which is always a win in my book. That will be even more important if it turns out that the rules for PCIe device assignment (eg. what device/controller can be plugged into which slot) are different for PCIe PHBs than they are for q35/mach-virt PCIe Root Bus. I've asked for clarifications about this elsewhere in the thread. --=C2=A0 Andrea Bolognani / Red Hat / Virtualization