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. > 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.
> > Alex > > > 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 > > >
