[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] xen-pciback: allow compiling on other archs than x86



On 16.11.21 11:45, Oleksandr Andrushchenko wrote:
Hi, Geert!

On 16.11.21 11:36, Geert Uytterhoeven wrote:
Hi Oleksandr,

On Thu, Oct 28, 2021 at 8:15 AM Oleksandr Andrushchenko
<andr2000@xxxxxxxxx> wrote:
From: Oleksandr Andrushchenko <oleksandr_andrushchenko@xxxxxxxx>

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 <oleksandr_andrushchenko@xxxxxxxx>
Signed-off-by: Anastasiia Lukianenko <anastasiia_lukianenko@xxxxxxxx>
Reviewed-by: Stefano Stabellini <sstabellini@xxxxxxxxxx>
Reviewed-by: Juergen Gross <jgross@xxxxxxxx>
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?

TBH, I don't have any.

All other backends have no "default" line, so maybe the cleanest
solution would be to remove the "default" lines for XEN_PCIDEV_STUB
and XEN_PCIDEV_BACKEND, too?


+       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


Juergen

Attachment: OpenPGP_0xB0DE9DD628BF132F.asc
Description: OpenPGP public key

Attachment: OpenPGP_signature
Description: OpenPGP digital signature


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.