From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:56082) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YStaW-0004DT-FU for qemu-devel@nongnu.org; Tue, 03 Mar 2015 15:38:45 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YStaS-0007CK-Dy for qemu-devel@nongnu.org; Tue, 03 Mar 2015 15:38:44 -0500 Received: from cantor2.suse.de ([195.135.220.15]:36905 helo=mx2.suse.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YStaS-0007BW-35 for qemu-devel@nongnu.org; Tue, 03 Mar 2015 15:38:40 -0500 Message-ID: <54F61BCD.9060409@suse.de> Date: Tue, 03 Mar 2015 21:38:37 +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> <54EF3CEE.5020008@suse.de> <20150303080631.GA20285@tuxmaker.boeblingen.de.ibm.com> <20150303132539.GA20144@tuxmaker.boeblingen.de.ibm.com> In-Reply-To: <20150303132539.GA20144@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 03.03.15 14:25, Frank Blaschka wrote: > On Tue, Mar 03, 2015 at 10:33:05AM +0100, Alexander Graf wrote: >> >> >> >>> Am 03.03.2015 um 09:06 schrieb Frank Blaschka : >>> >>>> 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. >> >> So they are arbitrary numbers? What uniqueness constraints do we have on them? > fid and uid must be unique within the same qemu. At a first look the numbers are > arbitrary but our configuration folks want explicitly define a particular fid and uid > to better support migration and pass-through scenarios. Well, at the end of the day you want to make sure they're identical on both sides, yes. >> IIUC you can only have a single pcie device behind a virtual "bus" anyway, so what if we just calculate uid and fid from the bus id? > I think this similar to the current implementation. We use the slot (idea for the future was > bus + slot) to generate uid and fid. But this is not flexible enough. As I said, our > configuration folks want to be able to specify fid and uid for the device. I don't see how this is different from what PPC does with its LIOBN which is a property of the PHB. Alex