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

[Alexander Graf]

> Am 03.03.2015 um 09:06 schrieb Frank Blaschka <address@hidden>:
> 
>> 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?

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?

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
>