Re: [Qemu-devel] [PATCH 00/17] s390x: the big pci update

[Cornelia Huck <cornelia.huck@de.ibm.com>]

On Fri, 24 Jun 2016 15:28:49 +0200
Cornelia Huck <cornelia.huck@de.ibm.com> wrote:

> We had been looking at remodelling the pci representation for s390x
> to handle our slightly odd architecture correctly some time ago
> already, but now we have a patchset that we're happy with.
> 
> There's a bunch of bugfixes, cleanups and architecture conformance
> changes in there, but the most interesting part is the modelling
> (which, in some respects, takes a cue from what sPAPR does).
> 
> We introduce a 'zpci' device to hold s390x-specific properties like
> the uid and fid. This 'zpci' device is connected to a run-of-the-mill
> pci device via the 'target' property.
> 
> Example command line portion:
> 
> -device zpci,uid=1,fid=1,target=vpci0 \
> -device vfio-pci,host=0000:00:00.0,id=vpci0 \
> -device zpci,target=vpci1 \
> -device vfio-pci,host=0001:00:00.0,id=vpci1 \
> -device vfio-pci,host=0002:00:00.0,id=vpci2
> 
> For device vpci0, uid and fid are specified in the associated zpci
> device.
> For device vpci1, uid and fid are automatically generated.
> For device vpci2, first an associated zpci device is generated and
> then autogenerated values for uid and fid are placed in it.
> 
> This should accomodate both specifying our special parameters and
> re-using standard statements for pci devices. You can still specify
> bus/slot/function for the pci device, but it will not be propagated
> into the guest (as the s390 pci architecture does not allow for it;
> the guest only sees uid/fid).
> 
> The "introduce S390PCI<foo>" patches are probably the most interesting
> for those looking at the modelling.
> 
> I'd love to see some feedback from a PCI perspective, as I'm happy
> from the s390x perspective (and I'd like to see this in 2.7).
> 
> Branch available at git://github.com/cohuck/qemu s390x-pci-update
> 
> Yi Min Zhao (17):
>   s390x/pci: fix failures of dma map/unmap
>   s390x/pci: acceleration for getting S390pciState
>   s390x/pci: write fid in CLP_QUERY_PCI_FN
>   s390x/pci: unify FH_ macros
>   s390x/pci: refactor s390_pci_find_dev_by_fh
>   s390x/pci: enforce zPCI state checking
>   s390x/pci: introduce S390PCIBus
>   s390x/pci: introduce S390PCIIOMMU
>   s390x/pci: introduce S390PCIBusDevice qdev
>   s390x/pci: enable uid-checking
>   s390x/pci: enable zpci hot-plug/hot-unplug
>   s390x/pci: add checkings in CLP_SET_PCI_FN
>   s390x/pci: refactor s390_pci_find_dev_by_idx
>   s390x/pci: refactor list_pci
>   s390x/pci: fix stpcifc_service_call
>   s390x/pci: replace fid with idx in msg data of msix
>   s390x/pci: make hot-unplug handler smoother
> 
>  hw/s390x/s390-pci-bus.c  | 579 +++++++++++++++++++++++++++++++++++------------
>  hw/s390x/s390-pci-bus.h  |  77 ++++++-
>  hw/s390x/s390-pci-inst.c | 266 ++++++++++++++++------
>  hw/s390x/s390-pci-inst.h |   7 +-
>  include/hw/s390x/sclp.h  |   1 +
>  target-s390x/kvm.c       |   4 +-
>  6 files changed, 718 insertions(+), 216 deletions(-)
> 

FWIW: I plan to include this in the next s390x pullreq for 2.7, unless
someone objects.