Re: [libvirt] [PATCH 06/11] qemu: Implement pcie-to-pci-bridge controller

[John Ferlan]

On 04/06/2018 04:15 AM, Andrea Bolognani wrote:
> On Wed, 2018-04-04 at 10:58 +0200, Andrea Bolognani wrote:
>> On Tue, 2018-04-03 at 19:13 -0400, John Ferlan wrote:
>>> Is there something else perhaps a few paragraphs later that could be
>>> added to say what this is and how/when/why someone should want to use
>>> it? Including the restriction about slot=0 (whatever the FLA SHPC is)...
>>> Similar to dmi-to-pci-bridge... Perhaps something that would already be
>>> there considering my patch 1 comment for a description field or some
>>> sort of relationship matrix...
>>
>> Yeah, I realized today that there's some documentation for the
>> existing behavior of adding a dmi-to-pci-bridge that will need to
>> tweaked in this patch to address the changes... Once that's been
>> taken care of, I don't think there will be much to add, though.
> 
> I've come up with the diff below, which I plan to squash in patch
> 8/11, when the change in behavior it documents is implemented. I
> have also converted the list of models to a , as agreed upon in
> the review for patch 1/11.
> 
> Since patch 3/11 is really just an independent cleanup which doesn't
> need to hold up the new feature, I plan to go ahead and push the
> rest of the series (with the changes described above) later today.
> Is that okay with you, or would you rather see a full v2 posted on
> the list?
> 

Your plan is fine by me.

John

> 
> diff --git a/docs/formatdomain.html.in b/docs/formatdomain.html.in
> index 84059737d5..a5a83f56c3 100644
> --- a/docs/formatdomain.html.in
> +++ b/docs/formatdomain.html.in
> @@ -4114,10 +4114,14 @@
>devices (although libvirt will never auto-assign a PCI device to
>a PCIe slot, it will allow manual specification of such an
>assignment). Devices connected to pcie-root cannot be
> -  hotplugged. In order to make standard PCI slots available on a
> -  system which has a pcie-root controller, a pci controller
> -  with model='dmi-to-pci-bridge' is automatically
> -  added, usually at the defacto standard location of slot=0x1e. A
> +  hotplugged. If traditional PCI devices are present in the guest
> +  configuration, a pcie-to-pci-bridge controller will
> +  automatically be added: this controller, which plugs into a
> +  pcie-root-port, provides 31 usable PCI slots (1-31) with
> +  hotplug support (since 4.3.0). If the QEMU
> +  binary doesn't support the corresponding device, then a
> +  dmi-to-pci-bridge controller will be added instead,
> +  usually at the defacto standard location of slot=0x1e. A
>dmi-to-pci-bridge controller plugs into a PCIe slot (as provided
>by pcie-root), and itself provides 31 standard PCI slots (which
>also do not support device hotplug). In order to have
> 

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH 06/11] qemu: Implement pcie-to-pci-bridge controller

[Andrea Bolognani]

On Wed, 2018-04-04 at 10:58 +0200, Andrea Bolognani wrote:
> On Tue, 2018-04-03 at 19:13 -0400, John Ferlan wrote:
> > Is there something else perhaps a few paragraphs later that could be
> > added to say what this is and how/when/why someone should want to use
> > it? Including the restriction about slot=0 (whatever the FLA SHPC is)...
> > Similar to dmi-to-pci-bridge... Perhaps something that would already be
> > there considering my patch 1 comment for a description field or some
> > sort of relationship matrix...
> 
> Yeah, I realized today that there's some documentation for the
> existing behavior of adding a dmi-to-pci-bridge that will need to
> tweaked in this patch to address the changes... Once that's been
> taken care of, I don't think there will be much to add, though.

I've come up with the diff below, which I plan to squash in patch
8/11, when the change in behavior it documents is implemented. I
have also converted the list of models to a , as agreed upon in
the review for patch 1/11.

Since patch 3/11 is really just an independent cleanup which doesn't
need to hold up the new feature, I plan to go ahead and push the
rest of the series (with the changes described above) later today.
Is that okay with you, or would you rather see a full v2 posted on
the list?


