From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:56996) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bHu5Y-0001a9-0k for qemu-devel@nongnu.org; Tue, 28 Jun 2016 10:34:09 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bHu5R-0008Jg-U8 for qemu-devel@nongnu.org; Tue, 28 Jun 2016 10:34:07 -0400 Received: from mx1.redhat.com ([209.132.183.28]:32934) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bHu5R-0008JA-OX for qemu-devel@nongnu.org; Tue, 28 Jun 2016 10:34:01 -0400 References: <20160624132906.14446-1-cornelia.huck@de.ibm.com> From: Marcel Apfelbaum Message-ID: <57728AD6.9010403@redhat.com> Date: Tue, 28 Jun 2016 17:33:58 +0300 MIME-Version: 1.0 In-Reply-To: <20160624132906.14446-1-cornelia.huck@de.ibm.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 00/17] s390x: the big pci update List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Cornelia Huck , qemu-devel@nongnu.org Cc: mst@redhat.com, borntraeger@de.ibm.com, agraf@suse.de, jfrei@linux.vnet.ibm.com, zyimin@linux.vnet.ibm.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 [...]