qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
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)

  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).