[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Marcel Apfelbaum
Subject: Re: [Qemu-devel] [PATCH 00/17] s390x: the big pci update
Date: Tue, 28 Jun 2016 17:33:58 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0

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
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).


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 



reply via email to

[Prev in Thread] Current Thread [Next in Thread]