[libvirt] [PATCH 0/8] vfio-ccw passthrough support

[John Ferlan]

On 04/26/2018 03:59 AM, Bjoern Walk wrote:
> Shalini Chellathurai Saroja <shalini at linux.vnet.ibm.com> [2018-04-11, 05:49PM +0200]:
>> Let us support the basic channel I/O passthrough infrastructure based on
>> vfio, which have been introduced in QEMU 2.10. The current focus is to
>> support dasd-eckd (cu_type/dev_type = 0x3990/0x3390) as the target
>> device.
>>
>> Shalini Chellathurai Saroja (8):
>>   qemu: introduce capability for virtual-css-bridge
>>   qemu: introduce vfio-ccw capability
>>   util: virhostdev: add virHostdevIsMdevDevice()
>>   qemu: vfio-ccw device address generation
>>   qemu: command line generation for vfio-ccw device
>>   tests: tests for vfio-ccw passthrough
>>   docs: documentation for vfio-ccw passthrough
>>   news: documentation of new feature
> 
> Any chance, we get at least a review before 4.3 hits? Would be
> appreciated.
> 
> 

So obviously this did not make the 4.3.0 and the series will need a
refresh due to the volume of change in qemu_capabilities.{c,h}.

I've reviewed a number of patches recently and made a similar comment in
all of them - when changing qemu_capabilities.{c,h} and updating the
various qemucapabilitiesdata/caps_*.xml files - do so in a separate
patch. That way if someone doesn't review the code right away, it's
actually fairly simple to recreate at least the capability for a
reviewer. Having it mixed in one patch with other qemu, conf, test, etc.
changes causes git am -3 to fail and thus makes review harder especially
when you don't get to reviews as soon as patches hit the list.

Someone may also want to consider creating a s390 specific version of
what Peter did for x86_64 for VIR_TEST_CAPS_LATEST in order to then
have/use the "latest" capabilities instead of adding bits to xml2argv
tests. I'm curious why the xml2xml test needed the bit adjustment - did
something fail?  Since there were no xml output data changes, that would
seem to indicate there isn't a need to modify the xml2xml test source.

John