[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH v4 1/2] xen-pciback: prepare for the split for stub and PV
On 28.09.21 09:24, Oleksandr Andrushchenko wrote:
On 28.09.21 10:20, Juergen Gross wrote:
On 28.09.21 09:17, Oleksandr Andrushchenko wrote:
On 28.09.21 09:59, Juergen Gross wrote:
On 28.09.21 08:56, Oleksandr Andrushchenko wrote:
On 28.09.21 09:42, Jan Beulich wrote:
On 28.09.2021 06:18, Stefano Stabellini wrote:
On Mon, 27 Sep 2021, Juergen Gross wrote:
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_andrushchenko@xxxxxxxx>
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_andrushchenko@xxxxxxxx>
---
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.
It is fine for me to squash the two patches.
But in any case, wouldn't it be better to modify that specific change to:
diff --git a/drivers/xen/xen-pciback/Makefile b/drivers/xen/xen-pciback/Makefile
index e2cb376444a6..e23c758b85ae 100644
--- a/drivers/xen/xen-pciback/Makefile
+++ b/drivers/xen/xen-pciback/Makefile
@@ -1,6 +1,5 @@
# SPDX-License-Identifier: GPL-2.0
-obj-$(CONFIG_XEN_PCIDEV_BACKEND) += xen-pciback.o
-obj-$(CONFIG_XEN_PCIDEV_STUB) += xen-pciback.o
+obj-$(CONFIG_XEN_PCI_STUB) += xen-pciback.o
But that wouldn't allow the driver to be a module anymore, would it?
Exactly. I forgot that when playing with module/built-in I was not able
to control that anymore because CONFIG_XEN_PCI_STUB will always be
in "y" state, thus even if you have CONFIG_XEN_PCIDEV_BACKEND=m
you won't be able to build it as module. So, I will probably put a comment
about that in the Makefile explaining the need for
obj-$(CONFIG_XEN_PCIDEV_BACKEND) += xen-pciback.o
obj-$(CONFIG_XEN_PCIDEV_STUB) += xen-pciback.o
In case the real split between both parts of xen-pciback is done this
will be needed anyway.
Yes, it will
So, I'll put a comment in the Makefile:
# N.B. This cannot be expressed with a single line using CONFIG_XEN_PCI_STUB
# as it always remains in "y" state, thus preventing the driver to be built as
# a module.
obj-$(CONFIG_XEN_PCIDEV_BACKEND) += xen-pciback.o
obj-$(CONFIG_XEN_PCIDEV_STUB) += xen-pciback.o
Will this be ok or needs some re-wording?
I'd add that CONFIG_XEN_PCIDEV_BACKEND and CONFIG_XEN_PCIDEV_STUB are
mutually exclusive.
# N.B. The below cannot be expressed with a single line using
# CONFIG_XEN_PCI_STUB as it always remains in "y" state,
# thus preventing the driver to be built as a module.
# Please note, that CONFIG_XEN_PCIDEV_BACKEND and
# CONFIG_XEN_PCIDEV_STUB are mutually exclusive.
obj-$(CONFIG_XEN_PCIDEV_BACKEND) += xen-pciback.o
obj-$(CONFIG_XEN_PCIDEV_STUB) += xen-pciback.o
Yes, that's fine.
Juergen
Attachment:
OpenPGP_0xB0DE9DD628BF132F.asc
Description: OpenPGP public key
Attachment:
OpenPGP_signature
Description: OpenPGP digital signature
|
