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 >>>>> <blasc...@linux.vnet.ibm.com>: >>>>> >>>>>> 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
