Hi, Geert!
On 16.11.21 11:36, Geert Uytterhoeven wrote: > Hi Oleksandr, > > On Thu, Oct 28, 2021 at 8:15 AM Oleksandr Andrushchenko > <[email protected]> wrote: >> From: Oleksandr Andrushchenko <[email protected]> >> >> Xen-pciback driver was designed to be built for x86 only. But it >> can also be used by other architectures, e.g. Arm. >> >> Currently PCI backend implements multiple functionalities at a time, >> such as: >> 1. It is used as a database for assignable PCI devices, e.g. xl >> pci-assignable-{add|remove|list} manipulates that list. So, whenever >> the toolstack needs to know which PCI devices can be passed through >> it reads that from the relevant sysfs entries of the pciback. >> 2. It is used to hold the unbound PCI devices list, e.g. when passing >> through a PCI device it needs to be unbound from the relevant device >> driver and bound to pciback (strictly speaking it is not required >> that the device is bound to pciback, but pciback is again used as a >> database of the passed through PCI devices, so we can re-bind the >> devices back to their original drivers when guest domain shuts down) >> 3. Device reset for the devices being passed through >> 4. Para-virtualised use-cases support >> >> The para-virtualised part of the driver is not always needed as some >> architectures, e.g. Arm or x86 PVH Dom0, are not using backend-frontend >> model for PCI device passthrough. >> >> For such use-cases make the very first step in splitting the >> xen-pciback driver into two parts: Xen PCI stub and PCI PV backend >> drivers. >> >> For that add new configuration options CONFIG_XEN_PCI_STUB and >> CONFIG_XEN_PCIDEV_STUB, so the driver can be limited in its >> functionality, e.g. no support for para-virtualised scenario. >> x86 platform will continue using CONFIG_XEN_PCIDEV_BACKEND for the >> fully featured backend driver. >> >> Signed-off-by: Oleksandr Andrushchenko <[email protected]> >> Signed-off-by: Anastasiia Lukianenko <[email protected]> >> Reviewed-by: Stefano Stabellini <[email protected]> >> Reviewed-by: Juergen Gross <[email protected]> > Thanks for your patch, which is now commit a67efff28832a597 > ("xen-pciback: allow compiling on other archs than x86") > in v5.16-rc1. > >> --- a/drivers/xen/Kconfig >> +++ b/drivers/xen/Kconfig >> @@ -181,10 +181,34 @@ config SWIOTLB_XEN >> select DMA_OPS >> select SWIOTLB >> >> +config XEN_PCI_STUB >> + bool >> + >> +config XEN_PCIDEV_STUB >> + tristate "Xen PCI-device stub driver" >> + depends on PCI && !X86 && XEN >> + depends on XEN_BACKEND >> + select XEN_PCI_STUB >> + default m > Please note that this means "default y" if CONFIG_MODULES=n. > Perhaps this should be "default m if MODULES" instead? I don't really have strong opinion on this and will let Xen maintainers speak: @Boris, @Juergen what's your preference here? > >> + help >> + The PCI device stub driver provides limited version of the PCI >> + device backend driver without para-virtualized support for guests. >> + If you select this to be a module, you will need to make sure no >> + other driver has bound to the device(s) you want to make visible to >> + other guests. >> + >> + The "hide" parameter (only applicable if backend driver is compiled >> + into the kernel) allows you to bind the PCI devices to this module >> + from the default device drivers. The argument is the list of PCI >> BDFs: >> + xen-pciback.hide=(03:00.0)(04:00.0) >> + >> + If in doubt, say m. >> + >> config XEN_PCIDEV_BACKEND >> tristate "Xen PCI-device backend driver" >> depends on PCI && X86 && XEN >> depends on XEN_BACKEND >> + select XEN_PCI_STUB >> default m >> help >> The PCI device backend driver allows the kernel to export >> arbitrary > Gr{oetje,eeting}s, > > Geert Thank you, Oleksandr > > -- > Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- > [email protected] > > In personal conversations with technical people, I call myself a hacker. But > when I'm talking to journalists I just say "programmer" or something like > that. > -- Linus Torvalds
