From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:37835) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YTAtz-000668-Bd for qemu-devel@nongnu.org; Wed, 04 Mar 2015 10:08:00 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YTAtu-0003EQ-0B for qemu-devel@nongnu.org; Wed, 04 Mar 2015 10:07:59 -0500 Received: from e06smtp16.uk.ibm.com ([195.75.94.112]:50247) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YTAtt-0003DQ-N4 for qemu-devel@nongnu.org; Wed, 04 Mar 2015 10:07:53 -0500 Received: from /spool/local by e06smtp16.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Wed, 4 Mar 2015 15:07:50 -0000 Received: from b06cxnps3075.portsmouth.uk.ibm.com (d06relay10.portsmouth.uk.ibm.com [9.149.109.195]) by d06dlp01.portsmouth.uk.ibm.com (Postfix) with ESMTP id 1470217D8069 for ; Wed, 4 Mar 2015 15:08:07 +0000 (GMT) Received: from d06av08.portsmouth.uk.ibm.com (d06av08.portsmouth.uk.ibm.com [9.149.37.249]) by b06cxnps3075.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id t24F7lAP1704272 for ; Wed, 4 Mar 2015 15:07:47 GMT Received: from d06av08.portsmouth.uk.ibm.com (localhost [127.0.0.1]) by d06av08.portsmouth.uk.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id t24F7lup020879 for ; Wed, 4 Mar 2015 08:07:47 -0700 Date: Wed, 4 Mar 2015 16:07:46 +0100 From: Frank Blaschka Message-ID: <20150304150746.GA63486@tuxmaker.boeblingen.de.ibm.com> References: <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> <54F61BCD.9060409@suse.de> <20150304134421.GA54616@tuxmaker.boeblingen.de.ibm.com> <54F71B6B.6070909@suse.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <54F71B6B.6070909@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 Wed, Mar 04, 2015 at 03:49:15PM +0100, Alexander Graf wrote: > > > On 04.03.15 14:44, Frank Blaschka wrote: > > On Tue, Mar 03, 2015 at 09:38:37PM +0100, Alexander Graf wrote: > >> > >> > >> 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 > >> > > > > I played arround with the idea of having multiple host bridges and this worked well > > at least for static (non hotplug) configuration. In case I want to hotplug a host > > bridge I got following error: > > > > (qemu) device_add s390-pcihost,fid=8,uid=9 > > Bus 'main-system-bus' does not support hotplugging > > > > Is there anything I have to enable to support this? > > > > I have: has_dynamic_sysbus = 1 and cannot_instantiate_with_device_add_yet = false > > but this seems not to help for the hotplug case. > > Having s390 devices reside on sysbus is probably a bad idea. Instead, > they should be on an s390 specific bus which then can implement hotplug > easily. > > > Alex > Hm now I get lost ... Do you suggest we should implement a s390 specific device (which is not derived from TYPE_PCI_HOST_BRIDGE) but implements a pci bus so we can attach a pci device to this device?