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

[Alexander Graf <agraf@suse.de>]

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