From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:52796) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YShqi-00009M-CG for qemu-devel@nongnu.org; Tue, 03 Mar 2015 03:06:41 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YShqe-0003kG-Aw for qemu-devel@nongnu.org; Tue, 03 Mar 2015 03:06:40 -0500 Received: from e06smtp17.uk.ibm.com ([195.75.94.113]:57054) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YShqe-0003k6-25 for qemu-devel@nongnu.org; Tue, 03 Mar 2015 03:06:36 -0500 Received: from /spool/local by e06smtp17.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Tue, 3 Mar 2015 08:06:33 -0000 Received: from b06cxnps4076.portsmouth.uk.ibm.com (d06relay13.portsmouth.uk.ibm.com [9.149.109.198]) by d06dlp02.portsmouth.uk.ibm.com (Postfix) with ESMTP id 0242F219005E for ; Tue, 3 Mar 2015 08:06:24 +0000 (GMT) Received: from d06av05.portsmouth.uk.ibm.com (d06av05.portsmouth.uk.ibm.com [9.149.37.229]) by b06cxnps4076.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id t2386VYM7668136 for ; Tue, 3 Mar 2015 08:06:31 GMT Received: from d06av05.portsmouth.uk.ibm.com (localhost [127.0.0.1]) by d06av05.portsmouth.uk.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id t2386VIS016813 for ; Tue, 3 Mar 2015 01:06:31 -0700 Date: Tue, 3 Mar 2015 09:06:31 +0100 From: Frank Blaschka Message-ID: <20150303080631.GA20285@tuxmaker.boeblingen.de.ibm.com> References: <1424951988-40477-1-git-send-email-blaschka@linux.vnet.ibm.com> <1424951988-40477-2-git-send-email-blaschka@linux.vnet.ibm.com> <54EF3013.8020608@suse.de> <20150226152701.GA31166@tuxmaker.boeblingen.de.ibm.com> <54EF3CEE.5020008@suse.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <54EF3CEE.5020008@suse.de> Subject: Re: [Qemu-devel] [PATCH RFC 1/1] s390x/pci: Extend pci representation by new zpci device List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alexander Graf Cc: cornelia.huck@de.ibm.com, borntraeger@de.ibm.com, qemu-devel@nongnu.org On Thu, Feb 26, 2015 at 04:34:06PM +0100, Alexander Graf wrote: > > > On 26.02.15 16:27, Frank Blaschka wrote: > > On Thu, Feb 26, 2015 at 03:39:15PM +0100, Alexander Graf wrote: > >> > >> > >> On 26.02.15 12:59, Frank Blaschka wrote: > >>> This patch extends the current s390 pci implementation to > >>> provide more flexibility in configuration of s390 specific > >>> device handling. For this we had to introduce a new facility > >>> (and bus) to hold devices representing information actually > >>> provided by s390 firmware and I/O configuration. > >>> > >>> On s390 the physical structure of the pci system (bridge, bus, slot) > >>> in not shown to the OS. For this the pci bridge and bus created > >>> in qemu can also not be shown to the guest. The new zpci device class > >>> represents this abstract view on the bare pci function and allows to > >>> provide s390 specific configuration attributes for it. > >>> > >>> Sample qemu configuration: > >>> -device e1000,id=zpci1 > >>> -device ne2k_pci,id=zpci2 > >>> -device zpci,fid=2,uid=1248,pci_id=zpci1 > >>> -device zpci,fid=17,uid=2244,pci_id=zpci2 > >>> > >>> A zpci device references the corresponding PCI device via device id. > >>> The new design allows to define multiple host bridges and support more > >>> pci devices. > >> > >> Isn't this reverse? Shouldn't it rather be > >> > >> -device zpci,...,id=zpci1 > >> -device e1000,bus=zpci1.0 > >> > >> with a limit on each virtual zpci bus to only support one device? > > > > Do you mean something like having multiple host bridges (providing a pci bus > > each) and limit the bus to just one device? > > > > -device s390-pcihost,fid=16,uid=1234 > > -device s390-pcihost,fid=17,uid=5678 > > -device e1000,bus=pci.0 > > -device ne2k_pci,bus=pci.1 > > > > We also discussed this option but we don't like the idea to put attributes > > belong to the pci device to the host bridge. > > I guess I'm not grasping something obvious here :). What exactly are the > attributes again? > Sorry for the late response, I was on vacation the last couple days. The fid and uid values are provided by microcode/io layer on the real hardware. You can read them out via s390 specific device attributes e.g. # cat /sys/bus/pci/devices/0000\:00\:00.0/function_id 0x00000016 # cat /sys/bus/pci/devices/0000\:00\:00.0/uid 0x25 Since there is no regular pci address (as explained earlier) I think this is a mechanism to unique identify a pci function. We discussed both options how to model this in qemu, but maybe you have another even better idea how to bring this additional attributes to a qemu pci device. Thx for any help and new ideas ... Frank > > Alex >