On Fri, 17 Nov 2023, Volodymyr Babchuk wrote: > > I still think, no matter the BDF allocation scheme, that we should try > > to avoid as much as possible to have two different PCI Root Complex > > emulators. Ideally we would have only one PCI Root Complex emulated by > > Xen. Having 2 PCI Root Complexes both of them emulated by Xen would be > > tolerable but not ideal. > > But what is exactly wrong with this setup?
[...] > > The worst case I would like to avoid is to have > > two PCI Root Complexes, one emulated by Xen and one emulated by QEMU. > > This is how our setup works right now. If we have: - a single PCI Root Complex emulated in Xen - Xen is safety certified - individual Virtio devices emulated by QEMU with grants for memory We can go very far in terms of being able to use Virtio in safety use-cases. We might even be able to use Virtio (frontends) in a SafeOS. On the other hand if we put an additional Root Complex in QEMU: - we pay a price in terms of complexity of the codebase - we pay a price in terms of resource utilization - we have one additional problem in terms of using this setup with a SafeOS (one more device emulated by a non-safe component) Having 2 PCI Root Complexes both emulated in Xen is a middle ground solution because: - we still pay a price in terms of resource utilization - the code complexity goes up a bit but hopefully not by much - there is no impact on safety compared to the ideal scenario This is why I wrote that it is tolerable. > I agree that we need some way to provide static vBDF numbers. But I am > wondering what is the best way to do this. We need some entity that > manages and assigns those vBDFs. It should reside in Xen, because there > is Dom0less use case. Probably we need to extend > xen_domctl_assign_device so we can either request a free vBDF or a > specific vBDF. And in the first case, Xen should return assigned vBDF so > toolstack can give it to a backend, if PCI device is purely virtual. I think that would be fine.
