Pavel Hrdina (5):
  qemu: change the logic of setting default USB controller
  qemu: use nec-usb-xhci as a default controller for aarch64 if
    available
  qemu: introduce QEMU_CAPS_DEVICE_QEMU_XHCI
  qemu: add support for qemu-xhci USB controller
  qemu: use qemu-xhci USB controller by default for ppc64 and aarch64

 docs/formatdomain.html.in                          |  4 +-
 docs/schemas/domaincommon.rng                      |  1 +
 src/conf/domain_addr.c                             |  1 +
 src/conf/domain_conf.c                             |  1 +
 src/conf/domain_conf.h                             |  1 +
 src/qemu/qemu_capabilities.c                       |  2 +
 src/qemu/qemu_capabilities.h                       |  1 +
 src/qemu/qemu_command.c                            |  8 +++-
 src/qemu/qemu_domain.c                             | 47 ++++++++++++++--------
 src/qemu/qemu_domain_address.c                     |  1 +
 tests/qemucapabilitiesdata/caps_2.9.0.x86_64.xml   |  1 +
 ...muxml2argv-aarch64-usb-controller-nec-xhci.args | 19 +++++++++
 ...emuxml2argv-aarch64-usb-controller-nec-xhci.xml | 16 ++++++++
 ...uxml2argv-aarch64-usb-controller-qemu-xhci.args | 19 +++++++++
 ...muxml2argv-aarch64-usb-controller-qemu-xhci.xml | 16 ++++++++
 ...emuxml2argv-ppc64-usb-controller-qemu-xhci.args | 19 +++++++++
 ...qemuxml2argv-ppc64-usb-controller-qemu-xhci.xml |  1 +
 ...qemuxml2argv-usb-controller-qemu-xhci-limit.xml | 14 +++++++
 ...l2argv-usb-controller-qemu-xhci-unavailable.xml |  1 +
 .../qemuxml2argv-usb-controller-qemu-xhci.args     | 19 +++++++++
 .../qemuxml2argv-usb-controller-qemu-xhci.xml      | 14 +++++++
 tests/qemuxml2argvtest.c                           | 15 +++++++
 22 files changed, 201 insertions(+), 20 deletions(-)
 create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-aarch64-usb-controller-nec-xhci.args
 create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-aarch64-usb-controller-nec-xhci.xml
 create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-aarch64-usb-controller-qemu-xhci.args
 create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-aarch64-usb-controller-qemu-xhci.xml
 create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-ppc64-usb-controller-qemu-xhci.args
 create mode 120000 tests/qemuxml2argvdata/qemuxml2argv-ppc64-usb-controller-qemu-xhci.xml
 create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-usb-controller-qemu-xhci-limit.xml
 create mode 120000 tests/qemuxml2argvdata/qemuxml2argv-usb-controller-qemu-xhci-unavailable.xml
 create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-usb-controller-qemu-xhci.args
 create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-usb-controller-qemu-xhci.xml

-- 
2.12.2

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

On Thu, 2017-04-27 at 18:09 +0200, Pavel Hrdina wrote:
> Pavel Hrdina (5):
>   qemu: change the logic of setting default USB controller
>   qemu: use nec-usb-xhci as a default controller for aarch64 if
>     available
>   qemu: introduce QEMU_CAPS_DEVICE_QEMU_XHCI
>   qemu: add support for qemu-xhci USB controller
>   qemu: use qemu-xhci USB controller by default for ppc64 and aarch64

There are a couple of minor nits in patches 4 and 5, the
kind that would not generally require a respin. The issue
with patch 1 is also simple enough to be fixed without
going through another round of reviews, but I'd prefer if
you dropped that patch altogether and if you decide to do
so the changes would become significant enough that I
feel a respin would be warranted.

Having expressed my preference, I leave up to you how to
go about dealing with patch 1: you can expect a swift
response on my part regardless of whether you ask for a
formal ACK or a review of v3 :)

-- 
Andrea Bolognani / Red Hat / Virtualization

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

On Thu, 2017-04-27 at 20:47 +0200, Andrea Bolognani wrote:
> > Pavel Hrdina (5):
> >    qemu: change the logic of setting default USB controller
> >    qemu: use nec-usb-xhci as a default controller for aarch64 if
> >      available
> >    qemu: introduce QEMU_CAPS_DEVICE_QEMU_XHCI
> >    qemu: add support for qemu-xhci USB controller
> >    qemu: use qemu-xhci USB controller by default for ppc64 and aarch64
> 
> There are a couple of minor nits in patches 4 and 5, the
> kind that would not generally require a respin. The issue
> with patch 1 is also simple enough to be fixed without
> going through another round of reviews, but I'd prefer if
> you dropped that patch altogether and if you decide to do
> so the changes would become significant enough that I
> feel a respin would be warranted.
> 
> Having expressed my preference, I leave up to you how to
> go about dealing with patch 1: you can expect a swift
> response on my part regardless of whether you ask for a
> formal ACK or a review of v3 :)

Given your follow-up comments: after you address the nit
I pointed out in patch 5, you can consider the series

Acked-by: Andrea Bolognani <abologna@redhat.com>

-- 
Andrea Bolognani / Red Hat / Virtualization

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

On Fri, Apr 28, 2017 at 10:36:06AM +0200, Andrea Bolognani wrote:
> On Thu, 2017-04-27 at 20:47 +0200, Andrea Bolognani wrote:
> > > Pavel Hrdina (5):
> > >    qemu: change the logic of setting default USB controller
> > >    qemu: use nec-usb-xhci as a default controller for aarch64 if
> > >      available
> > >    qemu: introduce QEMU_CAPS_DEVICE_QEMU_XHCI
> > >    qemu: add support for qemu-xhci USB controller
> > >    qemu: use qemu-xhci USB controller by default for ppc64 and aarch64
> > 
> > There are a couple of minor nits in patches 4 and 5, the
> > kind that would not generally require a respin. The issue
> > with patch 1 is also simple enough to be fixed without
> > going through another round of reviews, but I'd prefer if
> > you dropped that patch altogether and if you decide to do
> > so the changes would become significant enough that I
> > feel a respin would be warranted.
> > 
> > Having expressed my preference, I leave up to you how to
> > go about dealing with patch 1: you can expect a swift
> > response on my part regardless of whether you ask for a
> > formal ACK or a review of v3 :)
> 
> Given your follow-up comments: after you address the nit
> I pointed out in patch 5, you can consider the series
> 
> Acked-by: Andrea Bolognani <abologna@redhat.com>

Thanks for the review, I'll push it shortly.

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