[libvirt] [PATCH v2 RESEND 00/12] PCI passthrough support on s390

[Yi Min Zhao]

在 2018/7/25 下午11:44, Andrea Bolognani 写道:
> On Wed, 2018-07-25 at 16:34 +0800, Yi Min Zhao wrote:
>> 在 2018/7/24 下午11:43, Andrea Bolognani 写道:
>>>>> More concrete questions: one of the zPCI test cases includes
>>>>>
>>>>>        <controller type='pci' index='1' model='pci-bridge'/>
>>>>>        <hostdev mode='subsystem' type='pci' managed='no'>
>>>>>          <driver name='vfio'/>
>>>>>          <source>
>>>>>            <address domain='0xffff' bus='0x00' slot='0x00' function='0x0'/>
>>>>>          </source>
>>>>>          <address type='pci' domain='0x0000' bus='0x01' slot='0x1f'
>>>>>                   function='0x0' uid='0xffff' fid='0xffffffff'/>
>>>>>        </hostdev>
>>>>>
>>>>> which translates to
>>>>>
>>>>>      -device zpci,uid=3,fid=2,target=pci.1,id=zpci3 \
>>>>>      -device pci-bridge,chassis_nr=1,id=pci.1,bus=pci.0,addr=0x1 \
>>>>>      -device zpci,uid=65535,fid=4294967295,target=hostdev0,id=zpci65535 \
>>>>>      -device vfio-pci,host=ffff:00:00.0,id=hostdev0,bus=pci.1,addr=0x1f \
>>>>>
>>>>> How does the pci-bridge controller show up in the guest, if at all?
>> Qemu hides pci-bridge devices and just exposes pci devices to the guest.
>> In above example, indeed, qemu will generate a pci-bridge device and it will
>> be existing in pci topology. But the guest can't see it. This is very
>> special.
> Yeah, that's kinda problematic as it violates the principle of least
> surprise... If s390 guests can only see a flat PCI topology, then we
> should find a way to reject bridges altogether instead of allowing
> the user to create them (or even create them automatically) only for
> them not to show up in the guest.
If we reject bridges, there would be only one pci bus that maximum
32 pci devices could be plugged to. This kind of limitation is more
problematic IMO.
>>>>> Do the bus= and addr= attributes of vfio-pci and pci-bridge in the
>>>>> example above matter eg. for migration purposes?
>> Do you mean we leave attribute generation for bus and addr to qemu?
> That would be the idea, but of course it can only work if the
> address of the underlying PCI device can change without affecting
> the guest in any way, including migration. If that's not the case,
> and the PCI address needs to be as stable as the IDs, then I don't
> think there's a way to avoid storing it in the guest XML, no matter
> how confusing that will end up looking.
>
I think it relies on pci base code. Although we don't expose pci address 
to the guest, any
pci device still exists PCI tree tolopogy in qemu. IIUC, this has effect 
on qemu process itself.
For example, if we hotplug a pci device permanently, it will be 
dynamically assigned with a
pci address, and this address might change after shutdown and start 
again the guest and also
might change in destination during migration.