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

[Marcel Apfelbaum <marcel@redhat.com>]

On 06/24/2016 04:28 PM, Cornelia Huck 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).
>

Hi,

Please excuse my lack of s390 knowledge, but I find hard to understand
how it works. If using bus/slot/function is not an option,
how can one access the configuration space? This configuration is not PCI compliant?

Thanks,
Marcel

[...]