On 14/12/2021 22.55, Tony Krowiak wrote:
On 12/13/21 11:11, Cornelia Huck wrote:
On Mon, Dec 13 2021, Harald Freudenberger <freude@xxxxxxxxxxxxx> wrote:
On 01.12.21 15:11, Thomas Huth wrote:
The crypto devices that we can use with the vfio_ap module are sitting
on the "ap" bus, not on the "vfio_ap" bus that the module defines
itself. With this change, the vfio_ap module now gets automatically
loaded if a supported crypto adapter is available in the host.
Signed-off-by: Thomas Huth <thuth@xxxxxxxxxx>
---
Note: Marked as "RFC" since I'm not 100% sure about it ...
please review carefully!
drivers/s390/crypto/vfio_ap_drv.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/s390/crypto/vfio_ap_drv.c
b/drivers/s390/crypto/vfio_ap_drv.c
index 4d2556bc7fe5..5580e40608a4 100644
--- a/drivers/s390/crypto/vfio_ap_drv.c
+++ b/drivers/s390/crypto/vfio_ap_drv.c
@@ -39,7 +39,7 @@ static struct ap_device_id ap_queue_ids[] = {
{ /* end of sibling */ },
};
-MODULE_DEVICE_TABLE(vfio_ap, ap_queue_ids);
+MODULE_DEVICE_TABLE(ap, ap_queue_ids);
/**
* vfio_ap_queue_dev_probe:
I had a chance to check this now.
First I have to apologize about the dispute with vfio devices appearing
on the ap bus.
That's not the case with this patch. As Connie states the
MODULE_DEVICE_TABLE() does not
change the parent of a device and vfio_ap_drv is a driver for ap devices
and thus
belongs to the ap bus anyway.
So what's left is that with this change the vfio_ap kernel module is
automatically loaded
when an ap device type 10-13 is recognized by the ap bus. So the
intention of the patch
is fulfilled.
Yet another kernel module which may occupy memory but will never get used
by most customers.
This may not be a problem but I had a glance at the list of kernel
modules loaded on my
LPAR with and without the patch and the difference is:
...
kvm 512000 1 vfio_ap
vfio_ap 28672 0
...
So the vfio_ap module has a dependency to the biggest kernel module ever
- kvm.
Do I need to say something more?
If this dependency is removed then I would not hesitate to accept this
patch. However
this is up to Tony as he is the maintainer of the vfio ap device driver.
I don't think you can drop the kvm reference, as the code in vfio-ap
obviously depends on it...
One possibility is simply blocking autoload of the module in userspace by
default, and only allow it to be loaded automatically when e.g. qemu-kvm
is installed on the system. This is obviously something that needs to be
decided by the distros.
(kvm might actually be autoloaded already, so autoloading vfio-ap would
not really make it worse.)
Of the vfio_ccw module is automatically loaded, then the kvm
module will also get loaded. I startup up a RHEL8.3 system and
sure enough, the vfio_ccw module is loaded along with the
kvm, vfio and mdev modules. If this is true for all distros, then
it wouldn't make much difference if the vfio_ap module is
autoloaded too.
I think I don't mind too much if we auto-load vfio-ap or not - but I think
we should make it consistent with vfio-ccw. So either auto-load both modules
(if the corresponding devices are available), or remove the
MODULE_DEVICE_TABLE() entries from both modules?
Thomas
