eve
eve copied to clipboard
lf-edge
Integrate the ACS override patch into the kernel and support new features
The initial patch: https://aur.archlinux.org/cgit/aur.git/tree/add-acs-overrides.patch?h=linux-vfio Tasks:
- Integrate into the EVE kernel
- Clean up the code
- Add a feature of overriding ACS by the BDF address
- Test passthrough on MF devs and topologies containing bridges/RCs
Hi guys. This is Denis Semakin. I have a number of questions. Let's move step by step.
Integrate into the EVE kernel
What is EVE kernel? Is it just a linux kernel for OS where EVE run or EVE's kernel? If it's a linux kernel then what version should I use?
Clean up the code.
No questions yet.
Add a feature of overriding ACS by the BDF address
Modify EVE's source code to apply this feature?
Test passthrough on MF devs and topologies containing bridges/RCs
May I ask what is MF devs and bridges/RCs?
What is EVE kernel?
The Linux kernel version used by EVE. There are 2 versions right now, both are built as packages.
Modify EVE's source code to apply this feature?
It will require some modifications to the kernel code.
what is MF devs and bridges/RCs
Multifunction devices and PCI/PCIe bridges and/or root complexes.
I have a little misunderstanding...
The initial patch: https://aur.archlinux.org/cgit/aur.git/tree/add-acs-overrides.patch?h=linux-vfio Integrate into the EVE kernel
But looks like it is already integrated. Have a look at https://github.com/lf-edge/eve/blob/master/pkg/kernel/patches-4.19.x/0047-pcie-acs-overrides.patch. Also one may find the description why this patch is differ from original patch in upstream.
Then my question is what should be integrated into EVE kernel?
I supposed that it was the initial patch.
EVE also has the 'new-kernel' package, 5.4.x which does not have this patch. In fact, the check for the ACS capability presence is not significant here (the spec mandates downstream switch ports and RC to support upstream redirection where applicable). The end goal is the ability to put arbitrary PCIe functions into separate IOMMU groups and to be able to create arbitrary virtual topologies containing those host devices.
The original patch dates back to kernel v3.16 and looks rather trivial
https://lkml.org/lkml/2013/5/30/513
It is not accepted into mainline kernel but still remains applicable to upsteam kernels with a few minor changes.
What would be a manifest evidence that the patch does the thing?
Yes, the patch is quite trivial, but it still needs to be tested with the kernel 5.4. As the next step, we can reimplement it in the same way as other ACS quirks, but with BDF addresses instead of user/device IDs. This will suit our needs as we have fixed PCIe topologies.
For testing, it would be OK to 1 - check that an arbitrary multifunction device's components end up in different IOMMU groups 2 - set up a VM config with a vIOMMU and assign different functions of a same MF device to it without resorting to hacks like a virtual PCIe2PCI bridge.
The issue is outdated, both kernel are patched with the acs override patch in question, no plans to modify the original patch (BDF addresses support), thus close.
