From: Marcel Apfelbaum <marcel@redhat.com>
To: Markus Armbruster <armbru@redhat.com>
Cc: ehabkost@redhat.com, mst@redhat.com, qemu-devel@nongnu.org,
kraxel@redhat.com, imammedo@redhat.com,
Paolo Bonzini <pbonzini@redhat.com>,
rth@twiddle.net
Subject: Re: [Qemu-devel] [PATCH V2 0/4] hw/pcie: Multi-root support for Q35
Date: Tue, 17 Nov 2015 12:42:42 +0200 [thread overview]
Message-ID: <564B04A2.9070007@redhat.com> (raw)
In-Reply-To: <87h9kl2g99.fsf@blackfin.pond.sub.org>
On 11/17/2015 10:15 AM, Markus Armbruster wrote:
> Marcel Apfelbaum <marcel@redhat.com> writes:
>
>> 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.
>
> I have no opinion on two devices vs. one device + property in this
> particular case, I just want to interject that I'd expect the difference
> in maintaince to be negligible.
>
> A second device basically takes a copy of the TypeInfo with some
> (trivial) init function to make it different. Might be a few more lines
> of code than adding a property, but in complexity, it's a wash.
>
> In case you plan to get rid of the old variant: with two devices, you
> deprecate and later delete the old device. With device + property, you
> deprecate setting the property, and later delete it. The former might
> be a bit easier to document.
Hi Markus,
Thank you for the review.
Following all the comments I have received, I am going to:
1. Leave the old device (pxb) as is and mark it as deprecated. Maybe
you can point me on the cleanest way to mark a device as deprecated?
2. Create a new device (pci-expander) that will behave as a:
- PCI root, if the machine's bus 0 is legacy PCI.
- PCI express root (Root Complex), if machine's bus 0 is PCI Express.
This way I will not need two device and not even a property for (pci/pcie).
We don't really need an extra PCI root on a PCIe machine and vice versa.
By the way, following the same concept I converted the virtio devices to PCIe devices.
I didn't want a new set of devices.
Thanks,
Marcel
>
>>>> 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)
next prev parent reply other threads:[~2015-11-17 10:42 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-11-15 15:39 [Qemu-devel] [PATCH V2 0/4] hw/pcie: Multi-root support for Q35 Marcel Apfelbaum
2015-11-15 15:39 ` [Qemu-devel] [PATCH V2 1/4] hw/pxb: remove the built-in pci bridge Marcel Apfelbaum
2015-11-15 15:39 ` [Qemu-devel] [PATCH V2 2/4] hw/acpi: merge pxb adjacent memory/IO ranges Marcel Apfelbaum
2015-11-15 15:39 ` [Qemu-devel] [PATCH V2 3/4] hw/pc: query both q35 and i440fx bus Marcel Apfelbaum
2015-11-16 18:26 ` Eduardo Habkost
2015-11-17 10:29 ` Marcel Apfelbaum
2015-11-15 15:39 ` [Qemu-devel] [PATCH V2 4/4] hw/pxb: add support for PCIe Marcel Apfelbaum
2015-11-16 8:40 ` [Qemu-devel] [PATCH V2 0/4] hw/pcie: Multi-root support for Q35 Paolo Bonzini
2015-11-16 9:52 ` Marcel Apfelbaum
2015-11-16 9:56 ` Paolo Bonzini
2015-11-16 10:02 ` Marcel Apfelbaum
2015-11-16 10:03 ` Paolo Bonzini
2015-11-16 10:10 ` Marcel Apfelbaum
2015-11-16 10:11 ` Paolo Bonzini
2015-11-16 10:34 ` Marcel Apfelbaum
2015-11-16 10:37 ` Michael S. Tsirkin
2015-11-16 10:39 ` Marcel Apfelbaum
2015-11-16 10:59 ` Michael S. Tsirkin
2015-11-16 11:37 ` Marcel Apfelbaum
2015-11-16 13:30 ` Paolo Bonzini
2015-11-19 15:05 ` Laine Stump
2015-11-17 8:15 ` Markus Armbruster
2015-11-17 10:42 ` Marcel Apfelbaum [this message]
2015-11-17 12:26 ` Markus Armbruster
2015-11-17 13:49 ` Marcel Apfelbaum
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=564B04A2.9070007@redhat.com \
--to=marcel@redhat.com \
--cc=armbru@redhat.com \
--cc=ehabkost@redhat.com \
--cc=imammedo@redhat.com \
--cc=kraxel@redhat.com \
--cc=mst@redhat.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=rth@twiddle.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).