From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:46070) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZyI6D-0000D9-Pa for qemu-devel@nongnu.org; Mon, 16 Nov 2015 06:37:30 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZyI69-00041J-Kp for qemu-devel@nongnu.org; Mon, 16 Nov 2015 06:37:29 -0500 Received: from mx1.redhat.com ([209.132.183.28]:41287) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZyI69-00041F-F6 for qemu-devel@nongnu.org; Mon, 16 Nov 2015 06:37:25 -0500 References: <5649966C.7070702@redhat.com> <5649A770.5070908@redhat.com> <5649A857.406@redhat.com> <5649A9CA.2070309@redhat.com> <5649A9F9.5070405@redhat.com> <5649AB7F.9030702@redhat.com> <5649ABDF.1010901@redhat.com> <5649B123.1050507@redhat.com> <20151116123454-mutt-send-email-mst@redhat.com> <5649B271.10204@redhat.com> <20151116125539-mutt-send-email-mst@redhat.com> From: Marcel Apfelbaum Message-ID: <5649BFF2.3000602@redhat.com> Date: Mon, 16 Nov 2015 13:37:22 +0200 MIME-Version: 1.0 In-Reply-To: <20151116125539-mutt-send-email-mst@redhat.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH V2 0/4] hw/pcie: Multi-root support for Q35 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Michael S. Tsirkin" Cc: ehabkost@redhat.com, qemu-devel@nongnu.org, kraxel@redhat.com, imammedo@redhat.com, Paolo Bonzini , rth@twiddle.net On 11/16/2015 12:59 PM, Michael S. Tsirkin wrote: > On Mon, Nov 16, 2015 at 12:39:45PM +0200, Marcel Apfelbaum wrote: >> On 11/16/2015 12:37 PM, Michael S. Tsirkin wrote: >>> On Mon, Nov 16, 2015 at 12:34:11PM +0200, Marcel Apfelbaum wrote: >>>> On 11/16/2015 12:11 PM, Paolo Bonzini wrote: >>>>> >>>>> >>>>> On 16/11/2015 11:10, Marcel Apfelbaum wrote: >>>>>>> What would you lose? Hotplug? >>>>>> >>>>>> Without the bridge? Yes. However the user can add it manually the >>>>>> pci-bridge and have it anyway. >>>>> >>>>> Ok, I guess that's more or less acceptable. It's still ugly however, to >>>>> the point that I wonder if we should rename the device and call the old >>>>> one a failed experiment. >>>>> >>>> >>>> I guess we can rename the pxb to extra-root or something, but in this way >>>> will have a deprecated/duplicated device to support and kill in the future. >>>> >>>> Why not use the compat property as it is? >>>> Again, the command line *remains* the same, the difference is where the >>>> devices associated with the pxb will land: on the secondary bus (for QEMU < 2.5) >>>> or on the root bus itself (QEMU >= 2.5). >>>> >>>> I know is guest visible, but the guest will see one of them depending on the machine type. >>>> >>>> Regarding the splitting of pxb into 2 devices (pci/pcie), I have nothing against it, >>>> but because the implementation is *exactly* the same I think we should gain more >>>> by maintaining one device. >>>> >>>> >>>> Thanks, >>>> Marcel >>> >>> Yes, I think you want a new "pci-extender" device which is just the extender. >>> Then existing pxb will create both it and the bridge behind it. >>> Maybe creating pxb which is extender+bridge was a mistake, I don't know, >>> but we shipped it in QEMU so we support it. >> >> OK, but this device will be both pci/pcie, depending on the machine type right? >> No need to split it too? >> >> Thanks, >> Marcel > > It's ok to have a single device but I don't like > tying it to a machine type, much. > It's always integrated within a RC, right? > Can you go by the type of the parent device? Yes and this is what I am doing, looking for the bus the pxb is on and not for the machine type. I'll start working on it, Thanks, Marcel > >> >>> >>>> >>>>> Paolo >>>>> >>>>>> I wanted to get rid of the internal pci-bridge as a default, and this >>>>>> is why pxb and pxb-pcie are he same device now (except bus type)