From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:52127) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fT72j-0002fb-Bn for qemu-devel@nongnu.org; Wed, 13 Jun 2018 10:46:38 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fT72f-0003HC-W3 for qemu-devel@nongnu.org; Wed, 13 Jun 2018 10:46:37 -0400 Received: from mx3-rdu2.redhat.com ([66.187.233.73]:34986 helo=mx1.redhat.com) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1fT72f-0003Fi-Qd for qemu-devel@nongnu.org; Wed, 13 Jun 2018 10:46:33 -0400 Date: Wed, 13 Jun 2018 17:46:32 +0300 From: "Michael S. Tsirkin" Message-ID: <20180613173655-mutt-send-email-mst@kernel.org> References: <1528794804-6289-1-git-send-email-whois.zihan.yang@gmail.com> <20180612163301-mutt-send-email-mst@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [RFC v2 1/3] pci_expander_bridge: add type TYPE_PXB_PCIE_HOST List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Zihan Yang Cc: qemu-devel@nongnu.org, Marcel Apfelbaum On Wed, Jun 13, 2018 at 04:23:40PM +0800, Zihan Yang wrote: > Michael S. Tsirkin =E4=BA=8E2018=E5=B9=B46=E6=9C=8812=E6= =97=A5=E5=91=A8=E4=BA=8C =E4=B8=8B=E5=8D=889:43=E5=86=99=E9=81=93=EF=BC=9A > > > > On Tue, Jun 12, 2018 at 05:13:22PM +0800, Zihan Yang wrote: > > > The inner host bridge created by pxb-pcie is TYPE_PXB_PCI_HOST by d= efault, > > > add a new type TYPE_PXB_PCIE_HOST to better utilize the ECAM of PCI= e > > > > > > Signed-off-by: Zihan Yang > > > > I have a concern that there are lots of new properties > > added here, I'm not sure how are upper layers supposed to > > manage them all. > > > > E.g. bus_nr supplied in several places, domain_nr for which > > it's not clear how it is supposed to be allocated, etc. >=20 > Indeed they seem to double the properties, but the pxb host is > an internal structure of pxb-pcie device, created in pxb-pcie's > realization procedure, and acpi-build queries host bridges instead > of pxb-pcie devices. This means that users can not directly specify > the property of pxb host bridge, but must 'inherit' from pxb-pcie > devices. I had thought about changing the acpi-build process, > but that would require more modifications. > As for the properties, bus_nr means the start bus number > of this host bridge. It is used when pxb-pcie is in pci domain 0 > with q35 host to avoid bus number confliction. When it is placed > in a separate pci domain, it is not used and should be 0. >=20 > max_bus means how many buses the user desires, EACH bus in > PCIe requires 1MB configuration space, thus specifying it could > reduce the reserved memory in MMCFG as suggested by Marcel. > Typically, the user can specify >=20 > -device pxb-pcie,id=3Dbr1,bus=3D"pcie.0",sep_domain=3Don,domain_nr=3D1,= max_bus=3D130 >=20 > this will place the buses under this pxb host bridge in pci domain > 1, and reserve (130 + 1) =3D 131 buses for it. The start bus number > is always 0 currently for simplicity. >=20 > > Can the management interface be simplified? > > Ideally we wouldn't have to teach libvirt new tricks, > > just generalize pxb support slightly. >=20 > We can delete 'sep_domain' property, I just find 'domain_nr' > already indicates domain number. But domain_nr and > max_bus seems unremovable, although they look 'redundant' > because they appear twice. >=20 > I'm not familiar with libvirt, but from the perspective of user, > only 2 properties are added(domain_nr and max_bus, if we > delete sep_domain), though the internal structure actually has > changed. If you want a property for an internal purpose, you can have a property starting with "x-" this way we don't commit to maintaining it. --=20 MST