Re: [Qemu-devel] [PATCH RFC 1/1] s390x/pci: Extend pci representation by new zpci device

[Frank Blaschka <blaschka@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.
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
>