Re: [PATCH v4 1/2] xen-pciback: prepare for the split for stub and PV

[Juergen Gross]

On 27.09.21 09:35, Oleksandr Andrushchenko wrote:

On 27.09.21 10:26, Jan Beulich wrote:

On 27.09.2021 08:58, Oleksandr Andrushchenko wrote:

From: Oleksandr Andrushchenko <oleksandr_andrushche...@epam.com>

Currently PCI backend implements multiple functionalities at a time.
To name a few:
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.

Signed-off-by: Oleksandr Andrushchenko <oleksandr_andrushche...@epam.com>

---
Changes since v3:
- Move CONFIG_XEN_PCIDEV_STUB to the second patch

I'm afraid this wasn't fully done:

--- a/drivers/xen/xen-pciback/Makefile
+++ b/drivers/xen/xen-pciback/Makefile
@@ -1,5 +1,6 @@
   # SPDX-License-Identifier: GPL-2.0
   obj-$(CONFIG_XEN_PCIDEV_BACKEND) += xen-pciback.o
+obj-$(CONFIG_XEN_PCIDEV_STUB) += xen-pciback.o

While benign when added here, this addition still doesn't seem to
belong here.

My bad. So, it seems without CONFIG_XEN_PCIDEV_STUB the change seems

to be non-functional. With CONFIG_XEN_PCIDEV_STUB we fail to build on 32-bit

architectures...

What would be the preference here? Stefano suggested that we still define

CONFIG_XEN_PCIDEV_STUB, but in disabled state, e.g. we add tristate to it

in the second patch

Another option is just to squash the two patches.

Squashing would be fine for me.


Juergen

OpenPGP_0xB0DE9DD628BF132F.asc
Description: OpenPGP public key

OpenPGP_signature
Description: OpenPGP digital signature