diff --git a/docs/formatdomain.html.in b/docs/formatdomain.html.in
index 84059737d5..a5a83f56c3 100644
--- a/docs/formatdomain.html.in
+++ b/docs/formatdomain.html.in
@@ -4114,10 +4114,14 @@
   devices (although libvirt will never auto-assign a PCI device to
   a PCIe slot, it will allow manual specification of such an
   assignment). Devices connected to pcie-root cannot be
-  hotplugged. In order to make standard PCI slots available on a
-  system which has a pcie-root controller, a pci controller
-  with model='dmi-to-pci-bridge' is automatically
-  added, usually at the defacto standard location of slot=0x1e. A
+  hotplugged. If traditional PCI devices are present in the guest
+  configuration, a pcie-to-pci-bridge controller will
+  automatically be added: this controller, which plugs into a
+  pcie-root-port, provides 31 usable PCI slots (1-31) with
+  hotplug support (since 4.3.0). If the QEMU
+  binary doesn't support the corresponding device, then a
+  dmi-to-pci-bridge controller will be added instead,
+  usually at the defacto standard location of slot=0x1e. A
   dmi-to-pci-bridge controller plugs into a PCIe slot (as provided
   by pcie-root), and itself provides 31 standard PCI slots (which
   also do not support device hotplug). In order to have
-- 
Andrea Bolognani / Red Hat / Virtualization

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH 06/11] qemu: Implement pcie-to-pci-bridge controller

[Andrea Bolognani]

On Tue, 2018-04-03 at 19:13 -0400, John Ferlan wrote:
> Is there something else perhaps a few paragraphs later that could be
> added to say what this is and how/when/why someone should want to use
> it? Including the restriction about slot=0 (whatever the FLA SHPC is)...
> Similar to dmi-to-pci-bridge... Perhaps something that would already be
> there considering my patch 1 comment for a description field or some
> sort of relationship matrix...

Yeah, I realized today that there's some documentation for the
existing behavior of adding a dmi-to-pci-bridge that will need to
tweaked in this patch to address the changes... Once that's been
taken care of, I don't think there will be much to add, though.

-- 
Andrea Bolognani / Red Hat / Virtualization

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH 06/11] qemu: Implement pcie-to-pci-bridge controller

[John Ferlan]

On 03/28/2018 10:06 AM, Andrea Bolognani wrote:
> The new controller will not yet be used automatically by
> libvirt, but at this point it's already possible to configure
> a guest to use it.
> 
> Signed-off-by: Andrea Bolognani 
> ---
>  docs/formatdomain.html.in  |  3 ++-
>  docs/schemas/domaincommon.rng  |  3 +++
>  src/conf/domain_addr.c | 25 -
>  src/conf/domain_addr.h |  4 +++-
>  src/conf/domain_conf.c |  3 +++
>  src/conf/domain_conf.h |  2 ++
>  src/qemu/qemu_command.c|  1 +
>  src/qemu/qemu_domain.c | 17 +
>  src/qemu/qemu_domain_address.c |  4 
>  9 files changed, 55 insertions(+), 7 deletions(-)
> 
> diff --git a/docs/formatdomain.html.in b/docs/formatdomain.html.in
> index 299d7b9d42..fa5a0fff8a 100644
> --- a/docs/formatdomain.html.in
> +++ b/docs/formatdomain.html.in
> @@ -3942,7 +3942,8 @@
>pcie-root-port, pcie-switch-upstream-port and
>pcie-switch-downstream-port (since
>1.2.19), pci-expander-bus and
> -  pcie-expander-bus (since 
> 1.3.4).
> +  pcie-expander-bus (since 
> 1.3.4),
> +  pcie-to-pci-bridge (since 
> 4.3.0).
>The root controllers (pci-root
>and pcie-root) have an
>optional pcihole64 element specifying how big (in

Considering my patch 1 comments, there will be obvious adjustments here.

Is there something else perhaps a few paragraphs later that could be
added to say what this is and how/when/why someone should want to use
it? Including the restriction about slot=0 (whatever the FLA SHPC is)...
Similar to dmi-to-pci-bridge... Perhaps something that would already be
there considering my patch 1 comment for a description field or some
sort of relationship matrix...

With a few more words...

Reviewed-by: John Ferlan 

John

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list