From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:57954) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YR0S3-0007xC-I6 for qemu-devel@nongnu.org; Thu, 26 Feb 2015 10:34:12 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YR0S0-0006iF-8b for qemu-devel@nongnu.org; Thu, 26 Feb 2015 10:34:11 -0500 Received: from cantor2.suse.de ([195.135.220.15]:49664 helo=mx2.suse.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YR0S0-0006i6-1s for qemu-devel@nongnu.org; Thu, 26 Feb 2015 10:34:08 -0500 Message-ID: <54EF3CEE.5020008@suse.de> Date: Thu, 26 Feb 2015 16:34:06 +0100 From: Alexander Graf MIME-Version: 1.0 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> In-Reply-To: <20150226152701.GA31166@tuxmaker.boeblingen.de.ibm.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit 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: Frank Blaschka Cc: cornelia.huck@de.ibm.com, borntraeger@de.ibm.com, qemu-devel@nongnu.org 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? Alex