Go to file
Matthias Tafelmeier 765b05cdbd refer to uaccess to prevent build failure
Tackling following build glitch for 4.19 kernel:

/var/lib/dkms/vendor-reset/0.0.18/build/src/ioctl.c: In function ‘vendor_reset_ioctl_reset’:
/var/lib/dkms/vendor-reset/0.0.18/build/src/ioctl.c:34:7: error: implicit declaration of function ‘copy_from_user’; did you mean ‘sg_copy_from_buffer’? [-Werror=implicit-function-declaration]
   if (copy_from_user(&iodev, (void __user *)arg, sizeof(iodev)))
       ^~~~~~~~~~~~~~
       sg_copy_from_buffer
cc1: some warnings being treated as errors
make[4]: *** [/usr/src/linux-headers-4.19.0-12-common/scripts/Makefile.build:308: /var/lib/dkms/vendor-reset/0.0.18/build/src/ioctl.o] Error 1
make[4]: *** Waiting for unfinished jobs....
make[3]: *** [/usr/src/linux-headers-4.19.0-12-common/Makefile:1565: _module_/var/lib/dkms/vendor-reset/0.0.18/build] Error 2
make[2]: *** [Makefile:146: sub-make] Error 2
make[1]: *** [Makefile:8: all] Error 2
make[1]: Leaving directory '/usr/src/linux-headers-4.19.0-12-amd64'
make: *** [Makefile:8: build] Error 2
2020-12-23 05:38:44 +11:00
include [core] refactored to centralize the lookup and reset code 2020-11-12 08:16:51 +11:00
src refer to uaccess to prevent build failure 2020-12-23 05:38:44 +11:00
userspace [core] refactored to centralize the lookup and reset code 2020-11-12 08:16:51 +11:00
.gitignore AMD: I think that's Navi. 2020-11-10 09:48:36 -06:00
Kbuild [core] disable building of the userspace reset for now 2020-11-12 08:16:51 +11:00
LICENSE Initial module framework 2020-10-31 18:00:00 +11:00
Makefile [core] since hook is the default, add NOHOOK argument to Make 2020-11-18 17:42:46 -06:00
README.md [doc] added information about early loading of the module 2020-11-15 12:20:14 +11:00
dkms.conf [core] release dkms version 0.0.18 2020-11-20 13:17:03 -06:00

README.md

Vendor Reset

The goal of this project is to provide a kernel module that is capable of resetting hardware devices into a state where they can be re-initialized or passed through into a virtual machine (VFIO). While it would be great to have these in the kernel as PCI quirks, some of the reset procedures are very complex and would never be accepted as a quirk (ie AMD Vega 10).

By providing this as an out of tree kernel module, vendors will be able to easily create pull requests to add functionality to this module, and users will be able to easily update this module without requiring a complete kernel rebuild.

Patching the kernel

TL;DR - No patching required.

This module has been written to use ftrace to hook pci_dev_specific_reset, allowing it to handle device resets directly without patching the running kernel. Simply modprobing the module is enough to enable the reset routines for all supported hardware.

Requirements

Ensure your kernel has the following options enabled:

CONFIG_FTRACE=y
CONFIG_KPROBES=y
CONFIG_PCI_QUIRKS=y
CONFIG_KALLSYMS=y
CONFIG_KALLSYMS_ALL=y
CONFIG_FUNCTION_TRACER=y

Installing

This module can be installed either using the standard make, make install pattern, or through dkms (recommended).

dkms install .

Usage

Either modprobe vendor-reset or add the device to the appropriate place to load it at system boot, such as /etc/modules (Debian). Consult your distribution's documentation as to the best way to perform this.

**NOTE: ** This module must be loaded EARLY, the default reset the kernel will try to perform completely breaks the GPU which this module can not recover from. Please consult your distributions documentation on how to do this, for most however it will be as simple as adding vendor-reset to /etc/modules and updating your initrd.

Supported Devices

Vendor Family Common Name(s)
AMD Polaris 10
AMD Polaris 11
AMD Polaris 12
AMD Vega 10 Vega 56/64
AMD Vega 20 Radeon VII
AMD Navi 10 5600XT, 5700, 5700XT
AMD Navi 12 Pro 5600M
AMD Navi 14 Pro 5300, RX 5300, 5500XT

Developing

If you are a vendor intending to add support for your device to this project please first consider two things:

  1. Can you fix your hardware/firmware to reset correctly using FLR or a BUS reset?
  2. Is the reset simple enough that it should really be a kernel pci quirk (see: kernel/drivers/pci/quirk.c)?

If you answer yes to either of these questions this project is not for you.