* [PATCH RFC 01/18] rust: drm: ioctl: Add DRM ioctl abstraction
2023-03-07 14:25 [PATCH RFC 00/18] Rust DRM subsystem abstractions (& preview AGX driver) Asahi Lina
@ 2023-03-07 14:25 ` Asahi Lina
2023-03-07 14:48 ` Karol Herbst
` (3 more replies)
2023-03-07 14:25 ` [PATCH RFC 02/18] rust: drm: Add Device and Driver abstractions Asahi Lina
` (17 subsequent siblings)
18 siblings, 4 replies; 122+ messages in thread
From: Asahi Lina @ 2023-03-07 14:25 UTC (permalink / raw)
To: Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
David Airlie, Daniel Vetter, Miguel Ojeda, Alex Gaynor,
Wedson Almeida Filho, Boqun Feng, Gary Guo, Björn Roy Baron,
Sumit Semwal, Christian König, Luben Tuikov,
Jarkko Sakkinen, Dave Hansen
Cc: Alyssa Rosenzweig, Karol Herbst, Ella Stanforth, Faith Ekstrand,
Mary, linux-kernel, dri-devel, rust-for-linux, linux-media,
linaro-mm-sig, linux-sgx, asahi, Asahi Lina
DRM drivers need to be able to declare which driver-specific ioctls they
support. This abstraction adds the required types and a helper macro to
generate the ioctl definition inside the DRM driver.
Note that this macro is not usable until further bits of the
abstraction are in place (but it will not fail to compile on its own, if
not called).
Signed-off-by: Asahi Lina <lina@asahilina.net>
---
drivers/gpu/drm/Kconfig | 7 ++
rust/bindings/bindings_helper.h | 2 +
rust/kernel/drm/ioctl.rs | 147 ++++++++++++++++++++++++++++++++++++++++
rust/kernel/drm/mod.rs | 5 ++
rust/kernel/lib.rs | 2 +
5 files changed, 163 insertions(+)
diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index dc0f94f02a82..dab8f0f9aa96 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -27,6 +27,13 @@ menuconfig DRM
details. You should also select and configure AGP
(/dev/agpgart) support if it is available for your platform.
+# Rust abstractions cannot be built as modules currently, so force them as
+# bool by using these intermediate symbols. In the future these could be
+# tristate once abstractions themselves can be built as modules.
+config RUST_DRM
+ bool "Rust support for the DRM subsystem"
+ depends on DRM=y
+
config DRM_MIPI_DBI
tristate
depends on DRM
diff --git a/rust/bindings/bindings_helper.h b/rust/bindings/bindings_helper.h
index 91bb7906ca5a..2687bef1676f 100644
--- a/rust/bindings/bindings_helper.h
+++ b/rust/bindings/bindings_helper.h
@@ -6,6 +6,7 @@
* Sorted alphabetically.
*/
+#include <drm/drm_ioctl.h>
#include <linux/delay.h>
#include <linux/device.h>
#include <linux/dma-mapping.h>
@@ -23,6 +24,7 @@
#include <linux/sysctl.h>
#include <linux/timekeeping.h>
#include <linux/xarray.h>
+#include <uapi/drm/drm.h>
/* `bindgen` gets confused at certain things. */
const gfp_t BINDINGS_GFP_KERNEL = GFP_KERNEL;
diff --git a/rust/kernel/drm/ioctl.rs b/rust/kernel/drm/ioctl.rs
new file mode 100644
index 000000000000..10304efbd5f1
--- /dev/null
+++ b/rust/kernel/drm/ioctl.rs
@@ -0,0 +1,147 @@
+// SPDX-License-Identifier: GPL-2.0 OR MIT
+#![allow(non_snake_case)]
+
+//! DRM IOCTL definitions.
+//!
+//! C header: [`include/linux/drm/drm_ioctl.h`](../../../../include/linux/drm/drm_ioctl.h)
+
+use crate::ioctl;
+
+const BASE: u32 = bindings::DRM_IOCTL_BASE as u32;
+
+/// Construct a DRM ioctl number with no argument.
+pub const fn IO(nr: u32) -> u32 {
+ ioctl::_IO(BASE, nr)
+}
+
+/// Construct a DRM ioctl number with a read-only argument.
+pub const fn IOR<T>(nr: u32) -> u32 {
+ ioctl::_IOR::<T>(BASE, nr)
+}
+
+/// Construct a DRM ioctl number with a write-only argument.
+pub const fn IOW<T>(nr: u32) -> u32 {
+ ioctl::_IOW::<T>(BASE, nr)
+}
+
+/// Construct a DRM ioctl number with a read-write argument.
+pub const fn IOWR<T>(nr: u32) -> u32 {
+ ioctl::_IOWR::<T>(BASE, nr)
+}
+
+/// Descriptor type for DRM ioctls. Use the `declare_drm_ioctls!{}` macro to construct them.
+pub type DrmIoctlDescriptor = bindings::drm_ioctl_desc;
+
+/// This is for ioctl which are used for rendering, and require that the file descriptor is either
+/// for a render node, or if it’s a legacy/primary node, then it must be authenticated.
+pub const AUTH: u32 = bindings::drm_ioctl_flags_DRM_AUTH;
+
+/// This must be set for any ioctl which can change the modeset or display state. Userspace must
+/// call the ioctl through a primary node, while it is the active master.
+///
+/// Note that read-only modeset ioctl can also be called by unauthenticated clients, or when a
+/// master is not the currently active one.
+pub const MASTER: u32 = bindings::drm_ioctl_flags_DRM_MASTER;
+
+/// Anything that could potentially wreak a master file descriptor needs to have this flag set.
+///
+/// Current that’s only for the SETMASTER and DROPMASTER ioctl, which e.g. logind can call to force
+/// a non-behaving master (display compositor) into compliance.
+///
+/// This is equivalent to callers with the SYSADMIN capability.
+pub const ROOT_ONLY: u32 = bindings::drm_ioctl_flags_DRM_ROOT_ONLY;
+
+/// Whether drm_ioctl_desc.func should be called with the DRM BKL held or not. Enforced as the
+/// default for all modern drivers, hence there should never be a need to set this flag.
+///
+/// Do not use anywhere else than for the VBLANK_WAIT IOCTL, which is the only legacy IOCTL which
+/// needs this.
+pub const UNLOCKED: u32 = bindings::drm_ioctl_flags_DRM_UNLOCKED;
+
+/// This is used for all ioctl needed for rendering only, for drivers which support render nodes.
+/// This should be all new render drivers, and hence it should be always set for any ioctl with
+/// `AUTH` set. Note though that read-only query ioctl might have this set, but have not set
+/// DRM_AUTH because they do not require authentication.
+pub const RENDER_ALLOW: u32 = bindings::drm_ioctl_flags_DRM_RENDER_ALLOW;
+
+/// Declare the DRM ioctls for a driver.
+///
+/// Each entry in the list should have the form:
+///
+/// `(ioctl_number, argument_type, flags, user_callback),`
+///
+/// `argument_type` is the type name within the `bindings` crate.
+/// `user_callback` should have the following prototype:
+///
+/// ```
+/// fn foo(device: &kernel::drm::device::Device<Self>,
+/// data: &mut bindings::argument_type,
+/// file: &kernel::drm::file::File<Self::File>,
+/// )
+/// ```
+/// where `Self` is the drm::drv::Driver implementation these ioctls are being declared within.
+///
+/// # Examples
+///
+/// ```
+/// kernel::declare_drm_ioctls! {
+/// (FOO_GET_PARAM, drm_foo_get_param, ioctl::RENDER_ALLOW, my_get_param_handler),
+/// }
+/// ```
+///
+#[macro_export]
+macro_rules! declare_drm_ioctls {
+ ( $(($cmd:ident, $struct:ident, $flags:expr, $func:expr)),* $(,)? ) => {
+ const IOCTLS: &'static [$crate::drm::ioctl::DrmIoctlDescriptor] = {
+ const _:() = {
+ let i: u32 = $crate::bindings::DRM_COMMAND_BASE;
+ // Assert that all the IOCTLs are in the right order and there are no gaps,
+ // and that the sizeof of the specified type is correct.
+ $(
+ let cmd: u32 = $crate::macros::concat_idents!($crate::bindings::DRM_IOCTL_, $cmd);
+ ::core::assert!(i == $crate::ioctl::_IOC_NR(cmd));
+ ::core::assert!(core::mem::size_of::<$crate::bindings::$struct>() == $crate::ioctl::_IOC_SIZE(cmd));
+ let i: u32 = i + 1;
+ )*
+ };
+
+ let ioctls = &[$(
+ $crate::bindings::drm_ioctl_desc {
+ cmd: $crate::macros::concat_idents!($crate::bindings::DRM_IOCTL_, $cmd) as u32,
+ func: {
+ #[allow(non_snake_case)]
+ unsafe extern "C" fn $cmd(
+ raw_dev: *mut $crate::bindings::drm_device,
+ raw_data: *mut ::core::ffi::c_void,
+ raw_file_priv: *mut $crate::bindings::drm_file,
+ ) -> core::ffi::c_int {
+ // SAFETY: We never drop this, and the DRM core ensures the device lives
+ // while callbacks are being called.
+ //
+ // FIXME: Currently there is nothing enforcing that the types of the
+ // dev/file match the current driver these ioctls are being declared
+ // for, and it's not clear how to enforce this within the type system.
+ let dev = ::core::mem::ManuallyDrop::new(unsafe {
+ $crate::drm::device::Device::from_raw(raw_dev)
+ });
+ // SAFETY: This is just the ioctl argument, which hopefully has the right type
+ // (we've done our best checking the size).
+ let data = unsafe { &mut *(raw_data as *mut $crate::bindings::$struct) };
+ // SAFETY: This is just the DRM file structure
+ let file = unsafe { $crate::drm::file::File::from_raw(raw_file_priv) };
+
+ match $func(&*dev, data, &file) {
+ Err(e) => e.to_kernel_errno(),
+ Ok(i) => i.try_into().unwrap_or(ERANGE.to_kernel_errno()),
+ }
+ }
+ Some($cmd)
+ },
+ flags: $flags,
+ name: $crate::c_str!(::core::stringify!($cmd)).as_char_ptr(),
+ }
+ ),*];
+ ioctls
+ };
+ };
+}
diff --git a/rust/kernel/drm/mod.rs b/rust/kernel/drm/mod.rs
new file mode 100644
index 000000000000..9ec6d7cbcaf3
--- /dev/null
+++ b/rust/kernel/drm/mod.rs
@@ -0,0 +1,5 @@
+// SPDX-License-Identifier: GPL-2.0 OR MIT
+
+//! DRM subsystem abstractions.
+
+pub mod ioctl;
diff --git a/rust/kernel/lib.rs b/rust/kernel/lib.rs
index 7903490816bf..cb23d24c6718 100644
--- a/rust/kernel/lib.rs
+++ b/rust/kernel/lib.rs
@@ -37,6 +37,8 @@ mod build_assert;
pub mod delay;
pub mod device;
pub mod driver;
+#[cfg(CONFIG_RUST_DRM)]
+pub mod drm;
pub mod error;
pub mod io_buffer;
pub mod io_mem;
--
2.35.1
^ permalink raw reply related [flat|nested] 122+ messages in thread* Re: [PATCH RFC 01/18] rust: drm: ioctl: Add DRM ioctl abstraction
2023-03-07 14:25 ` [PATCH RFC 01/18] rust: drm: ioctl: Add DRM ioctl abstraction Asahi Lina
@ 2023-03-07 14:48 ` Karol Herbst
2023-03-07 14:51 ` Karol Herbst
2023-03-07 15:32 ` Maíra Canal
` (2 subsequent siblings)
3 siblings, 1 reply; 122+ messages in thread
From: Karol Herbst @ 2023-03-07 14:48 UTC (permalink / raw)
To: Asahi Lina
Cc: Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
David Airlie, Daniel Vetter, Miguel Ojeda, Alex Gaynor,
Wedson Almeida Filho, Boqun Feng, Gary Guo, Björn Roy Baron,
Sumit Semwal, Christian König, Luben Tuikov,
Jarkko Sakkinen, Dave Hansen, linaro-mm-sig, rust-for-linux,
asahi, linux-kernel, dri-devel, Mary, Alyssa Rosenzweig,
linux-sgx, Ella Stanforth, Faith Ekstrand, linux-media
On Tue, Mar 7, 2023 at 3:27 PM Asahi Lina <lina@asahilina.net> wrote:
>
> DRM drivers need to be able to declare which driver-specific ioctls they
> support. This abstraction adds the required types and a helper macro to
> generate the ioctl definition inside the DRM driver.
>
> Note that this macro is not usable until further bits of the
> abstraction are in place (but it will not fail to compile on its own, if
> not called).
>
> Signed-off-by: Asahi Lina <lina@asahilina.net>
> ---
> drivers/gpu/drm/Kconfig | 7 ++
> rust/bindings/bindings_helper.h | 2 +
> rust/kernel/drm/ioctl.rs | 147 ++++++++++++++++++++++++++++++++++++++++
> rust/kernel/drm/mod.rs | 5 ++
> rust/kernel/lib.rs | 2 +
> 5 files changed, 163 insertions(+)
>
> diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
> index dc0f94f02a82..dab8f0f9aa96 100644
> --- a/drivers/gpu/drm/Kconfig
> +++ b/drivers/gpu/drm/Kconfig
> @@ -27,6 +27,13 @@ menuconfig DRM
> details. You should also select and configure AGP
> (/dev/agpgart) support if it is available for your platform.
>
> +# Rust abstractions cannot be built as modules currently, so force them as
> +# bool by using these intermediate symbols. In the future these could be
> +# tristate once abstractions themselves can be built as modules.
> +config RUST_DRM
> + bool "Rust support for the DRM subsystem"
> + depends on DRM=y
> +
> config DRM_MIPI_DBI
> tristate
> depends on DRM
> diff --git a/rust/bindings/bindings_helper.h b/rust/bindings/bindings_helper.h
> index 91bb7906ca5a..2687bef1676f 100644
> --- a/rust/bindings/bindings_helper.h
> +++ b/rust/bindings/bindings_helper.h
> @@ -6,6 +6,7 @@
> * Sorted alphabetically.
> */
>
> +#include <drm/drm_ioctl.h>
> #include <linux/delay.h>
> #include <linux/device.h>
> #include <linux/dma-mapping.h>
> @@ -23,6 +24,7 @@
> #include <linux/sysctl.h>
> #include <linux/timekeeping.h>
> #include <linux/xarray.h>
> +#include <uapi/drm/drm.h>
>
might make more sense to add this chunk to the patch actually needing it
> /* `bindgen` gets confused at certain things. */
> const gfp_t BINDINGS_GFP_KERNEL = GFP_KERNEL;
> diff --git a/rust/kernel/drm/ioctl.rs b/rust/kernel/drm/ioctl.rs
> new file mode 100644
> index 000000000000..10304efbd5f1
> --- /dev/null
> +++ b/rust/kernel/drm/ioctl.rs
> @@ -0,0 +1,147 @@
> +// SPDX-License-Identifier: GPL-2.0 OR MIT
> +#![allow(non_snake_case)]
> +
> +//! DRM IOCTL definitions.
> +//!
> +//! C header: [`include/linux/drm/drm_ioctl.h`](../../../../include/linux/drm/drm_ioctl.h)
> +
> +use crate::ioctl;
> +
> +const BASE: u32 = bindings::DRM_IOCTL_BASE as u32;
> +
> +/// Construct a DRM ioctl number with no argument.
> +pub const fn IO(nr: u32) -> u32 {
> + ioctl::_IO(BASE, nr)
> +}
> +
> +/// Construct a DRM ioctl number with a read-only argument.
> +pub const fn IOR<T>(nr: u32) -> u32 {
> + ioctl::_IOR::<T>(BASE, nr)
> +}
> +
> +/// Construct a DRM ioctl number with a write-only argument.
> +pub const fn IOW<T>(nr: u32) -> u32 {
> + ioctl::_IOW::<T>(BASE, nr)
> +}
> +
> +/// Construct a DRM ioctl number with a read-write argument.
> +pub const fn IOWR<T>(nr: u32) -> u32 {
> + ioctl::_IOWR::<T>(BASE, nr)
> +}
> +
> +/// Descriptor type for DRM ioctls. Use the `declare_drm_ioctls!{}` macro to construct them.
> +pub type DrmIoctlDescriptor = bindings::drm_ioctl_desc;
> +
> +/// This is for ioctl which are used for rendering, and require that the file descriptor is either
> +/// for a render node, or if it’s a legacy/primary node, then it must be authenticated.
> +pub const AUTH: u32 = bindings::drm_ioctl_flags_DRM_AUTH;
> +
> +/// This must be set for any ioctl which can change the modeset or display state. Userspace must
> +/// call the ioctl through a primary node, while it is the active master.
> +///
> +/// Note that read-only modeset ioctl can also be called by unauthenticated clients, or when a
> +/// master is not the currently active one.
> +pub const MASTER: u32 = bindings::drm_ioctl_flags_DRM_MASTER;
> +
> +/// Anything that could potentially wreak a master file descriptor needs to have this flag set.
> +///
> +/// Current that’s only for the SETMASTER and DROPMASTER ioctl, which e.g. logind can call to force
> +/// a non-behaving master (display compositor) into compliance.
> +///
> +/// This is equivalent to callers with the SYSADMIN capability.
> +pub const ROOT_ONLY: u32 = bindings::drm_ioctl_flags_DRM_ROOT_ONLY;
> +
> +/// Whether drm_ioctl_desc.func should be called with the DRM BKL held or not. Enforced as the
> +/// default for all modern drivers, hence there should never be a need to set this flag.
> +///
> +/// Do not use anywhere else than for the VBLANK_WAIT IOCTL, which is the only legacy IOCTL which
> +/// needs this.
> +pub const UNLOCKED: u32 = bindings::drm_ioctl_flags_DRM_UNLOCKED;
> +
> +/// This is used for all ioctl needed for rendering only, for drivers which support render nodes.
> +/// This should be all new render drivers, and hence it should be always set for any ioctl with
> +/// `AUTH` set. Note though that read-only query ioctl might have this set, but have not set
> +/// DRM_AUTH because they do not require authentication.
> +pub const RENDER_ALLOW: u32 = bindings::drm_ioctl_flags_DRM_RENDER_ALLOW;
> +
> +/// Declare the DRM ioctls for a driver.
> +///
> +/// Each entry in the list should have the form:
> +///
> +/// `(ioctl_number, argument_type, flags, user_callback),`
> +///
> +/// `argument_type` is the type name within the `bindings` crate.
> +/// `user_callback` should have the following prototype:
> +///
> +/// ```
> +/// fn foo(device: &kernel::drm::device::Device<Self>,
> +/// data: &mut bindings::argument_type,
> +/// file: &kernel::drm::file::File<Self::File>,
> +/// )
> +/// ```
> +/// where `Self` is the drm::drv::Driver implementation these ioctls are being declared within.
> +///
> +/// # Examples
> +///
> +/// ```
> +/// kernel::declare_drm_ioctls! {
> +/// (FOO_GET_PARAM, drm_foo_get_param, ioctl::RENDER_ALLOW, my_get_param_handler),
> +/// }
I am wondering.. couldn't we make it a proc_macro and just tag all the
functions instead? Though I also see the point of having a central
list of all ioctls... Maybe we should have some higher level
discussions around on _how_ we want things to look like.
> +/// ```
> +///
> +#[macro_export]
> +macro_rules! declare_drm_ioctls {
> + ( $(($cmd:ident, $struct:ident, $flags:expr, $func:expr)),* $(,)? ) => {
> + const IOCTLS: &'static [$crate::drm::ioctl::DrmIoctlDescriptor] = {
> + const _:() = {
> + let i: u32 = $crate::bindings::DRM_COMMAND_BASE;
> + // Assert that all the IOCTLs are in the right order and there are no gaps,
> + // and that the sizeof of the specified type is correct.
> + $(
> + let cmd: u32 = $crate::macros::concat_idents!($crate::bindings::DRM_IOCTL_, $cmd);
> + ::core::assert!(i == $crate::ioctl::_IOC_NR(cmd));
> + ::core::assert!(core::mem::size_of::<$crate::bindings::$struct>() == $crate::ioctl::_IOC_SIZE(cmd));
::core::mem::size_of
> + let i: u32 = i + 1;
> + )*
> + };
> +
> + let ioctls = &[$(
> + $crate::bindings::drm_ioctl_desc {
> + cmd: $crate::macros::concat_idents!($crate::bindings::DRM_IOCTL_, $cmd) as u32,
> + func: {
> + #[allow(non_snake_case)]
> + unsafe extern "C" fn $cmd(
> + raw_dev: *mut $crate::bindings::drm_device,
> + raw_data: *mut ::core::ffi::c_void,
> + raw_file_priv: *mut $crate::bindings::drm_file,
> + ) -> core::ffi::c_int {
::core
> + // SAFETY: We never drop this, and the DRM core ensures the device lives
> + // while callbacks are being called.
> + //
> + // FIXME: Currently there is nothing enforcing that the types of the
> + // dev/file match the current driver these ioctls are being declared
> + // for, and it's not clear how to enforce this within the type system.
> + let dev = ::core::mem::ManuallyDrop::new(unsafe {
> + $crate::drm::device::Device::from_raw(raw_dev)
> + });
> + // SAFETY: This is just the ioctl argument, which hopefully has the right type
> + // (we've done our best checking the size).
> + let data = unsafe { &mut *(raw_data as *mut $crate::bindings::$struct) };
> + // SAFETY: This is just the DRM file structure
> + let file = unsafe { $crate::drm::file::File::from_raw(raw_file_priv) };
> +
> + match $func(&*dev, data, &file) {
> + Err(e) => e.to_kernel_errno(),
> + Ok(i) => i.try_into().unwrap_or(ERANGE.to_kernel_errno()),
need to specify the namespace on ERANGE, no?
> + }
> + }
> + Some($cmd)
> + },
> + flags: $flags,
> + name: $crate::c_str!(::core::stringify!($cmd)).as_char_ptr(),
> + }
> + ),*];
> + ioctls
> + };
> + };
> +}
> diff --git a/rust/kernel/drm/mod.rs b/rust/kernel/drm/mod.rs
> new file mode 100644
> index 000000000000..9ec6d7cbcaf3
> --- /dev/null
> +++ b/rust/kernel/drm/mod.rs
> @@ -0,0 +1,5 @@
> +// SPDX-License-Identifier: GPL-2.0 OR MIT
> +
> +//! DRM subsystem abstractions.
> +
> +pub mod ioctl;
> diff --git a/rust/kernel/lib.rs b/rust/kernel/lib.rs
> index 7903490816bf..cb23d24c6718 100644
> --- a/rust/kernel/lib.rs
> +++ b/rust/kernel/lib.rs
> @@ -37,6 +37,8 @@ mod build_assert;
> pub mod delay;
> pub mod device;
> pub mod driver;
> +#[cfg(CONFIG_RUST_DRM)]
> +pub mod drm;
> pub mod error;
> pub mod io_buffer;
> pub mod io_mem;
>
> --
> 2.35.1
>
^ permalink raw reply [flat|nested] 122+ messages in thread* Re: [PATCH RFC 01/18] rust: drm: ioctl: Add DRM ioctl abstraction
2023-03-07 14:48 ` Karol Herbst
@ 2023-03-07 14:51 ` Karol Herbst
0 siblings, 0 replies; 122+ messages in thread
From: Karol Herbst @ 2023-03-07 14:51 UTC (permalink / raw)
To: Asahi Lina
Cc: Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
David Airlie, Daniel Vetter, Miguel Ojeda, Alex Gaynor,
Wedson Almeida Filho, Boqun Feng, Gary Guo, Björn Roy Baron,
Sumit Semwal, Christian König, Luben Tuikov,
Jarkko Sakkinen, Dave Hansen, linaro-mm-sig, rust-for-linux,
asahi, linux-kernel, dri-devel, Mary, Alyssa Rosenzweig,
linux-sgx, Ella Stanforth, Faith Ekstrand, linux-media
On Tue, Mar 7, 2023 at 3:48 PM Karol Herbst <kherbst@redhat.com> wrote:
>
> On Tue, Mar 7, 2023 at 3:27 PM Asahi Lina <lina@asahilina.net> wrote:
> >
> > DRM drivers need to be able to declare which driver-specific ioctls they
> > support. This abstraction adds the required types and a helper macro to
> > generate the ioctl definition inside the DRM driver.
> >
> > Note that this macro is not usable until further bits of the
> > abstraction are in place (but it will not fail to compile on its own, if
> > not called).
> >
> > Signed-off-by: Asahi Lina <lina@asahilina.net>
> > ---
> > drivers/gpu/drm/Kconfig | 7 ++
> > rust/bindings/bindings_helper.h | 2 +
> > rust/kernel/drm/ioctl.rs | 147 ++++++++++++++++++++++++++++++++++++++++
> > rust/kernel/drm/mod.rs | 5 ++
> > rust/kernel/lib.rs | 2 +
> > 5 files changed, 163 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
> > index dc0f94f02a82..dab8f0f9aa96 100644
> > --- a/drivers/gpu/drm/Kconfig
> > +++ b/drivers/gpu/drm/Kconfig
> > @@ -27,6 +27,13 @@ menuconfig DRM
> > details. You should also select and configure AGP
> > (/dev/agpgart) support if it is available for your platform.
> >
> > +# Rust abstractions cannot be built as modules currently, so force them as
> > +# bool by using these intermediate symbols. In the future these could be
> > +# tristate once abstractions themselves can be built as modules.
> > +config RUST_DRM
> > + bool "Rust support for the DRM subsystem"
> > + depends on DRM=y
> > +
> > config DRM_MIPI_DBI
> > tristate
> > depends on DRM
> > diff --git a/rust/bindings/bindings_helper.h b/rust/bindings/bindings_helper.h
> > index 91bb7906ca5a..2687bef1676f 100644
> > --- a/rust/bindings/bindings_helper.h
> > +++ b/rust/bindings/bindings_helper.h
> > @@ -6,6 +6,7 @@
> > * Sorted alphabetically.
> > */
> >
> > +#include <drm/drm_ioctl.h>
> > #include <linux/delay.h>
> > #include <linux/device.h>
> > #include <linux/dma-mapping.h>
> > @@ -23,6 +24,7 @@
> > #include <linux/sysctl.h>
> > #include <linux/timekeeping.h>
> > #include <linux/xarray.h>
> > +#include <uapi/drm/drm.h>
> >
>
> might make more sense to add this chunk to the patch actually needing it
>
ehh, ignore this comment please :)
> > /* `bindgen` gets confused at certain things. */
> > const gfp_t BINDINGS_GFP_KERNEL = GFP_KERNEL;
> > diff --git a/rust/kernel/drm/ioctl.rs b/rust/kernel/drm/ioctl.rs
> > new file mode 100644
> > index 000000000000..10304efbd5f1
> > --- /dev/null
> > +++ b/rust/kernel/drm/ioctl.rs
> > @@ -0,0 +1,147 @@
> > +// SPDX-License-Identifier: GPL-2.0 OR MIT
> > +#![allow(non_snake_case)]
> > +
> > +//! DRM IOCTL definitions.
> > +//!
> > +//! C header: [`include/linux/drm/drm_ioctl.h`](../../../../include/linux/drm/drm_ioctl.h)
> > +
> > +use crate::ioctl;
> > +
> > +const BASE: u32 = bindings::DRM_IOCTL_BASE as u32;
> > +
> > +/// Construct a DRM ioctl number with no argument.
> > +pub const fn IO(nr: u32) -> u32 {
> > + ioctl::_IO(BASE, nr)
> > +}
> > +
> > +/// Construct a DRM ioctl number with a read-only argument.
> > +pub const fn IOR<T>(nr: u32) -> u32 {
> > + ioctl::_IOR::<T>(BASE, nr)
> > +}
> > +
> > +/// Construct a DRM ioctl number with a write-only argument.
> > +pub const fn IOW<T>(nr: u32) -> u32 {
> > + ioctl::_IOW::<T>(BASE, nr)
> > +}
> > +
> > +/// Construct a DRM ioctl number with a read-write argument.
> > +pub const fn IOWR<T>(nr: u32) -> u32 {
> > + ioctl::_IOWR::<T>(BASE, nr)
> > +}
> > +
> > +/// Descriptor type for DRM ioctls. Use the `declare_drm_ioctls!{}` macro to construct them.
> > +pub type DrmIoctlDescriptor = bindings::drm_ioctl_desc;
> > +
> > +/// This is for ioctl which are used for rendering, and require that the file descriptor is either
> > +/// for a render node, or if it’s a legacy/primary node, then it must be authenticated.
> > +pub const AUTH: u32 = bindings::drm_ioctl_flags_DRM_AUTH;
> > +
> > +/// This must be set for any ioctl which can change the modeset or display state. Userspace must
> > +/// call the ioctl through a primary node, while it is the active master.
> > +///
> > +/// Note that read-only modeset ioctl can also be called by unauthenticated clients, or when a
> > +/// master is not the currently active one.
> > +pub const MASTER: u32 = bindings::drm_ioctl_flags_DRM_MASTER;
> > +
> > +/// Anything that could potentially wreak a master file descriptor needs to have this flag set.
> > +///
> > +/// Current that’s only for the SETMASTER and DROPMASTER ioctl, which e.g. logind can call to force
> > +/// a non-behaving master (display compositor) into compliance.
> > +///
> > +/// This is equivalent to callers with the SYSADMIN capability.
> > +pub const ROOT_ONLY: u32 = bindings::drm_ioctl_flags_DRM_ROOT_ONLY;
> > +
> > +/// Whether drm_ioctl_desc.func should be called with the DRM BKL held or not. Enforced as the
> > +/// default for all modern drivers, hence there should never be a need to set this flag.
> > +///
> > +/// Do not use anywhere else than for the VBLANK_WAIT IOCTL, which is the only legacy IOCTL which
> > +/// needs this.
> > +pub const UNLOCKED: u32 = bindings::drm_ioctl_flags_DRM_UNLOCKED;
> > +
> > +/// This is used for all ioctl needed for rendering only, for drivers which support render nodes.
> > +/// This should be all new render drivers, and hence it should be always set for any ioctl with
> > +/// `AUTH` set. Note though that read-only query ioctl might have this set, but have not set
> > +/// DRM_AUTH because they do not require authentication.
> > +pub const RENDER_ALLOW: u32 = bindings::drm_ioctl_flags_DRM_RENDER_ALLOW;
> > +
> > +/// Declare the DRM ioctls for a driver.
> > +///
> > +/// Each entry in the list should have the form:
> > +///
> > +/// `(ioctl_number, argument_type, flags, user_callback),`
> > +///
> > +/// `argument_type` is the type name within the `bindings` crate.
> > +/// `user_callback` should have the following prototype:
> > +///
> > +/// ```
> > +/// fn foo(device: &kernel::drm::device::Device<Self>,
> > +/// data: &mut bindings::argument_type,
> > +/// file: &kernel::drm::file::File<Self::File>,
> > +/// )
> > +/// ```
> > +/// where `Self` is the drm::drv::Driver implementation these ioctls are being declared within.
> > +///
> > +/// # Examples
> > +///
> > +/// ```
> > +/// kernel::declare_drm_ioctls! {
> > +/// (FOO_GET_PARAM, drm_foo_get_param, ioctl::RENDER_ALLOW, my_get_param_handler),
> > +/// }
>
> I am wondering.. couldn't we make it a proc_macro and just tag all the
> functions instead? Though I also see the point of having a central
> list of all ioctls... Maybe we should have some higher level
> discussions around on _how_ we want things to look like.
>
> > +/// ```
> > +///
> > +#[macro_export]
> > +macro_rules! declare_drm_ioctls {
> > + ( $(($cmd:ident, $struct:ident, $flags:expr, $func:expr)),* $(,)? ) => {
> > + const IOCTLS: &'static [$crate::drm::ioctl::DrmIoctlDescriptor] = {
> > + const _:() = {
> > + let i: u32 = $crate::bindings::DRM_COMMAND_BASE;
> > + // Assert that all the IOCTLs are in the right order and there are no gaps,
> > + // and that the sizeof of the specified type is correct.
> > + $(
> > + let cmd: u32 = $crate::macros::concat_idents!($crate::bindings::DRM_IOCTL_, $cmd);
> > + ::core::assert!(i == $crate::ioctl::_IOC_NR(cmd));
> > + ::core::assert!(core::mem::size_of::<$crate::bindings::$struct>() == $crate::ioctl::_IOC_SIZE(cmd));
>
> ::core::mem::size_of
>
> > + let i: u32 = i + 1;
> > + )*
> > + };
> > +
> > + let ioctls = &[$(
> > + $crate::bindings::drm_ioctl_desc {
> > + cmd: $crate::macros::concat_idents!($crate::bindings::DRM_IOCTL_, $cmd) as u32,
> > + func: {
> > + #[allow(non_snake_case)]
> > + unsafe extern "C" fn $cmd(
> > + raw_dev: *mut $crate::bindings::drm_device,
> > + raw_data: *mut ::core::ffi::c_void,
> > + raw_file_priv: *mut $crate::bindings::drm_file,
> > + ) -> core::ffi::c_int {
>
> ::core
>
> > + // SAFETY: We never drop this, and the DRM core ensures the device lives
> > + // while callbacks are being called.
> > + //
> > + // FIXME: Currently there is nothing enforcing that the types of the
> > + // dev/file match the current driver these ioctls are being declared
> > + // for, and it's not clear how to enforce this within the type system.
> > + let dev = ::core::mem::ManuallyDrop::new(unsafe {
> > + $crate::drm::device::Device::from_raw(raw_dev)
> > + });
> > + // SAFETY: This is just the ioctl argument, which hopefully has the right type
> > + // (we've done our best checking the size).
> > + let data = unsafe { &mut *(raw_data as *mut $crate::bindings::$struct) };
> > + // SAFETY: This is just the DRM file structure
> > + let file = unsafe { $crate::drm::file::File::from_raw(raw_file_priv) };
> > +
> > + match $func(&*dev, data, &file) {
> > + Err(e) => e.to_kernel_errno(),
> > + Ok(i) => i.try_into().unwrap_or(ERANGE.to_kernel_errno()),
>
> need to specify the namespace on ERANGE, no?
>
> > + }
> > + }
> > + Some($cmd)
> > + },
> > + flags: $flags,
> > + name: $crate::c_str!(::core::stringify!($cmd)).as_char_ptr(),
> > + }
> > + ),*];
> > + ioctls
> > + };
> > + };
> > +}
> > diff --git a/rust/kernel/drm/mod.rs b/rust/kernel/drm/mod.rs
> > new file mode 100644
> > index 000000000000..9ec6d7cbcaf3
> > --- /dev/null
> > +++ b/rust/kernel/drm/mod.rs
> > @@ -0,0 +1,5 @@
> > +// SPDX-License-Identifier: GPL-2.0 OR MIT
> > +
> > +//! DRM subsystem abstractions.
> > +
> > +pub mod ioctl;
> > diff --git a/rust/kernel/lib.rs b/rust/kernel/lib.rs
> > index 7903490816bf..cb23d24c6718 100644
> > --- a/rust/kernel/lib.rs
> > +++ b/rust/kernel/lib.rs
> > @@ -37,6 +37,8 @@ mod build_assert;
> > pub mod delay;
> > pub mod device;
> > pub mod driver;
> > +#[cfg(CONFIG_RUST_DRM)]
> > +pub mod drm;
> > pub mod error;
> > pub mod io_buffer;
> > pub mod io_mem;
> >
> > --
> > 2.35.1
> >
^ permalink raw reply [flat|nested] 122+ messages in thread
* Re: [PATCH RFC 01/18] rust: drm: ioctl: Add DRM ioctl abstraction
2023-03-07 14:25 ` [PATCH RFC 01/18] rust: drm: ioctl: Add DRM ioctl abstraction Asahi Lina
2023-03-07 14:48 ` Karol Herbst
@ 2023-03-07 15:32 ` Maíra Canal
2023-03-09 5:32 ` Asahi Lina
2023-03-07 17:34 ` Björn Roy Baron
2023-04-13 9:23 ` Daniel Vetter
3 siblings, 1 reply; 122+ messages in thread
From: Maíra Canal @ 2023-03-07 15:32 UTC (permalink / raw)
To: Asahi Lina, Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
David Airlie, Daniel Vetter, Miguel Ojeda, Alex Gaynor,
Wedson Almeida Filho, Boqun Feng, Gary Guo, Björn Roy Baron,
Sumit Semwal, Christian König, Luben Tuikov,
Jarkko Sakkinen, Dave Hansen
Cc: linaro-mm-sig, rust-for-linux, Karol Herbst, asahi, linux-kernel,
dri-devel, Mary, Alyssa Rosenzweig, linux-sgx, Ella Stanforth,
Faith Ekstrand, linux-media
On 3/7/23 11:25, Asahi Lina wrote:
> DRM drivers need to be able to declare which driver-specific ioctls they
> support. This abstraction adds the required types and a helper macro to
> generate the ioctl definition inside the DRM driver.
>
> Note that this macro is not usable until further bits of the
> abstraction are in place (but it will not fail to compile on its own, if
> not called).
>
> Signed-off-by: Asahi Lina <lina@asahilina.net>
> ---
> drivers/gpu/drm/Kconfig | 7 ++
> rust/bindings/bindings_helper.h | 2 +
> rust/kernel/drm/ioctl.rs | 147 ++++++++++++++++++++++++++++++++++++++++
> rust/kernel/drm/mod.rs | 5 ++
> rust/kernel/lib.rs | 2 +
> 5 files changed, 163 insertions(+)
>
> diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
> index dc0f94f02a82..dab8f0f9aa96 100644
> --- a/drivers/gpu/drm/Kconfig
> +++ b/drivers/gpu/drm/Kconfig
> @@ -27,6 +27,13 @@ menuconfig DRM
> details. You should also select and configure AGP
> (/dev/agpgart) support if it is available for your platform.
>
[...]
> +
> +/// Declare the DRM ioctls for a driver.
> +///
> +/// Each entry in the list should have the form:
> +///
> +/// `(ioctl_number, argument_type, flags, user_callback),`
> +///
> +/// `argument_type` is the type name within the `bindings` crate.
> +/// `user_callback` should have the following prototype:
> +///
> +/// ```
> +/// fn foo(device: &kernel::drm::device::Device<Self>,
> +/// data: &mut bindings::argument_type,
> +/// file: &kernel::drm::file::File<Self::File>,
> +/// )
> +/// ```
> +/// where `Self` is the drm::drv::Driver implementation these ioctls are being declared within.
> +///
> +/// # Examples
> +///
> +/// ```
> +/// kernel::declare_drm_ioctls! {
> +/// (FOO_GET_PARAM, drm_foo_get_param, ioctl::RENDER_ALLOW, my_get_param_handler),
> +/// }
> +/// ```
> +///
> +#[macro_export]
> +macro_rules! declare_drm_ioctls {
> + ( $(($cmd:ident, $struct:ident, $flags:expr, $func:expr)),* $(,)? ) => {
> + const IOCTLS: &'static [$crate::drm::ioctl::DrmIoctlDescriptor] = {
> + const _:() = {
> + let i: u32 = $crate::bindings::DRM_COMMAND_BASE;
> + // Assert that all the IOCTLs are in the right order and there are no gaps,
> + // and that the sizeof of the specified type is correct.
I believe that not necessarily the IOCTLs need to be in the right order and
with no gaps. For example, armada_drm.h has a gap in between 0x00 and
0x02 and exynos_drm.h also have gaps. Moreover, some drivers, like vgem and
virtgpu, start their IOCTLs with 0x01.
Best Regards,
- Maíra Canal
> + $(
> + let cmd: u32 = $crate::macros::concat_idents!($crate::bindings::DRM_IOCTL_, $cmd);
> + ::core::assert!(i == $crate::ioctl::_IOC_NR(cmd));
> + ::core::assert!(core::mem::size_of::<$crate::bindings::$struct>() == $crate::ioctl::_IOC_SIZE(cmd));
> + let i: u32 = i + 1;
> + )*
> + };
> +
> + let ioctls = &[$(
> + $crate::bindings::drm_ioctl_desc {
> + cmd: $crate::macros::concat_idents!($crate::bindings::DRM_IOCTL_, $cmd) as u32,
> + func: {
> + #[allow(non_snake_case)]
> + unsafe extern "C" fn $cmd(
> + raw_dev: *mut $crate::bindings::drm_device,
> + raw_data: *mut ::core::ffi::c_void,
> + raw_file_priv: *mut $crate::bindings::drm_file,
> + ) -> core::ffi::c_int {
> + // SAFETY: We never drop this, and the DRM core ensures the device lives
> + // while callbacks are being called.
> + //
> + // FIXME: Currently there is nothing enforcing that the types of the
> + // dev/file match the current driver these ioctls are being declared
> + // for, and it's not clear how to enforce this within the type system.
> + let dev = ::core::mem::ManuallyDrop::new(unsafe {
> + $crate::drm::device::Device::from_raw(raw_dev)
> + });
> + // SAFETY: This is just the ioctl argument, which hopefully has the right type
> + // (we've done our best checking the size).
> + let data = unsafe { &mut *(raw_data as *mut $crate::bindings::$struct) };
> + // SAFETY: This is just the DRM file structure
> + let file = unsafe { $crate::drm::file::File::from_raw(raw_file_priv) };
> +
> + match $func(&*dev, data, &file) {
> + Err(e) => e.to_kernel_errno(),
> + Ok(i) => i.try_into().unwrap_or(ERANGE.to_kernel_errno()),
> + }
> + }
> + Some($cmd)
> + },
> + flags: $flags,
> + name: $crate::c_str!(::core::stringify!($cmd)).as_char_ptr(),
> + }
> + ),*];
> + ioctls
> + };
> + };
> +}
> diff --git a/rust/kernel/drm/mod.rs b/rust/kernel/drm/mod.rs
> new file mode 100644
> index 000000000000..9ec6d7cbcaf3
> --- /dev/null
> +++ b/rust/kernel/drm/mod.rs
> @@ -0,0 +1,5 @@
> +// SPDX-License-Identifier: GPL-2.0 OR MIT
> +
> +//! DRM subsystem abstractions.
> +
> +pub mod ioctl;
> diff --git a/rust/kernel/lib.rs b/rust/kernel/lib.rs
> index 7903490816bf..cb23d24c6718 100644
> --- a/rust/kernel/lib.rs
> +++ b/rust/kernel/lib.rs
> @@ -37,6 +37,8 @@ mod build_assert;
> pub mod delay;
> pub mod device;
> pub mod driver;
> +#[cfg(CONFIG_RUST_DRM)]
> +pub mod drm;
> pub mod error;
> pub mod io_buffer;
> pub mod io_mem;
>
^ permalink raw reply [flat|nested] 122+ messages in thread* Re: [PATCH RFC 01/18] rust: drm: ioctl: Add DRM ioctl abstraction
2023-03-07 15:32 ` Maíra Canal
@ 2023-03-09 5:32 ` Asahi Lina
2023-03-09 6:15 ` Dave Airlie
0 siblings, 1 reply; 122+ messages in thread
From: Asahi Lina @ 2023-03-09 5:32 UTC (permalink / raw)
To: Maíra Canal, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Daniel Vetter, Miguel Ojeda,
Alex Gaynor, Wedson Almeida Filho, Boqun Feng, Gary Guo,
Björn Roy Baron, Sumit Semwal, Christian König,
Luben Tuikov, Jarkko Sakkinen, Dave Hansen
Cc: linaro-mm-sig, rust-for-linux, Karol Herbst, asahi, linux-kernel,
dri-devel, Mary, Alyssa Rosenzweig, linux-sgx, Ella Stanforth,
Faith Ekstrand, linux-media
On 08/03/2023 00.32, Maíra Canal wrote:
> On 3/7/23 11:25, Asahi Lina wrote:
>> DRM drivers need to be able to declare which driver-specific ioctls they
>> support. This abstraction adds the required types and a helper macro to
>> generate the ioctl definition inside the DRM driver.
>>
>> Note that this macro is not usable until further bits of the
>> abstraction are in place (but it will not fail to compile on its own, if
>> not called).
>>
>> Signed-off-by: Asahi Lina <lina@asahilina.net>
>> ---
>> drivers/gpu/drm/Kconfig | 7 ++
>> rust/bindings/bindings_helper.h | 2 +
>> rust/kernel/drm/ioctl.rs | 147 ++++++++++++++++++++++++++++++++++++++++
>> rust/kernel/drm/mod.rs | 5 ++
>> rust/kernel/lib.rs | 2 +
>> 5 files changed, 163 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
>> index dc0f94f02a82..dab8f0f9aa96 100644
>> --- a/drivers/gpu/drm/Kconfig
>> +++ b/drivers/gpu/drm/Kconfig
>> @@ -27,6 +27,13 @@ menuconfig DRM
>> details. You should also select and configure AGP
>> (/dev/agpgart) support if it is available for your platform.
>>
>
> [...]
>
>> +
>> +/// Declare the DRM ioctls for a driver.
>> +///
>> +/// Each entry in the list should have the form:
>> +///
>> +/// `(ioctl_number, argument_type, flags, user_callback),`
>> +///
>> +/// `argument_type` is the type name within the `bindings` crate.
>> +/// `user_callback` should have the following prototype:
>> +///
>> +/// ```
>> +/// fn foo(device: &kernel::drm::device::Device<Self>,
>> +/// data: &mut bindings::argument_type,
>> +/// file: &kernel::drm::file::File<Self::File>,
>> +/// )
>> +/// ```
>> +/// where `Self` is the drm::drv::Driver implementation these ioctls are being declared within.
>> +///
>> +/// # Examples
>> +///
>> +/// ```
>> +/// kernel::declare_drm_ioctls! {
>> +/// (FOO_GET_PARAM, drm_foo_get_param, ioctl::RENDER_ALLOW, my_get_param_handler),
>> +/// }
>> +/// ```
>> +///
>> +#[macro_export]
>> +macro_rules! declare_drm_ioctls {
>> + ( $(($cmd:ident, $struct:ident, $flags:expr, $func:expr)),* $(,)? ) => {
>> + const IOCTLS: &'static [$crate::drm::ioctl::DrmIoctlDescriptor] = {
>> + const _:() = {
>> + let i: u32 = $crate::bindings::DRM_COMMAND_BASE;
>> + // Assert that all the IOCTLs are in the right order and there are no gaps,
>> + // and that the sizeof of the specified type is correct.
>
> I believe that not necessarily the IOCTLs need to be in the right order and
> with no gaps. For example, armada_drm.h has a gap in between 0x00 and
> 0x02 and exynos_drm.h also have gaps. Moreover, some drivers, like vgem and
> virtgpu, start their IOCTLs with 0x01.
Yeah, we talked about this a bit... do you have any ideas about how to
design this? I think it should be possible with a const function
initializing an array entry by entry, we just need a two-pass macro
(once to determine the max ioctl number, then again to actually output
the implementation).
I'm not sure why drivers would have gaps in the ioctl numbers though...
my idea was that new drivers shouldn't need that as far as I can tell
(you can't remove APIs after the fact due to UAPI stability guarantees,
so as long as you don't have gaps to begin with...). But I guess if
we're reimplementing existing drivers in Rust we'll need this... though
maybe it makes sense to just say it's not supported and require
reimplementations that have holes to just explicitly add dummy ioctls
that return EINVAL? We could even provide such a dummy generic ioctl
handler on the abstraction side, so drivers just have to add it to the
list, or make the macro take a special token that is used for
placeholder ioctls that don't exist (which then creates the NULL
function pointer that the drm core interprets as invalid)...
Basically I'm not sure if it makes sense to fully support noncontiguous
ioctl numbers automagically, or just say drivers need to explicitly list
gaps. I'd love to hear the opinion of other DRM folks about this!
~~ Lina
^ permalink raw reply [flat|nested] 122+ messages in thread* Re: [PATCH RFC 01/18] rust: drm: ioctl: Add DRM ioctl abstraction
2023-03-09 5:32 ` Asahi Lina
@ 2023-03-09 6:15 ` Dave Airlie
2023-03-09 12:09 ` Maíra Canal
0 siblings, 1 reply; 122+ messages in thread
From: Dave Airlie @ 2023-03-09 6:15 UTC (permalink / raw)
To: Asahi Lina
Cc: Maíra Canal, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, Daniel Vetter, Miguel Ojeda, Alex Gaynor,
Wedson Almeida Filho, Boqun Feng, Gary Guo, Björn Roy Baron,
Sumit Semwal, Christian König, Luben Tuikov,
Jarkko Sakkinen, Dave Hansen, linaro-mm-sig, rust-for-linux,
Karol Herbst, asahi, linux-kernel, dri-devel, Mary,
Alyssa Rosenzweig, linux-sgx, Ella Stanforth, Faith Ekstrand,
linux-media
On Thu, 9 Mar 2023 at 15:32, Asahi Lina <lina@asahilina.net> wrote:
>
> On 08/03/2023 00.32, Maíra Canal wrote:
> > On 3/7/23 11:25, Asahi Lina wrote:
> >> DRM drivers need to be able to declare which driver-specific ioctls they
> >> support. This abstraction adds the required types and a helper macro to
> >> generate the ioctl definition inside the DRM driver.
> >>
> >> Note that this macro is not usable until further bits of the
> >> abstraction are in place (but it will not fail to compile on its own, if
> >> not called).
> >>
> >> Signed-off-by: Asahi Lina <lina@asahilina.net>
> >> ---
> >> drivers/gpu/drm/Kconfig | 7 ++
> >> rust/bindings/bindings_helper.h | 2 +
> >> rust/kernel/drm/ioctl.rs | 147 ++++++++++++++++++++++++++++++++++++++++
> >> rust/kernel/drm/mod.rs | 5 ++
> >> rust/kernel/lib.rs | 2 +
> >> 5 files changed, 163 insertions(+)
> >>
> >> diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
> >> index dc0f94f02a82..dab8f0f9aa96 100644
> >> --- a/drivers/gpu/drm/Kconfig
> >> +++ b/drivers/gpu/drm/Kconfig
> >> @@ -27,6 +27,13 @@ menuconfig DRM
> >> details. You should also select and configure AGP
> >> (/dev/agpgart) support if it is available for your platform.
> >>
> >
> > [...]
> >
> >> +
> >> +/// Declare the DRM ioctls for a driver.
> >> +///
> >> +/// Each entry in the list should have the form:
> >> +///
> >> +/// `(ioctl_number, argument_type, flags, user_callback),`
> >> +///
> >> +/// `argument_type` is the type name within the `bindings` crate.
> >> +/// `user_callback` should have the following prototype:
> >> +///
> >> +/// ```
> >> +/// fn foo(device: &kernel::drm::device::Device<Self>,
> >> +/// data: &mut bindings::argument_type,
> >> +/// file: &kernel::drm::file::File<Self::File>,
> >> +/// )
> >> +/// ```
> >> +/// where `Self` is the drm::drv::Driver implementation these ioctls are being declared within.
> >> +///
> >> +/// # Examples
> >> +///
> >> +/// ```
> >> +/// kernel::declare_drm_ioctls! {
> >> +/// (FOO_GET_PARAM, drm_foo_get_param, ioctl::RENDER_ALLOW, my_get_param_handler),
> >> +/// }
> >> +/// ```
> >> +///
> >> +#[macro_export]
> >> +macro_rules! declare_drm_ioctls {
> >> + ( $(($cmd:ident, $struct:ident, $flags:expr, $func:expr)),* $(,)? ) => {
> >> + const IOCTLS: &'static [$crate::drm::ioctl::DrmIoctlDescriptor] = {
> >> + const _:() = {
> >> + let i: u32 = $crate::bindings::DRM_COMMAND_BASE;
> >> + // Assert that all the IOCTLs are in the right order and there are no gaps,
> >> + // and that the sizeof of the specified type is correct.
> >
> > I believe that not necessarily the IOCTLs need to be in the right order and
> > with no gaps. For example, armada_drm.h has a gap in between 0x00 and
> > 0x02 and exynos_drm.h also have gaps. Moreover, some drivers, like vgem and
> > virtgpu, start their IOCTLs with 0x01.
>
> Yeah, we talked about this a bit... do you have any ideas about how to
> design this? I think it should be possible with a const function
> initializing an array entry by entry, we just need a two-pass macro
> (once to determine the max ioctl number, then again to actually output
> the implementation).
>
> I'm not sure why drivers would have gaps in the ioctl numbers though...
> my idea was that new drivers shouldn't need that as far as I can tell
> (you can't remove APIs after the fact due to UAPI stability guarantees,
> so as long as you don't have gaps to begin with...). But I guess if
> we're reimplementing existing drivers in Rust we'll need this... though
> maybe it makes sense to just say it's not supported and require
> reimplementations that have holes to just explicitly add dummy ioctls
> that return EINVAL? We could even provide such a dummy generic ioctl
> handler on the abstraction side, so drivers just have to add it to the
> list, or make the macro take a special token that is used for
> placeholder ioctls that don't exist (which then creates the NULL
> function pointer that the drm core interprets as invalid)...
I can think of two reason for gaps having appeared:
a) developers wanted to group new uapis at a nice base number.
This is never essential it's just makes things easier to read, and
allows slotting other ioctls into the gaps later.
b) parallel feature development ends up conflicting then one thread never lands.
I've got two-three devs each adding a uAPI, we assign them 0x10, 0x11,
0x12 while they work, then 0x11 never lands because it was a bad idea.
However I think you should be fine enforcing a non-sparse space here
unless we want to handle replacing current drivers, as long as it's
hard to screw up so you know early.
Dave.
^ permalink raw reply [flat|nested] 122+ messages in thread* Re: [PATCH RFC 01/18] rust: drm: ioctl: Add DRM ioctl abstraction
2023-03-09 6:15 ` Dave Airlie
@ 2023-03-09 12:09 ` Maíra Canal
0 siblings, 0 replies; 122+ messages in thread
From: Maíra Canal @ 2023-03-09 12:09 UTC (permalink / raw)
To: Dave Airlie, Asahi Lina
Cc: Karol Herbst, Dave Hansen, dri-devel, Mary, Gary Guo,
Ella Stanforth, Sumit Semwal, Alyssa Rosenzweig,
Maíra Canal, Luben Tuikov, Alex Gaynor, Miguel Ojeda,
linux-media, Wedson Almeida Filho, rust-for-linux, Boqun Feng,
linaro-mm-sig, Faith Ekstrand, linux-sgx, Björn Roy Baron,
linux-kernel, Jarkko Sakkinen, asahi, Thomas Zimmermann,
Christian König
On 3/9/23 03:15, Dave Airlie wrote:
> On Thu, 9 Mar 2023 at 15:32, Asahi Lina <lina@asahilina.net> wrote:
>>
>> On 08/03/2023 00.32, Maíra Canal wrote:
>>> On 3/7/23 11:25, Asahi Lina wrote:
>>>> DRM drivers need to be able to declare which driver-specific ioctls they
>>>> support. This abstraction adds the required types and a helper macro to
>>>> generate the ioctl definition inside the DRM driver.
>>>>
>>>> Note that this macro is not usable until further bits of the
>>>> abstraction are in place (but it will not fail to compile on its own, if
>>>> not called).
>>>>
>>>> Signed-off-by: Asahi Lina <lina@asahilina.net>
>>>> ---
>>>> drivers/gpu/drm/Kconfig | 7 ++
>>>> rust/bindings/bindings_helper.h | 2 +
>>>> rust/kernel/drm/ioctl.rs | 147 ++++++++++++++++++++++++++++++++++++++++
>>>> rust/kernel/drm/mod.rs | 5 ++
>>>> rust/kernel/lib.rs | 2 +
>>>> 5 files changed, 163 insertions(+)
>>>>
>>>> diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
>>>> index dc0f94f02a82..dab8f0f9aa96 100644
>>>> --- a/drivers/gpu/drm/Kconfig
>>>> +++ b/drivers/gpu/drm/Kconfig
>>>> @@ -27,6 +27,13 @@ menuconfig DRM
>>>> details. You should also select and configure AGP
>>>> (/dev/agpgart) support if it is available for your platform.
>>>>
>>>
>>> [...]
>>>
>>>> +
>>>> +/// Declare the DRM ioctls for a driver.
>>>> +///
>>>> +/// Each entry in the list should have the form:
>>>> +///
>>>> +/// `(ioctl_number, argument_type, flags, user_callback),`
>>>> +///
>>>> +/// `argument_type` is the type name within the `bindings` crate.
>>>> +/// `user_callback` should have the following prototype:
>>>> +///
>>>> +/// ```
>>>> +/// fn foo(device: &kernel::drm::device::Device<Self>,
>>>> +/// data: &mut bindings::argument_type,
>>>> +/// file: &kernel::drm::file::File<Self::File>,
>>>> +/// )
>>>> +/// ```
>>>> +/// where `Self` is the drm::drv::Driver implementation these ioctls are being declared within.
>>>> +///
>>>> +/// # Examples
>>>> +///
>>>> +/// ```
>>>> +/// kernel::declare_drm_ioctls! {
>>>> +/// (FOO_GET_PARAM, drm_foo_get_param, ioctl::RENDER_ALLOW, my_get_param_handler),
>>>> +/// }
>>>> +/// ```
>>>> +///
>>>> +#[macro_export]
>>>> +macro_rules! declare_drm_ioctls {
>>>> + ( $(($cmd:ident, $struct:ident, $flags:expr, $func:expr)),* $(,)? ) => {
>>>> + const IOCTLS: &'static [$crate::drm::ioctl::DrmIoctlDescriptor] = {
>>>> + const _:() = {
>>>> + let i: u32 = $crate::bindings::DRM_COMMAND_BASE;
>>>> + // Assert that all the IOCTLs are in the right order and there are no gaps,
>>>> + // and that the sizeof of the specified type is correct.
>>>
>>> I believe that not necessarily the IOCTLs need to be in the right order and
>>> with no gaps. For example, armada_drm.h has a gap in between 0x00 and
>>> 0x02 and exynos_drm.h also have gaps. Moreover, some drivers, like vgem and
>>> virtgpu, start their IOCTLs with 0x01.
>>
>> Yeah, we talked about this a bit... do you have any ideas about how to
>> design this? I think it should be possible with a const function
>> initializing an array entry by entry, we just need a two-pass macro
>> (once to determine the max ioctl number, then again to actually output
>> the implementation).
>>
>> I'm not sure why drivers would have gaps in the ioctl numbers though...
>> my idea was that new drivers shouldn't need that as far as I can tell
>> (you can't remove APIs after the fact due to UAPI stability guarantees,
>> so as long as you don't have gaps to begin with...). But I guess if
>> we're reimplementing existing drivers in Rust we'll need this... though
>> maybe it makes sense to just say it's not supported and require
>> reimplementations that have holes to just explicitly add dummy ioctls
>> that return EINVAL? We could even provide such a dummy generic ioctl
>> handler on the abstraction side, so drivers just have to add it to the
>> list, or make the macro take a special token that is used for
>> placeholder ioctls that don't exist (which then creates the NULL
>> function pointer that the drm core interprets as invalid)...
>
> I can think of two reason for gaps having appeared:
>
> a) developers wanted to group new uapis at a nice base number.
> This is never essential it's just makes things easier to read, and
> allows slotting other ioctls into the gaps later.
>
> b) parallel feature development ends up conflicting then one thread never lands.
> I've got two-three devs each adding a uAPI, we assign them 0x10, 0x11,
> 0x12 while they work, then 0x11 never lands because it was a bad idea.
>
> However I think you should be fine enforcing a non-sparse space here
> unless we want to handle replacing current drivers, as long as it's
> hard to screw up so you know early.
I guess it would be nice to support old UAPIs for cases of reimplementations.
Currently, I'm working on a reimplementation of vgem and I ended up having to
create a dummy IOCTL to deal with the sparse number space. Although creating
dummy IOCTLs works, I don't believe it is a nice practice.
Moreover, I believe that if we keep developing new drivers with Rust, cases
(a) and (b) will end up happening, and maybe the Rust abstractions should
work like DRM and allow it to happen.
Best Regards,
- Maíra Canal
>
> Dave.
^ permalink raw reply [flat|nested] 122+ messages in thread
* Re: [PATCH RFC 01/18] rust: drm: ioctl: Add DRM ioctl abstraction
2023-03-07 14:25 ` [PATCH RFC 01/18] rust: drm: ioctl: Add DRM ioctl abstraction Asahi Lina
2023-03-07 14:48 ` Karol Herbst
2023-03-07 15:32 ` Maíra Canal
@ 2023-03-07 17:34 ` Björn Roy Baron
2023-03-09 6:04 ` Asahi Lina
2023-04-13 9:23 ` Daniel Vetter
3 siblings, 1 reply; 122+ messages in thread
From: Björn Roy Baron @ 2023-03-07 17:34 UTC (permalink / raw)
To: Asahi Lina
Cc: Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
David Airlie, Daniel Vetter, Miguel Ojeda, Alex Gaynor,
Wedson Almeida Filho, Boqun Feng, Gary Guo, Sumit Semwal,
Christian König, Luben Tuikov, Jarkko Sakkinen, Dave Hansen,
Alyssa Rosenzweig, Karol Herbst, Ella Stanforth, Faith Ekstrand,
Mary, linux-kernel, dri-devel, rust-for-linux, linux-media,
linaro-mm-sig, linux-sgx, asahi
------- Original Message -------
On Tuesday, March 7th, 2023 at 15:25, Asahi Lina <lina@asahilina.net> wrote:
> DRM drivers need to be able to declare which driver-specific ioctls they
> support. This abstraction adds the required types and a helper macro to
> generate the ioctl definition inside the DRM driver.
>
> Note that this macro is not usable until further bits of the
> abstraction are in place (but it will not fail to compile on its own, if
> not called).
>
> Signed-off-by: Asahi Lina lina@asahilina.net
>
> ---
> drivers/gpu/drm/Kconfig | 7 ++
> rust/bindings/bindings_helper.h | 2 +
> rust/kernel/drm/ioctl.rs | 147 ++++++++++++++++++++++++++++++++++++++++
> rust/kernel/drm/mod.rs | 5 ++
> rust/kernel/lib.rs | 2 +
> 5 files changed, 163 insertions(+)
>
> diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
> index dc0f94f02a82..dab8f0f9aa96 100644
> --- a/drivers/gpu/drm/Kconfig
> +++ b/drivers/gpu/drm/Kconfig
> @@ -27,6 +27,13 @@ menuconfig DRM
> details. You should also select and configure AGP
> (/dev/agpgart) support if it is available for your platform.
>
> +# Rust abstractions cannot be built as modules currently, so force them as
> +# bool by using these intermediate symbols. In the future these could be
> +# tristate once abstractions themselves can be built as modules.
> +config RUST_DRM
> + bool "Rust support for the DRM subsystem"
> + depends on DRM=y
> +
> config DRM_MIPI_DBI
> tristate
> depends on DRM
> diff --git a/rust/bindings/bindings_helper.h b/rust/bindings/bindings_helper.h
> index 91bb7906ca5a..2687bef1676f 100644
> --- a/rust/bindings/bindings_helper.h
> +++ b/rust/bindings/bindings_helper.h
> @@ -6,6 +6,7 @@
> * Sorted alphabetically.
> */
>
> +#include <drm/drm_ioctl.h>
> #include <linux/delay.h>
> #include <linux/device.h>
> #include <linux/dma-mapping.h>
> @@ -23,6 +24,7 @@
> #include <linux/sysctl.h>
> #include <linux/timekeeping.h>
> #include <linux/xarray.h>
> +#include <uapi/drm/drm.h>
>
> /* `bindgen` gets confused at certain things. */
> const gfp_t BINDINGS_GFP_KERNEL = GFP_KERNEL;
> diff --git a/rust/kernel/drm/ioctl.rs b/rust/kernel/drm/ioctl.rs
> new file mode 100644
> index 000000000000..10304efbd5f1
> --- /dev/null
> +++ b/rust/kernel/drm/ioctl.rs
> @@ -0,0 +1,147 @@
> +// SPDX-License-Identifier: GPL-2.0 OR MIT
> +#![allow(non_snake_case)]
> +
> +//! DRM IOCTL definitions.
> +//!
> +//! C header: [`include/linux/drm/drm_ioctl.h`](../../../../include/linux/drm/drm_ioctl.h)
> +
> +use crate::ioctl;
> +
> +const BASE: u32 = bindings::DRM_IOCTL_BASE as u32;
> +
> +/// Construct a DRM ioctl number with no argument.
> +pub const fn IO(nr: u32) -> u32 {
> + ioctl::_IO(BASE, nr)
> +}
> +
> +/// Construct a DRM ioctl number with a read-only argument.
> +pub const fn IOR<T>(nr: u32) -> u32 {
> + ioctl::_IOR::<T>(BASE, nr)
> +}
> +
> +/// Construct a DRM ioctl number with a write-only argument.
> +pub const fn IOW<T>(nr: u32) -> u32 {
> + ioctl::_IOW::<T>(BASE, nr)
> +}
> +
> +/// Construct a DRM ioctl number with a read-write argument.
> +pub const fn IOWR<T>(nr: u32) -> u32 {
> + ioctl::_IOWR::<T>(BASE, nr)
> +}
> +
> +/// Descriptor type for DRM ioctls. Use the `declare_drm_ioctls!{}` macro to construct them.
> +pub type DrmIoctlDescriptor = bindings::drm_ioctl_desc;
> +
> +/// This is for ioctl which are used for rendering, and require that the file descriptor is either
> +/// for a render node, or if it’s a legacy/primary node, then it must be authenticated.
> +pub const AUTH: u32 = bindings::drm_ioctl_flags_DRM_AUTH;
> +
> +/// This must be set for any ioctl which can change the modeset or display state. Userspace must
> +/// call the ioctl through a primary node, while it is the active master.
> +///
> +/// Note that read-only modeset ioctl can also be called by unauthenticated clients, or when a
> +/// master is not the currently active one.
> +pub const MASTER: u32 = bindings::drm_ioctl_flags_DRM_MASTER;
> +
> +/// Anything that could potentially wreak a master file descriptor needs to have this flag set.
> +///
> +/// Current that’s only for the SETMASTER and DROPMASTER ioctl, which e.g. logind can call to force
> +/// a non-behaving master (display compositor) into compliance.
> +///
> +/// This is equivalent to callers with the SYSADMIN capability.
> +pub const ROOT_ONLY: u32 = bindings::drm_ioctl_flags_DRM_ROOT_ONLY;
> +
> +/// Whether drm_ioctl_desc.func should be called with the DRM BKL held or not. Enforced as the
> +/// default for all modern drivers, hence there should never be a need to set this flag.
> +///
> +/// Do not use anywhere else than for the VBLANK_WAIT IOCTL, which is the only legacy IOCTL which
> +/// needs this.
> +pub const UNLOCKED: u32 = bindings::drm_ioctl_flags_DRM_UNLOCKED;
> +
> +/// This is used for all ioctl needed for rendering only, for drivers which support render nodes.
> +/// This should be all new render drivers, and hence it should be always set for any ioctl with
> +/// `AUTH` set. Note though that read-only query ioctl might have this set, but have not set
> +/// DRM_AUTH because they do not require authentication.
> +pub const RENDER_ALLOW: u32 = bindings::drm_ioctl_flags_DRM_RENDER_ALLOW;
> +
> +/// Declare the DRM ioctls for a driver.
> +///
> +/// Each entry in the list should have the form:
> +///
> +/// `(ioctl_number, argument_type, flags, user_callback),`
> +///
> +/// `argument_type` is the type name within the `bindings` crate.
> +/// `user_callback` should have the following prototype:
> +///
> +/// ```
> +/// fn foo(device: &kernel::drm::device::Device<Self>,
> +/// data: &mut bindings::argument_type,
> +/// file: &kernel::drm::file::File<Self::File>,
> +/// )
> +/// ```
> +/// where `Self` is the drm::drv::Driver implementation these ioctls are being declared within.
> +///
> +/// # Examples
> +///
> +/// ```
> +/// kernel::declare_drm_ioctls! {
> +/// (FOO_GET_PARAM, drm_foo_get_param, ioctl::RENDER_ALLOW, my_get_param_handler),
> +/// }
> +/// ```
> +///
> +#[macro_export]
> +macro_rules! declare_drm_ioctls {
> + ( $(($cmd:ident, $struct:ident, $flags:expr, $func:expr)),* $(,)? ) => {
> + const IOCTLS: &'static [$crate::drm::ioctl::DrmIoctlDescriptor] = {
> + const _:() = {
> + let i: u32 = $crate::bindings::DRM_COMMAND_BASE;
> + // Assert that all the IOCTLs are in the right order and there are no gaps,
> + // and that the sizeof of the specified type is correct.
> + $(
> + let cmd: u32 = $crate::macros::concat_idents!($crate::bindings::DRM_IOCTL_, $cmd);
> + ::core::assert!(i == $crate::ioctl::_IOC_NR(cmd));
> + ::core::assert!(core::mem::size_of::<$crate::bindings::$struct>() == $crate::ioctl::_IOC_SIZE(cmd));
> + let i: u32 = i + 1;
> + )*
> + };
> +
> + let ioctls = &[$(
> + $crate::bindings::drm_ioctl_desc {
> + cmd: $crate::macros::concat_idents!($crate::bindings::DRM_IOCTL_, $cmd) as u32,
> + func: {
> + #[allow(non_snake_case)]
> + unsafe extern "C" fn $cmd(
> + raw_dev: *mut $crate::bindings::drm_device,
> + raw_data: *mut ::core::ffi::c_void,
> + raw_file_priv: *mut $crate::bindings::drm_file,
> + ) -> core::ffi::c_int {
> + // SAFETY: We never drop this, and the DRM core ensures the device lives
> + // while callbacks are being called.
> + //
> + // FIXME: Currently there is nothing enforcing that the types of the
> + // dev/file match the current driver these ioctls are being declared
> + // for, and it's not clear how to enforce this within the type system.
> + let dev = ::core::mem::ManuallyDrop::new(unsafe {
> + $crate::drm::device::Device::from_raw(raw_dev)
> + });
> + // SAFETY: This is just the ioctl argument, which hopefully has the right type
> + // (we've done our best checking the size).
In the rust tree there is the ReadableFromBytes [1] trait which indicates that it is safe to read arbitrary bytes into the type. Maybe you could add it as bound on the argument type when it lands in rust-next? This way you can't end up with for example a struct containing a bool with the byte value 2, which is UB.
https://rust-for-linux.github.io/docs/kernel/io_buffer/trait.ReadableFromBytes.html [1]
> + let data = unsafe { &mut *(raw_data as *mut $crate::bindings::$struct) };
> + // SAFETY: This is just the DRM file structure
> + let file = unsafe { $crate::drm::file::File::from_raw(raw_file_priv) };
> +
> + match $func(&*dev, data, &file) {
> + Err(e) => e.to_kernel_errno(),
> + Ok(i) => i.try_into().unwrap_or(ERANGE.to_kernel_errno()),
> + }
> + }
> + Some($cmd)
> + },
> + flags: $flags,
> + name: $crate::c_str!(::core::stringify!($cmd)).as_char_ptr(),
> + }
> + ),*];
> + ioctls
> + };
> + };
> +}
> diff --git a/rust/kernel/drm/mod.rs b/rust/kernel/drm/mod.rs
> new file mode 100644
> index 000000000000..9ec6d7cbcaf3
> --- /dev/null
> +++ b/rust/kernel/drm/mod.rs
> @@ -0,0 +1,5 @@
> +// SPDX-License-Identifier: GPL-2.0 OR MIT
> +
> +//! DRM subsystem abstractions.
> +
> +pub mod ioctl;
> diff --git a/rust/kernel/lib.rs b/rust/kernel/lib.rs
> index 7903490816bf..cb23d24c6718 100644
> --- a/rust/kernel/lib.rs
> +++ b/rust/kernel/lib.rs
> @@ -37,6 +37,8 @@ mod build_assert;
> pub mod delay;
> pub mod device;
> pub mod driver;
> +#[cfg(CONFIG_RUST_DRM)]
> +pub mod drm;
> pub mod error;
> pub mod io_buffer;
> pub mod io_mem;
>
> --
> 2.35.1
Cheers,
Bjorn
^ permalink raw reply [flat|nested] 122+ messages in thread* Re: [PATCH RFC 01/18] rust: drm: ioctl: Add DRM ioctl abstraction
2023-03-07 17:34 ` Björn Roy Baron
@ 2023-03-09 6:04 ` Asahi Lina
2023-03-09 20:24 ` Faith Ekstrand
0 siblings, 1 reply; 122+ messages in thread
From: Asahi Lina @ 2023-03-09 6:04 UTC (permalink / raw)
To: Björn Roy Baron
Cc: Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
David Airlie, Daniel Vetter, Miguel Ojeda, Alex Gaynor,
Wedson Almeida Filho, Boqun Feng, Gary Guo, Sumit Semwal,
Christian König, Luben Tuikov, Jarkko Sakkinen, Dave Hansen,
Alyssa Rosenzweig, Karol Herbst, Ella Stanforth, Faith Ekstrand,
Mary, linux-kernel, dri-devel, rust-for-linux, linux-media,
linaro-mm-sig, linux-sgx, asahi
On 08/03/2023 02.34, Björn Roy Baron wrote:
>> + // SAFETY: This is just the ioctl argument, which hopefully has the right type
>> + // (we've done our best checking the size).
>
> In the rust tree there is the ReadableFromBytes [1] trait which indicates that it is safe to read arbitrary bytes into the type. Maybe you could add it as bound on the argument type when it lands in rust-next? This way you can't end up with for example a struct containing a bool with the byte value 2, which is UB.
There's actually a much bigger story here, because that trait isn't
really very useful without a way to auto-derive it. I need the same kind
of guarantee for all the GPU firmware structs...
There's one using only declarative macros [1] and one using proc macros
[2]. And then, since ioctl arguments are declared in C UAPI header
files, we need a way to be able to derive those traits for them... which
I guess means bindgen changes?
For now though, I don't think this is something we need to worry about
too much for this particular use case because the macro forces all
struct types to be part of `bindings`, and any driver UAPI should
already follow these constraints if it is well-formed (and UAPIs are
going to already attract a lot of scrutiny anyway). Technically you
could try taking a random kernel struct containing a `bool` in an ioctl
list, but that would stand out as nonsense just as much as trying to
unsafe impl ReadableFromBytes for it so... it's kind of an academic
problem ^^
Actually, I think we talked of moving UAPI types to a separate crate (so
drivers can get access to those types and only those types, not the main
bindings crate). Then maybe we could just say that if the macro forces
the type to be from that crate, it's inherently safe since all UAPIs
should already be castable to/from bytes if properly designed.
Aside: I'm not sure the ReadableFromBytes/WritableToBytes distinction is
very useful. I know it exists (padding bytes, uninit fields, and
technically bool should be WritableToBytes but not ReadableFromBytes),
but I can't think of a good use case for it... I think I'd rather start
with a single trait and just always enforce the union of the rules,
because pretty much any time you're casting to/from bytes you want
well-defined "bag of bytes" struct layouts anyway. ioctls can be R/W/RW
so having separate traits depending on ioctl type complicates the code...
[1]
https://github.com/QubesOS/qubes-gui-rust/blob/940754bfefb7325548eece658c307a0c41c9bc7c/qubes-castable/src/lib.rs
[2] https://docs.rs/pkbuffer/latest/pkbuffer/derive.Castable.html
>
> https://rust-for-linux.github.io/docs/kernel/io_buffer/trait.ReadableFromBytes.html [1]
>
~~ Lina
^ permalink raw reply [flat|nested] 122+ messages in thread
* Re: [PATCH RFC 01/18] rust: drm: ioctl: Add DRM ioctl abstraction
2023-03-09 6:04 ` Asahi Lina
@ 2023-03-09 20:24 ` Faith Ekstrand
2023-03-09 20:39 ` Karol Herbst
0 siblings, 1 reply; 122+ messages in thread
From: Faith Ekstrand @ 2023-03-09 20:24 UTC (permalink / raw)
To: Asahi Lina, Björn Roy Baron
Cc: Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
David Airlie, Daniel Vetter, Miguel Ojeda, Alex Gaynor,
Wedson Almeida Filho, Boqun Feng, Gary Guo, Sumit Semwal,
Christian König, Luben Tuikov, Jarkko Sakkinen, Dave Hansen,
Alyssa Rosenzweig, Karol Herbst, Ella Stanforth, Mary,
linux-kernel, dri-devel, rust-for-linux, linux-media,
linaro-mm-sig, linux-sgx, asahi
On Thu, 2023-03-09 at 15:04 +0900, Asahi Lina wrote:
> On 08/03/2023 02.34, Björn Roy Baron wrote:
> > > + // SAFETY: This is just the ioctl
> > > argument, which hopefully has the right type
> > > + // (we've done our best checking the
> > > size).
> >
> > In the rust tree there is the ReadableFromBytes [1] trait which
> > indicates that it is safe to read arbitrary bytes into the type.
> > Maybe you could add it as bound on the argument type when it lands
> > in rust-next? This way you can't end up with for example a struct
> > containing a bool with the byte value 2, which is UB.
>
> There's actually a much bigger story here, because that trait isn't
> really very useful without a way to auto-derive it. I need the same
> kind
> of guarantee for all the GPU firmware structs...
>
> There's one using only declarative macros [1] and one using proc
> macros
> [2]. And then, since ioctl arguments are declared in C UAPI header
> files, we need a way to be able to derive those traits for them...
> which
> I guess means bindgen changes?
It'd be cool to be able to auto-verify that uAPI structs are all
tightly packed and use the right subset of types. Maybe not possible
this iteration but it'd be cool to see in future. I'd like to see it
for C as well, ideally.
~Faith
^ permalink raw reply [flat|nested] 122+ messages in thread
* Re: [PATCH RFC 01/18] rust: drm: ioctl: Add DRM ioctl abstraction
2023-03-09 20:24 ` Faith Ekstrand
@ 2023-03-09 20:39 ` Karol Herbst
2023-03-10 6:21 ` Asahi Lina
0 siblings, 1 reply; 122+ messages in thread
From: Karol Herbst @ 2023-03-09 20:39 UTC (permalink / raw)
To: Faith Ekstrand
Cc: Asahi Lina, Björn Roy Baron, Maarten Lankhorst,
Maxime Ripard, Thomas Zimmermann, David Airlie, Daniel Vetter,
Miguel Ojeda, Alex Gaynor, Wedson Almeida Filho, Boqun Feng,
Gary Guo, Sumit Semwal, Christian König, Luben Tuikov,
Jarkko Sakkinen, Dave Hansen, Alyssa Rosenzweig, Ella Stanforth,
Mary, linux-kernel, dri-devel, rust-for-linux, linux-media,
linaro-mm-sig, linux-sgx, asahi
On Thu, Mar 9, 2023 at 9:24 PM Faith Ekstrand
<faith.ekstrand@collabora.com> wrote:
>
> On Thu, 2023-03-09 at 15:04 +0900, Asahi Lina wrote:
> > On 08/03/2023 02.34, Björn Roy Baron wrote:
> > > > + // SAFETY: This is just the ioctl
> > > > argument, which hopefully has the right type
> > > > + // (we've done our best checking the
> > > > size).
> > >
> > > In the rust tree there is the ReadableFromBytes [1] trait which
> > > indicates that it is safe to read arbitrary bytes into the type.
> > > Maybe you could add it as bound on the argument type when it lands
> > > in rust-next? This way you can't end up with for example a struct
> > > containing a bool with the byte value 2, which is UB.
> >
> > There's actually a much bigger story here, because that trait isn't
> > really very useful without a way to auto-derive it. I need the same
> > kind
> > of guarantee for all the GPU firmware structs...
> >
> > There's one using only declarative macros [1] and one using proc
> > macros
> > [2]. And then, since ioctl arguments are declared in C UAPI header
> > files, we need a way to be able to derive those traits for them...
> > which
> > I guess means bindgen changes?
>
> It'd be cool to be able to auto-verify that uAPI structs are all
> tightly packed and use the right subset of types. Maybe not possible
> this iteration but it'd be cool to see in future. I'd like to see it
> for C as well, ideally.
>
> ~Faith
>
I'm sure that with a macro you could verify that a struct definition
doesn't contain any gaps, just not sure on how one would enforce that.
Could add a trait which can only be implemented through a proc_macro?
Maybe we can have a proc_macro ensuring no gaps? Would be cool tech to
have indeed.
^ permalink raw reply [flat|nested] 122+ messages in thread
* Re: [PATCH RFC 01/18] rust: drm: ioctl: Add DRM ioctl abstraction
2023-03-09 20:39 ` Karol Herbst
@ 2023-03-10 6:21 ` Asahi Lina
0 siblings, 0 replies; 122+ messages in thread
From: Asahi Lina @ 2023-03-10 6:21 UTC (permalink / raw)
To: Karol Herbst, Faith Ekstrand
Cc: Björn Roy Baron, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Daniel Vetter, Miguel Ojeda,
Alex Gaynor, Wedson Almeida Filho, Boqun Feng, Gary Guo,
Sumit Semwal, Christian König, Luben Tuikov,
Jarkko Sakkinen, Dave Hansen, Alyssa Rosenzweig, Ella Stanforth,
Mary, linux-kernel, dri-devel, rust-for-linux, linux-media,
linaro-mm-sig, linux-sgx, asahi
On 10/03/2023 05.39, Karol Herbst wrote:
> On Thu, Mar 9, 2023 at 9:24 PM Faith Ekstrand
> <faith.ekstrand@collabora.com> wrote:
>>
>> On Thu, 2023-03-09 at 15:04 +0900, Asahi Lina wrote:
>>> On 08/03/2023 02.34, Björn Roy Baron wrote:
>>>>> + // SAFETY: This is just the ioctl
>>>>> argument, which hopefully has the right type
>>>>> + // (we've done our best checking the
>>>>> size).
>>>>
>>>> In the rust tree there is the ReadableFromBytes [1] trait which
>>>> indicates that it is safe to read arbitrary bytes into the type.
>>>> Maybe you could add it as bound on the argument type when it lands
>>>> in rust-next? This way you can't end up with for example a struct
>>>> containing a bool with the byte value 2, which is UB.
>>>
>>> There's actually a much bigger story here, because that trait isn't
>>> really very useful without a way to auto-derive it. I need the same
>>> kind
>>> of guarantee for all the GPU firmware structs...
>>>
>>> There's one using only declarative macros [1] and one using proc
>>> macros
>>> [2]. And then, since ioctl arguments are declared in C UAPI header
>>> files, we need a way to be able to derive those traits for them...
>>> which
>>> I guess means bindgen changes?
>>
>> It'd be cool to be able to auto-verify that uAPI structs are all
>> tightly packed and use the right subset of types. Maybe not possible
>> this iteration but it'd be cool to see in future. I'd like to see it
>> for C as well, ideally.
>>
>> ~Faith
>>
>
> I'm sure that with a macro you could verify that a struct definition
> doesn't contain any gaps, just not sure on how one would enforce that.
> Could add a trait which can only be implemented through a proc_macro?
> Maybe we can have a proc_macro ensuring no gaps? Would be cool tech to
> have indeed.
You just make the trait unsafe, as usual, then implement it via that
macro. It's how the things I linked work ^^
The tricky thing with C UAPI definitions is just that we need to get
bindgen to emit those macro instantiations around struct definitions
somehow. Or maybe it could be done with a brute force text-based
postprocessing pass? If we put all UAPI defs into their own crate, you
could probably just do it with sed or a python script or something on
the bindgen output to add it for all struct types...
@Rust folks: Should I try creating a uapi crate for this? I think we can
just mirror the bindings crate logic, and we don't need helpers or
anything like that here, so it shouldn't be very difficult. Then I could
(eventually) eliminate all usage of the full bindings crate in the
driver, and also try experimenting with stuff like this to validate all
UAPI types and implement special traits for them...
~~ Lina
^ permalink raw reply [flat|nested] 122+ messages in thread
* Re: [PATCH RFC 01/18] rust: drm: ioctl: Add DRM ioctl abstraction
2023-03-07 14:25 ` [PATCH RFC 01/18] rust: drm: ioctl: Add DRM ioctl abstraction Asahi Lina
` (2 preceding siblings ...)
2023-03-07 17:34 ` Björn Roy Baron
@ 2023-04-13 9:23 ` Daniel Vetter
3 siblings, 0 replies; 122+ messages in thread
From: Daniel Vetter @ 2023-04-13 9:23 UTC (permalink / raw)
To: Asahi Lina
Cc: Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
David Airlie, Daniel Vetter, Miguel Ojeda, Alex Gaynor,
Wedson Almeida Filho, Boqun Feng, Gary Guo, Björn Roy Baron,
Sumit Semwal, Christian König, Luben Tuikov,
Jarkko Sakkinen, Dave Hansen, Alyssa Rosenzweig, Karol Herbst,
Ella Stanforth, Faith Ekstrand, Mary, linux-kernel, dri-devel,
rust-for-linux, linux-media, linaro-mm-sig, linux-sgx, asahi
On Tue, Mar 07, 2023 at 11:25:26PM +0900, Asahi Lina wrote:
> DRM drivers need to be able to declare which driver-specific ioctls they
> support. This abstraction adds the required types and a helper macro to
> generate the ioctl definition inside the DRM driver.
>
> Note that this macro is not usable until further bits of the
> abstraction are in place (but it will not fail to compile on its own, if
> not called).
>
> Signed-off-by: Asahi Lina <lina@asahilina.net>
A bunch of thoughts/questions:
- You have the pub functions to create ioctl numbers, but it looks like
most drivers just do this in the C uapi headers instead and then use the
direct number from the bindings? I wonder whether we shouldn't just use
that as standard way, since in the end we do need the C headers for
userspace to use the ioctls/structs. Or could we generate the headers
from rust?
- More type safety would be nice. You have the one for device, but not yet
for DrmFile. At least if I read the examples in asahi/vgem right. Also
the FIXME for how to make sure you generate the table for the right kind
of driver would be nice to fix.
- Type safety against the size of the struct an ioctl number is great!
- I wonder whether we could adjust the type according to _IOR/W/RW, i.e.
if you have W then your ioctl function is Result<Struct>, if not then
Result<()> since it's just errno, and you get the paramater only when
you have R set. We had in the past confusions where people got this
wrong and wondered why their parameters don't make it to userspace.
- There's also the question of drm_ioctl() zero-extending the ioctl
parameter struct both ways (i.e. kernel kernel or newer userspace). I
think trying to encode that with Some() is overkill, but maybe worth a
thought.
- It would be _really_ great if rust ioctl abstractions enforce
https://dri.freedesktop.org/docs/drm/process/botching-up-ioctls.html at
the type level, i.e. everything naturally aligned, no gaps, all that
stuff. This would also hold for get/put_user and all these things (I
didn't look into that stuff yet in the drivers when you pull in entire
arrays).
Cheers, Daniel
> ---
> drivers/gpu/drm/Kconfig | 7 ++
> rust/bindings/bindings_helper.h | 2 +
> rust/kernel/drm/ioctl.rs | 147 ++++++++++++++++++++++++++++++++++++++++
> rust/kernel/drm/mod.rs | 5 ++
> rust/kernel/lib.rs | 2 +
> 5 files changed, 163 insertions(+)
>
> diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
> index dc0f94f02a82..dab8f0f9aa96 100644
> --- a/drivers/gpu/drm/Kconfig
> +++ b/drivers/gpu/drm/Kconfig
> @@ -27,6 +27,13 @@ menuconfig DRM
> details. You should also select and configure AGP
> (/dev/agpgart) support if it is available for your platform.
>
> +# Rust abstractions cannot be built as modules currently, so force them as
> +# bool by using these intermediate symbols. In the future these could be
> +# tristate once abstractions themselves can be built as modules.
> +config RUST_DRM
> + bool "Rust support for the DRM subsystem"
> + depends on DRM=y
> +
> config DRM_MIPI_DBI
> tristate
> depends on DRM
> diff --git a/rust/bindings/bindings_helper.h b/rust/bindings/bindings_helper.h
> index 91bb7906ca5a..2687bef1676f 100644
> --- a/rust/bindings/bindings_helper.h
> +++ b/rust/bindings/bindings_helper.h
> @@ -6,6 +6,7 @@
> * Sorted alphabetically.
> */
>
> +#include <drm/drm_ioctl.h>
> #include <linux/delay.h>
> #include <linux/device.h>
> #include <linux/dma-mapping.h>
> @@ -23,6 +24,7 @@
> #include <linux/sysctl.h>
> #include <linux/timekeeping.h>
> #include <linux/xarray.h>
> +#include <uapi/drm/drm.h>
>
> /* `bindgen` gets confused at certain things. */
> const gfp_t BINDINGS_GFP_KERNEL = GFP_KERNEL;
> diff --git a/rust/kernel/drm/ioctl.rs b/rust/kernel/drm/ioctl.rs
> new file mode 100644
> index 000000000000..10304efbd5f1
> --- /dev/null
> +++ b/rust/kernel/drm/ioctl.rs
> @@ -0,0 +1,147 @@
> +// SPDX-License-Identifier: GPL-2.0 OR MIT
> +#![allow(non_snake_case)]
> +
> +//! DRM IOCTL definitions.
> +//!
> +//! C header: [`include/linux/drm/drm_ioctl.h`](../../../../include/linux/drm/drm_ioctl.h)
> +
> +use crate::ioctl;
> +
> +const BASE: u32 = bindings::DRM_IOCTL_BASE as u32;
> +
> +/// Construct a DRM ioctl number with no argument.
> +pub const fn IO(nr: u32) -> u32 {
> + ioctl::_IO(BASE, nr)
> +}
> +
> +/// Construct a DRM ioctl number with a read-only argument.
> +pub const fn IOR<T>(nr: u32) -> u32 {
> + ioctl::_IOR::<T>(BASE, nr)
> +}
> +
> +/// Construct a DRM ioctl number with a write-only argument.
> +pub const fn IOW<T>(nr: u32) -> u32 {
> + ioctl::_IOW::<T>(BASE, nr)
> +}
> +
> +/// Construct a DRM ioctl number with a read-write argument.
> +pub const fn IOWR<T>(nr: u32) -> u32 {
> + ioctl::_IOWR::<T>(BASE, nr)
> +}
> +
> +/// Descriptor type for DRM ioctls. Use the `declare_drm_ioctls!{}` macro to construct them.
> +pub type DrmIoctlDescriptor = bindings::drm_ioctl_desc;
> +
> +/// This is for ioctl which are used for rendering, and require that the file descriptor is either
> +/// for a render node, or if it’s a legacy/primary node, then it must be authenticated.
> +pub const AUTH: u32 = bindings::drm_ioctl_flags_DRM_AUTH;
> +
> +/// This must be set for any ioctl which can change the modeset or display state. Userspace must
> +/// call the ioctl through a primary node, while it is the active master.
> +///
> +/// Note that read-only modeset ioctl can also be called by unauthenticated clients, or when a
> +/// master is not the currently active one.
> +pub const MASTER: u32 = bindings::drm_ioctl_flags_DRM_MASTER;
> +
> +/// Anything that could potentially wreak a master file descriptor needs to have this flag set.
> +///
> +/// Current that’s only for the SETMASTER and DROPMASTER ioctl, which e.g. logind can call to force
> +/// a non-behaving master (display compositor) into compliance.
> +///
> +/// This is equivalent to callers with the SYSADMIN capability.
> +pub const ROOT_ONLY: u32 = bindings::drm_ioctl_flags_DRM_ROOT_ONLY;
> +
> +/// Whether drm_ioctl_desc.func should be called with the DRM BKL held or not. Enforced as the
> +/// default for all modern drivers, hence there should never be a need to set this flag.
> +///
> +/// Do not use anywhere else than for the VBLANK_WAIT IOCTL, which is the only legacy IOCTL which
> +/// needs this.
> +pub const UNLOCKED: u32 = bindings::drm_ioctl_flags_DRM_UNLOCKED;
> +
> +/// This is used for all ioctl needed for rendering only, for drivers which support render nodes.
> +/// This should be all new render drivers, and hence it should be always set for any ioctl with
> +/// `AUTH` set. Note though that read-only query ioctl might have this set, but have not set
> +/// DRM_AUTH because they do not require authentication.
> +pub const RENDER_ALLOW: u32 = bindings::drm_ioctl_flags_DRM_RENDER_ALLOW;
> +
> +/// Declare the DRM ioctls for a driver.
> +///
> +/// Each entry in the list should have the form:
> +///
> +/// `(ioctl_number, argument_type, flags, user_callback),`
> +///
> +/// `argument_type` is the type name within the `bindings` crate.
> +/// `user_callback` should have the following prototype:
> +///
> +/// ```
> +/// fn foo(device: &kernel::drm::device::Device<Self>,
> +/// data: &mut bindings::argument_type,
> +/// file: &kernel::drm::file::File<Self::File>,
> +/// )
> +/// ```
> +/// where `Self` is the drm::drv::Driver implementation these ioctls are being declared within.
> +///
> +/// # Examples
> +///
> +/// ```
> +/// kernel::declare_drm_ioctls! {
> +/// (FOO_GET_PARAM, drm_foo_get_param, ioctl::RENDER_ALLOW, my_get_param_handler),
> +/// }
> +/// ```
> +///
> +#[macro_export]
> +macro_rules! declare_drm_ioctls {
> + ( $(($cmd:ident, $struct:ident, $flags:expr, $func:expr)),* $(,)? ) => {
> + const IOCTLS: &'static [$crate::drm::ioctl::DrmIoctlDescriptor] = {
> + const _:() = {
> + let i: u32 = $crate::bindings::DRM_COMMAND_BASE;
> + // Assert that all the IOCTLs are in the right order and there are no gaps,
> + // and that the sizeof of the specified type is correct.
> + $(
> + let cmd: u32 = $crate::macros::concat_idents!($crate::bindings::DRM_IOCTL_, $cmd);
> + ::core::assert!(i == $crate::ioctl::_IOC_NR(cmd));
> + ::core::assert!(core::mem::size_of::<$crate::bindings::$struct>() == $crate::ioctl::_IOC_SIZE(cmd));
> + let i: u32 = i + 1;
> + )*
> + };
> +
> + let ioctls = &[$(
> + $crate::bindings::drm_ioctl_desc {
> + cmd: $crate::macros::concat_idents!($crate::bindings::DRM_IOCTL_, $cmd) as u32,
> + func: {
> + #[allow(non_snake_case)]
> + unsafe extern "C" fn $cmd(
> + raw_dev: *mut $crate::bindings::drm_device,
> + raw_data: *mut ::core::ffi::c_void,
> + raw_file_priv: *mut $crate::bindings::drm_file,
> + ) -> core::ffi::c_int {
> + // SAFETY: We never drop this, and the DRM core ensures the device lives
> + // while callbacks are being called.
> + //
> + // FIXME: Currently there is nothing enforcing that the types of the
> + // dev/file match the current driver these ioctls are being declared
> + // for, and it's not clear how to enforce this within the type system.
> + let dev = ::core::mem::ManuallyDrop::new(unsafe {
> + $crate::drm::device::Device::from_raw(raw_dev)
> + });
> + // SAFETY: This is just the ioctl argument, which hopefully has the right type
> + // (we've done our best checking the size).
> + let data = unsafe { &mut *(raw_data as *mut $crate::bindings::$struct) };
> + // SAFETY: This is just the DRM file structure
> + let file = unsafe { $crate::drm::file::File::from_raw(raw_file_priv) };
> +
> + match $func(&*dev, data, &file) {
> + Err(e) => e.to_kernel_errno(),
> + Ok(i) => i.try_into().unwrap_or(ERANGE.to_kernel_errno()),
> + }
> + }
> + Some($cmd)
> + },
> + flags: $flags,
> + name: $crate::c_str!(::core::stringify!($cmd)).as_char_ptr(),
> + }
> + ),*];
> + ioctls
> + };
> + };
> +}
> diff --git a/rust/kernel/drm/mod.rs b/rust/kernel/drm/mod.rs
> new file mode 100644
> index 000000000000..9ec6d7cbcaf3
> --- /dev/null
> +++ b/rust/kernel/drm/mod.rs
> @@ -0,0 +1,5 @@
> +// SPDX-License-Identifier: GPL-2.0 OR MIT
> +
> +//! DRM subsystem abstractions.
> +
> +pub mod ioctl;
> diff --git a/rust/kernel/lib.rs b/rust/kernel/lib.rs
> index 7903490816bf..cb23d24c6718 100644
> --- a/rust/kernel/lib.rs
> +++ b/rust/kernel/lib.rs
> @@ -37,6 +37,8 @@ mod build_assert;
> pub mod delay;
> pub mod device;
> pub mod driver;
> +#[cfg(CONFIG_RUST_DRM)]
> +pub mod drm;
> pub mod error;
> pub mod io_buffer;
> pub mod io_mem;
>
> --
> 2.35.1
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
^ permalink raw reply [flat|nested] 122+ messages in thread
* [PATCH RFC 02/18] rust: drm: Add Device and Driver abstractions
2023-03-07 14:25 [PATCH RFC 00/18] Rust DRM subsystem abstractions (& preview AGX driver) Asahi Lina
2023-03-07 14:25 ` [PATCH RFC 01/18] rust: drm: ioctl: Add DRM ioctl abstraction Asahi Lina
@ 2023-03-07 14:25 ` Asahi Lina
2023-03-07 18:19 ` Björn Roy Baron
` (3 more replies)
2023-03-07 14:25 ` [PATCH RFC 03/18] rust: drm: file: Add File abstraction Asahi Lina
` (16 subsequent siblings)
18 siblings, 4 replies; 122+ messages in thread
From: Asahi Lina @ 2023-03-07 14:25 UTC (permalink / raw)
To: Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
David Airlie, Daniel Vetter, Miguel Ojeda, Alex Gaynor,
Wedson Almeida Filho, Boqun Feng, Gary Guo, Björn Roy Baron,
Sumit Semwal, Christian König, Luben Tuikov,
Jarkko Sakkinen, Dave Hansen
Cc: Alyssa Rosenzweig, Karol Herbst, Ella Stanforth, Faith Ekstrand,
Mary, linux-kernel, dri-devel, rust-for-linux, linux-media,
linaro-mm-sig, linux-sgx, asahi, Asahi Lina
Add the initial abstractions for DRM drivers and devices. These go
together in one commit since they are fairly tightly coupled types.
A few things have been stubbed out, to be implemented as further bits of
the DRM subsystem are introduced.
Signed-off-by: Asahi Lina <lina@asahilina.net>
---
rust/bindings/bindings_helper.h | 3 +
rust/kernel/drm/device.rs | 76 +++++++++
rust/kernel/drm/drv.rs | 339 ++++++++++++++++++++++++++++++++++++++++
rust/kernel/drm/mod.rs | 2 +
4 files changed, 420 insertions(+)
diff --git a/rust/bindings/bindings_helper.h b/rust/bindings/bindings_helper.h
index 2687bef1676f..2a999138c4ae 100644
--- a/rust/bindings/bindings_helper.h
+++ b/rust/bindings/bindings_helper.h
@@ -6,10 +6,13 @@
* Sorted alphabetically.
*/
+#include <drm/drm_device.h>
+#include <drm/drm_drv.h>
#include <drm/drm_ioctl.h>
#include <linux/delay.h>
#include <linux/device.h>
#include <linux/dma-mapping.h>
+#include <linux/fs.h>
#include <linux/ioctl.h>
#include <linux/io-pgtable.h>
#include <linux/ktime.h>
diff --git a/rust/kernel/drm/device.rs b/rust/kernel/drm/device.rs
new file mode 100644
index 000000000000..6007f941137a
--- /dev/null
+++ b/rust/kernel/drm/device.rs
@@ -0,0 +1,76 @@
+// SPDX-License-Identifier: GPL-2.0 OR MIT
+
+//! DRM device.
+//!
+//! C header: [`include/linux/drm/drm_device.h`](../../../../include/linux/drm/drm_device.h)
+
+use crate::{bindings, device, drm, types::ForeignOwnable};
+use core::marker::PhantomData;
+
+/// Represents a reference to a DRM device. The device is reference-counted and is guaranteed to
+/// not be dropped while this object is alive.
+pub struct Device<T: drm::drv::Driver> {
+ // Type invariant: ptr must be a valid and initialized drm_device,
+ // and this value must either own a reference to it or the caller
+ // must ensure that it is never dropped if the reference is borrowed.
+ pub(super) ptr: *mut bindings::drm_device,
+ _p: PhantomData<T>,
+}
+
+impl<T: drm::drv::Driver> Device<T> {
+ // Not intended to be called externally, except via declare_drm_ioctls!()
+ #[doc(hidden)]
+ pub unsafe fn from_raw(raw: *mut bindings::drm_device) -> Device<T> {
+ Device {
+ ptr: raw,
+ _p: PhantomData,
+ }
+ }
+
+ #[allow(dead_code)]
+ pub(crate) fn raw(&self) -> *const bindings::drm_device {
+ self.ptr
+ }
+
+ pub(crate) fn raw_mut(&mut self) -> *mut bindings::drm_device {
+ self.ptr
+ }
+
+ /// Returns a borrowed reference to the user data associated with this Device.
+ pub fn data(&self) -> <T::Data as ForeignOwnable>::Borrowed<'_> {
+ unsafe { T::Data::borrow((*self.ptr).dev_private) }
+ }
+}
+
+impl<T: drm::drv::Driver> Drop for Device<T> {
+ fn drop(&mut self) {
+ // SAFETY: By the type invariants, we know that `self` owns a reference, so it is safe to
+ // relinquish it now.
+ unsafe { bindings::drm_dev_put(self.ptr) };
+ }
+}
+
+impl<T: drm::drv::Driver> Clone for Device<T> {
+ fn clone(&self) -> Self {
+ // SAFETY: We get a new reference and then create a new owning object from the raw pointer
+ unsafe {
+ bindings::drm_dev_get(self.ptr);
+ Device::from_raw(self.ptr)
+ }
+ }
+}
+
+// SAFETY: `Device` only holds a pointer to a C device, which is safe to be used from any thread.
+unsafe impl<T: drm::drv::Driver> Send for Device<T> {}
+
+// SAFETY: `Device` only holds a pointer to a C device, references to which are safe to be used
+// from any thread.
+unsafe impl<T: drm::drv::Driver> Sync for Device<T> {}
+
+// Make drm::Device work for dev_info!() and friends
+unsafe impl<T: drm::drv::Driver> device::RawDevice for Device<T> {
+ fn raw_device(&self) -> *mut bindings::device {
+ // SAFETY: ptr must be valid per the type invariant
+ unsafe { (*self.ptr).dev }
+ }
+}
diff --git a/rust/kernel/drm/drv.rs b/rust/kernel/drm/drv.rs
new file mode 100644
index 000000000000..29a465515dc9
--- /dev/null
+++ b/rust/kernel/drm/drv.rs
@@ -0,0 +1,339 @@
+// SPDX-License-Identifier: GPL-2.0 OR MIT
+
+//! DRM driver core.
+//!
+//! C header: [`include/linux/drm/drm_drv.h`](../../../../include/linux/drm/drm_drv.h)
+
+use crate::{
+ bindings, device, drm,
+ error::code::*,
+ error::from_kernel_err_ptr,
+ error::{Error, Result},
+ prelude::*,
+ private::Sealed,
+ str::CStr,
+ types::ForeignOwnable,
+ ThisModule,
+};
+use core::{
+ marker::{PhantomData, PhantomPinned},
+ pin::Pin,
+};
+use macros::vtable;
+
+/// Driver use the GEM memory manager. This should be set for all modern drivers.
+pub const FEAT_GEM: u32 = bindings::drm_driver_feature_DRIVER_GEM;
+/// Driver supports mode setting interfaces (KMS).
+pub const FEAT_MODESET: u32 = bindings::drm_driver_feature_DRIVER_MODESET;
+/// Driver supports dedicated render nodes.
+pub const FEAT_RENDER: u32 = bindings::drm_driver_feature_DRIVER_RENDER;
+/// Driver supports the full atomic modesetting userspace API.
+///
+/// Drivers which only use atomic internally, but do not support the full userspace API (e.g. not
+/// all properties converted to atomic, or multi-plane updates are not guaranteed to be tear-free)
+/// should not set this flag.
+pub const FEAT_ATOMIC: u32 = bindings::drm_driver_feature_DRIVER_ATOMIC;
+/// Driver supports DRM sync objects for explicit synchronization of command submission.
+pub const FEAT_SYNCOBJ: u32 = bindings::drm_driver_feature_DRIVER_SYNCOBJ;
+/// Driver supports the timeline flavor of DRM sync objects for explicit synchronization of command
+/// submission.
+pub const FEAT_SYNCOBJ_TIMELINE: u32 = bindings::drm_driver_feature_DRIVER_SYNCOBJ_TIMELINE;
+
+/// Information data for a DRM Driver.
+pub struct DriverInfo {
+ /// Driver major version.
+ pub major: i32,
+ /// Driver minor version.
+ pub minor: i32,
+ /// Driver patchlevel version.
+ pub patchlevel: i32,
+ /// Driver name.
+ pub name: &'static CStr,
+ /// Driver description.
+ pub desc: &'static CStr,
+ /// Driver date.
+ pub date: &'static CStr,
+}
+
+/// Internal memory management operation set, normally created by memory managers (e.g. GEM).
+///
+/// See `kernel::drm::gem` and `kernel::drm::gem::shmem`.
+pub struct AllocOps {
+ pub(crate) gem_create_object: Option<
+ unsafe extern "C" fn(
+ dev: *mut bindings::drm_device,
+ size: usize,
+ ) -> *mut bindings::drm_gem_object,
+ >,
+ pub(crate) prime_handle_to_fd: Option<
+ unsafe extern "C" fn(
+ dev: *mut bindings::drm_device,
+ file_priv: *mut bindings::drm_file,
+ handle: u32,
+ flags: u32,
+ prime_fd: *mut core::ffi::c_int,
+ ) -> core::ffi::c_int,
+ >,
+ pub(crate) prime_fd_to_handle: Option<
+ unsafe extern "C" fn(
+ dev: *mut bindings::drm_device,
+ file_priv: *mut bindings::drm_file,
+ prime_fd: core::ffi::c_int,
+ handle: *mut u32,
+ ) -> core::ffi::c_int,
+ >,
+ pub(crate) gem_prime_import: Option<
+ unsafe extern "C" fn(
+ dev: *mut bindings::drm_device,
+ dma_buf: *mut bindings::dma_buf,
+ ) -> *mut bindings::drm_gem_object,
+ >,
+ pub(crate) gem_prime_import_sg_table: Option<
+ unsafe extern "C" fn(
+ dev: *mut bindings::drm_device,
+ attach: *mut bindings::dma_buf_attachment,
+ sgt: *mut bindings::sg_table,
+ ) -> *mut bindings::drm_gem_object,
+ >,
+ pub(crate) gem_prime_mmap: Option<
+ unsafe extern "C" fn(
+ obj: *mut bindings::drm_gem_object,
+ vma: *mut bindings::vm_area_struct,
+ ) -> core::ffi::c_int,
+ >,
+ pub(crate) dumb_create: Option<
+ unsafe extern "C" fn(
+ file_priv: *mut bindings::drm_file,
+ dev: *mut bindings::drm_device,
+ args: *mut bindings::drm_mode_create_dumb,
+ ) -> core::ffi::c_int,
+ >,
+ pub(crate) dumb_map_offset: Option<
+ unsafe extern "C" fn(
+ file_priv: *mut bindings::drm_file,
+ dev: *mut bindings::drm_device,
+ handle: u32,
+ offset: *mut u64,
+ ) -> core::ffi::c_int,
+ >,
+ pub(crate) dumb_destroy: Option<
+ unsafe extern "C" fn(
+ file_priv: *mut bindings::drm_file,
+ dev: *mut bindings::drm_device,
+ handle: u32,
+ ) -> core::ffi::c_int,
+ >,
+}
+
+/// Trait for memory manager implementations. Implemented internally.
+pub trait AllocImpl: Sealed {
+ /// The C callback operations for this memory manager.
+ const ALLOC_OPS: AllocOps;
+}
+
+/// A DRM driver implementation.
+#[vtable]
+pub trait Driver {
+ /// Context data associated with the DRM driver
+ ///
+ /// Determines the type of the context data passed to each of the methods of the trait.
+ type Data: ForeignOwnable + Sync + Send;
+
+ /// The type used to manage memory for this driver.
+ ///
+ /// Should be either `drm::gem::Object<T>` or `drm::gem::shmem::Object<T>`.
+ type Object: AllocImpl;
+
+ /// Driver metadata
+ const INFO: DriverInfo;
+
+ /// Feature flags
+ const FEATURES: u32;
+
+ /// IOCTL list. See `kernel::drm::ioctl::declare_drm_ioctls!{}`.
+ const IOCTLS: &'static [drm::ioctl::DrmIoctlDescriptor];
+}
+
+/// A registration of a DRM device
+///
+/// # Invariants:
+///
+/// drm is always a valid pointer to an allocated drm_device
+pub struct Registration<T: Driver> {
+ drm: drm::device::Device<T>,
+ registered: bool,
+ fops: bindings::file_operations,
+ vtable: Pin<Box<bindings::drm_driver>>,
+ _p: PhantomData<T>,
+ _pin: PhantomPinned,
+}
+
+#[cfg(CONFIG_DRM_LEGACY)]
+macro_rules! drm_legacy_fields {
+ ( $($field:ident: $val:expr),* $(,)? ) => {
+ bindings::drm_driver {
+ $( $field: $val ),*,
+ firstopen: None,
+ preclose: None,
+ dma_ioctl: None,
+ dma_quiescent: None,
+ context_dtor: None,
+ irq_handler: None,
+ irq_preinstall: None,
+ irq_postinstall: None,
+ irq_uninstall: None,
+ get_vblank_counter: None,
+ enable_vblank: None,
+ disable_vblank: None,
+ dev_priv_size: 0,
+ }
+ }
+}
+
+#[cfg(not(CONFIG_DRM_LEGACY))]
+macro_rules! drm_legacy_fields {
+ ( $($field:ident: $val:expr),* $(,)? ) => {
+ bindings::drm_driver {
+ $( $field: $val ),*
+ }
+ }
+}
+
+/// Registers a DRM device with the rest of the kernel.
+///
+/// It automatically picks up THIS_MODULE.
+#[allow(clippy::crate_in_macro_def)]
+#[macro_export]
+macro_rules! drm_device_register {
+ ($reg:expr, $data:expr, $flags:expr $(,)?) => {{
+ $crate::drm::drv::Registration::register($reg, $data, $flags, &crate::THIS_MODULE)
+ }};
+}
+
+impl<T: Driver> Registration<T> {
+ const VTABLE: bindings::drm_driver = drm_legacy_fields! {
+ load: None,
+ open: None, // TODO: File abstraction
+ postclose: None, // TODO: File abstraction
+ lastclose: None,
+ unload: None,
+ release: None,
+ master_set: None,
+ master_drop: None,
+ debugfs_init: None,
+ gem_create_object: T::Object::ALLOC_OPS.gem_create_object,
+ prime_handle_to_fd: T::Object::ALLOC_OPS.prime_handle_to_fd,
+ prime_fd_to_handle: T::Object::ALLOC_OPS.prime_fd_to_handle,
+ gem_prime_import: T::Object::ALLOC_OPS.gem_prime_import,
+ gem_prime_import_sg_table: T::Object::ALLOC_OPS.gem_prime_import_sg_table,
+ gem_prime_mmap: T::Object::ALLOC_OPS.gem_prime_mmap,
+ dumb_create: T::Object::ALLOC_OPS.dumb_create,
+ dumb_map_offset: T::Object::ALLOC_OPS.dumb_map_offset,
+ dumb_destroy: T::Object::ALLOC_OPS.dumb_destroy,
+
+ major: T::INFO.major,
+ minor: T::INFO.minor,
+ patchlevel: T::INFO.patchlevel,
+ name: T::INFO.name.as_char_ptr() as *mut _,
+ desc: T::INFO.desc.as_char_ptr() as *mut _,
+ date: T::INFO.date.as_char_ptr() as *mut _,
+
+ driver_features: T::FEATURES,
+ ioctls: T::IOCTLS.as_ptr(),
+ num_ioctls: T::IOCTLS.len() as i32,
+ fops: core::ptr::null_mut(),
+ };
+
+ /// Creates a new [`Registration`] but does not register it yet.
+ ///
+ /// It is allowed to move.
+ pub fn new(parent: &dyn device::RawDevice) -> Result<Self> {
+ let vtable = Pin::new(Box::try_new(Self::VTABLE)?);
+ let raw_drm = unsafe { bindings::drm_dev_alloc(&*vtable, parent.raw_device()) };
+ let raw_drm = from_kernel_err_ptr(raw_drm)?;
+
+ // The reference count is one, and now we take ownership of that reference as a
+ // drm::device::Device.
+ let drm = unsafe { drm::device::Device::from_raw(raw_drm) };
+
+ Ok(Self {
+ drm,
+ registered: false,
+ vtable,
+ fops: Default::default(), // TODO: GEM abstraction
+ _pin: PhantomPinned,
+ _p: PhantomData,
+ })
+ }
+
+ /// Registers a DRM device with the rest of the kernel.
+ ///
+ /// Users are encouraged to use the [`drm_device_register!()`] macro because it automatically
+ /// picks up the current module.
+ pub fn register(
+ self: Pin<&mut Self>,
+ data: T::Data,
+ flags: usize,
+ module: &'static ThisModule,
+ ) -> Result {
+ if self.registered {
+ // Already registered.
+ return Err(EINVAL);
+ }
+
+ // SAFETY: We never move out of `this`.
+ let this = unsafe { self.get_unchecked_mut() };
+ let data_pointer = <T::Data as ForeignOwnable>::into_foreign(data);
+ // SAFETY: `drm` is valid per the type invariant
+ unsafe {
+ (*this.drm.raw_mut()).dev_private = data_pointer as *mut _;
+ }
+
+ this.fops.owner = module.0;
+ this.vtable.fops = &this.fops;
+
+ // SAFETY: The device is now initialized and ready to be registered.
+ let ret = unsafe { bindings::drm_dev_register(this.drm.raw_mut(), flags as u64) };
+ if ret < 0 {
+ // SAFETY: `data_pointer` was returned by `into_foreign` above.
+ unsafe { T::Data::from_foreign(data_pointer) };
+ return Err(Error::from_kernel_errno(ret));
+ }
+
+ this.registered = true;
+ Ok(())
+ }
+
+ /// Returns a reference to the `Device` instance for this registration.
+ pub fn device(&self) -> &drm::device::Device<T> {
+ &self.drm
+ }
+}
+
+// SAFETY: `Registration` doesn't offer any methods or access to fields when shared between threads
+// or CPUs, so it is safe to share it.
+unsafe impl<T: Driver> Sync for Registration<T> {}
+
+// SAFETY: Registration with and unregistration from the drm subsystem can happen from any thread.
+// Additionally, `T::Data` (which is dropped during unregistration) is `Send`, so it is ok to move
+// `Registration` to different threads.
+#[allow(clippy::non_send_fields_in_send_ty)]
+unsafe impl<T: Driver> Send for Registration<T> {}
+
+impl<T: Driver> Drop for Registration<T> {
+ /// Removes the registration from the kernel if it has completed successfully before.
+ fn drop(&mut self) {
+ if self.registered {
+ // Get a pointer to the data stored in device before destroying it.
+ // SAFETY: `drm` is valid per the type invariant
+ let data_pointer = unsafe { (*self.drm.raw_mut()).dev_private };
+
+ // SAFETY: Since `registered` is true, `self.drm` is both valid and registered.
+ unsafe { bindings::drm_dev_unregister(self.drm.raw_mut()) };
+
+ // Free data as well.
+ // SAFETY: `data_pointer` was returned by `into_foreign` during registration.
+ unsafe { <T::Data as ForeignOwnable>::from_foreign(data_pointer) };
+ }
+ }
+}
diff --git a/rust/kernel/drm/mod.rs b/rust/kernel/drm/mod.rs
index 9ec6d7cbcaf3..69376b3c6db9 100644
--- a/rust/kernel/drm/mod.rs
+++ b/rust/kernel/drm/mod.rs
@@ -2,4 +2,6 @@
//! DRM subsystem abstractions.
+pub mod device;
+pub mod drv;
pub mod ioctl;
--
2.35.1
^ permalink raw reply related [flat|nested] 122+ messages in thread* Re: [PATCH RFC 02/18] rust: drm: Add Device and Driver abstractions
2023-03-07 14:25 ` [PATCH RFC 02/18] rust: drm: Add Device and Driver abstractions Asahi Lina
@ 2023-03-07 18:19 ` Björn Roy Baron
2023-03-09 6:10 ` Asahi Lina
2023-03-10 18:56 ` Boqun Feng
` (2 subsequent siblings)
3 siblings, 1 reply; 122+ messages in thread
From: Björn Roy Baron @ 2023-03-07 18:19 UTC (permalink / raw)
To: Asahi Lina
Cc: Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
David Airlie, Daniel Vetter, Miguel Ojeda, Alex Gaynor,
Wedson Almeida Filho, Boqun Feng, Gary Guo, Sumit Semwal,
Christian König, Luben Tuikov, Jarkko Sakkinen, Dave Hansen,
Alyssa Rosenzweig, Karol Herbst, Ella Stanforth, Faith Ekstrand,
Mary, linux-kernel, dri-devel, rust-for-linux, linux-media,
linaro-mm-sig, linux-sgx, asahi
------- Original Message -------
On Tuesday, March 7th, 2023 at 15:25, Asahi Lina <lina@asahilina.net> wrote:
> Add the initial abstractions for DRM drivers and devices. These go
> together in one commit since they are fairly tightly coupled types.
>
> A few things have been stubbed out, to be implemented as further bits of
> the DRM subsystem are introduced.
>
> Signed-off-by: Asahi Lina lina@asahilina.net
>
> ---
> rust/bindings/bindings_helper.h | 3 +
> rust/kernel/drm/device.rs | 76 +++++++++
> rust/kernel/drm/drv.rs | 339 ++++++++++++++++++++++++++++++++++++++++
> rust/kernel/drm/mod.rs | 2 +
> 4 files changed, 420 insertions(+)
>
> diff --git a/rust/bindings/bindings_helper.h b/rust/bindings/bindings_helper.h
> index 2687bef1676f..2a999138c4ae 100644
> --- a/rust/bindings/bindings_helper.h
> +++ b/rust/bindings/bindings_helper.h
> @@ -6,10 +6,13 @@
> * Sorted alphabetically.
> */
>
> +#include <drm/drm_device.h>
> +#include <drm/drm_drv.h>
> #include <drm/drm_ioctl.h>
> #include <linux/delay.h>
> #include <linux/device.h>
> #include <linux/dma-mapping.h>
> +#include <linux/fs.h>
> #include <linux/ioctl.h>
> #include <linux/io-pgtable.h>
> #include <linux/ktime.h>
> diff --git a/rust/kernel/drm/device.rs b/rust/kernel/drm/device.rs
> new file mode 100644
> index 000000000000..6007f941137a
> --- /dev/null
> +++ b/rust/kernel/drm/device.rs
> @@ -0,0 +1,76 @@
> +// SPDX-License-Identifier: GPL-2.0 OR MIT
> +
> +//! DRM device.
> +//!
> +//! C header: [`include/linux/drm/drm_device.h`](../../../../include/linux/drm/drm_device.h)
> +
> +use crate::{bindings, device, drm, types::ForeignOwnable};
> +use core::marker::PhantomData;
> +
> +/// Represents a reference to a DRM device. The device is reference-counted and is guaranteed to
> +/// not be dropped while this object is alive.
> +pub struct Device<T: drm::drv::Driver> {
> + // Type invariant: ptr must be a valid and initialized drm_device,
> + // and this value must either own a reference to it or the caller
> + // must ensure that it is never dropped if the reference is borrowed.
> + pub(super) ptr: *mut bindings::drm_device,
> + _p: PhantomData<T>,
> +}
> +
> +impl<T: drm::drv::Driver> Device<T> {
> + // Not intended to be called externally, except via declare_drm_ioctls!()
> + #[doc(hidden)]
> + pub unsafe fn from_raw(raw: *mut bindings::drm_device) -> Device<T> {
> + Device {
> + ptr: raw,
> + _p: PhantomData,
> + }
> + }
> +
> + #[allow(dead_code)]
> + pub(crate) fn raw(&self) -> *const bindings::drm_device {
> + self.ptr
> + }
> +
> + pub(crate) fn raw_mut(&mut self) -> *mut bindings::drm_device {
> + self.ptr
> + }
> +
> + /// Returns a borrowed reference to the user data associated with this Device.
> + pub fn data(&self) -> <T::Data as ForeignOwnable>::Borrowed<'_> {
> + unsafe { T::Data::borrow((*self.ptr).dev_private) }
> + }
> +}
> +
> +impl<T: drm::drv::Driver> Drop for Device<T> {
> + fn drop(&mut self) {
> + // SAFETY: By the type invariants, we know that `self` owns a reference, so it is safe to
> + // relinquish it now.
> + unsafe { bindings::drm_dev_put(self.ptr) };
> + }
> +}
> +
> +impl<T: drm::drv::Driver> Clone for Device<T> {
> + fn clone(&self) -> Self {
> + // SAFETY: We get a new reference and then create a new owning object from the raw pointer
> + unsafe {
> + bindings::drm_dev_get(self.ptr);
> + Device::from_raw(self.ptr)
> + }
> + }
> +}
> +
> +// SAFETY: `Device` only holds a pointer to a C device, which is safe to be used from any thread.
> +unsafe impl<T: drm::drv::Driver> Send for Device<T> {}
> +
> +// SAFETY: `Device` only holds a pointer to a C device, references to which are safe to be used
> +// from any thread.
> +unsafe impl<T: drm::drv::Driver> Sync for Device<T> {}
> +
> +// Make drm::Device work for dev_info!() and friends
> +unsafe impl<T: drm::drv::Driver> device::RawDevice for Device<T> {
> + fn raw_device(&self) -> *mut bindings::device {
> + // SAFETY: ptr must be valid per the type invariant
> + unsafe { (*self.ptr).dev }
> + }
> +}
> diff --git a/rust/kernel/drm/drv.rs b/rust/kernel/drm/drv.rs
> new file mode 100644
> index 000000000000..29a465515dc9
> --- /dev/null
> +++ b/rust/kernel/drm/drv.rs
> @@ -0,0 +1,339 @@
> +// SPDX-License-Identifier: GPL-2.0 OR MIT
> +
> +//! DRM driver core.
> +//!
> +//! C header: [`include/linux/drm/drm_drv.h`](../../../../include/linux/drm/drm_drv.h)
> +
> +use crate::{
> + bindings, device, drm,
> + error::code::*,
> + error::from_kernel_err_ptr,
> + error::{Error, Result},
> + prelude::*,
> + private::Sealed,
> + str::CStr,
> + types::ForeignOwnable,
> + ThisModule,
> +};
> +use core::{
> + marker::{PhantomData, PhantomPinned},
> + pin::Pin,
> +};
> +use macros::vtable;
> +
> +/// Driver use the GEM memory manager. This should be set for all modern drivers.
> +pub const FEAT_GEM: u32 = bindings::drm_driver_feature_DRIVER_GEM;
> +/// Driver supports mode setting interfaces (KMS).
> +pub const FEAT_MODESET: u32 = bindings::drm_driver_feature_DRIVER_MODESET;
> +/// Driver supports dedicated render nodes.
> +pub const FEAT_RENDER: u32 = bindings::drm_driver_feature_DRIVER_RENDER;
> +/// Driver supports the full atomic modesetting userspace API.
> +///
> +/// Drivers which only use atomic internally, but do not support the full userspace API (e.g. not
> +/// all properties converted to atomic, or multi-plane updates are not guaranteed to be tear-free)
> +/// should not set this flag.
> +pub const FEAT_ATOMIC: u32 = bindings::drm_driver_feature_DRIVER_ATOMIC;
> +/// Driver supports DRM sync objects for explicit synchronization of command submission.
> +pub const FEAT_SYNCOBJ: u32 = bindings::drm_driver_feature_DRIVER_SYNCOBJ;
> +/// Driver supports the timeline flavor of DRM sync objects for explicit synchronization of command
> +/// submission.
> +pub const FEAT_SYNCOBJ_TIMELINE: u32 = bindings::drm_driver_feature_DRIVER_SYNCOBJ_TIMELINE;
> +
> +/// Information data for a DRM Driver.
> +pub struct DriverInfo {
> + /// Driver major version.
> + pub major: i32,
> + /// Driver minor version.
> + pub minor: i32,
> + /// Driver patchlevel version.
> + pub patchlevel: i32,
> + /// Driver name.
> + pub name: &'static CStr,
> + /// Driver description.
> + pub desc: &'static CStr,
> + /// Driver date.
> + pub date: &'static CStr,
> +}
> +
Could you please add an Invariants section to the doc comments indicating what requirements these function pointers must satisfy?
> +/// Internal memory management operation set, normally created by memory managers (e.g. GEM).
> +///
> +/// See `kernel::drm::gem` and `kernel::drm::gem::shmem`.
> +pub struct AllocOps {
> + pub(crate) gem_create_object: Option<
> + unsafe extern "C" fn(
> + dev: *mut bindings::drm_device,
> + size: usize,
> + ) -> *mut bindings::drm_gem_object,
> + >,
> + pub(crate) prime_handle_to_fd: Option<
> + unsafe extern "C" fn(
> + dev: *mut bindings::drm_device,
> + file_priv: *mut bindings::drm_file,
> + handle: u32,
> + flags: u32,
> + prime_fd: *mut core::ffi::c_int,
> + ) -> core::ffi::c_int,
> + >,
> + pub(crate) prime_fd_to_handle: Option<
> + unsafe extern "C" fn(
> + dev: *mut bindings::drm_device,
> + file_priv: *mut bindings::drm_file,
> + prime_fd: core::ffi::c_int,
> + handle: *mut u32,
> + ) -> core::ffi::c_int,
> + >,
> + pub(crate) gem_prime_import: Option<
> + unsafe extern "C" fn(
> + dev: *mut bindings::drm_device,
> + dma_buf: *mut bindings::dma_buf,
> + ) -> *mut bindings::drm_gem_object,
> + >,
> + pub(crate) gem_prime_import_sg_table: Option<
> + unsafe extern "C" fn(
> + dev: *mut bindings::drm_device,
> + attach: *mut bindings::dma_buf_attachment,
> + sgt: *mut bindings::sg_table,
> + ) -> *mut bindings::drm_gem_object,
> + >,
> + pub(crate) gem_prime_mmap: Option<
> + unsafe extern "C" fn(
> + obj: *mut bindings::drm_gem_object,
> + vma: *mut bindings::vm_area_struct,
> + ) -> core::ffi::c_int,
> + >,
> + pub(crate) dumb_create: Option<
> + unsafe extern "C" fn(
> + file_priv: *mut bindings::drm_file,
> + dev: *mut bindings::drm_device,
> + args: *mut bindings::drm_mode_create_dumb,
> + ) -> core::ffi::c_int,
> + >,
> + pub(crate) dumb_map_offset: Option<
> + unsafe extern "C" fn(
> + file_priv: *mut bindings::drm_file,
> + dev: *mut bindings::drm_device,
> + handle: u32,
> + offset: *mut u64,
> + ) -> core::ffi::c_int,
> + >,
> + pub(crate) dumb_destroy: Option<
> + unsafe extern "C" fn(
> + file_priv: *mut bindings::drm_file,
> + dev: *mut bindings::drm_device,
> + handle: u32,
> + ) -> core::ffi::c_int,
> + >,
> +}
> +
> +/// Trait for memory manager implementations. Implemented internally.
> +pub trait AllocImpl: Sealed {
> + /// The C callback operations for this memory manager.
> + const ALLOC_OPS: AllocOps;
> +}
> +
> +/// A DRM driver implementation.
> +#[vtable]
> +pub trait Driver {
> + /// Context data associated with the DRM driver
> + ///
> + /// Determines the type of the context data passed to each of the methods of the trait.
> + type Data: ForeignOwnable + Sync + Send;
> +
> + /// The type used to manage memory for this driver.
> + ///
> + /// Should be either `drm::gem::Object<T>` or `drm::gem::shmem::Object<T>`.
> + type Object: AllocImpl;
> +
> + /// Driver metadata
> + const INFO: DriverInfo;
> +
> + /// Feature flags
> + const FEATURES: u32;
> +
> + /// IOCTL list. See `kernel::drm::ioctl::declare_drm_ioctls!{}`.
> + const IOCTLS: &'static [drm::ioctl::DrmIoctlDescriptor];
> +}
> +
> +/// A registration of a DRM device
> +///
> +/// # Invariants:
> +///
> +/// drm is always a valid pointer to an allocated drm_device
> +pub struct Registration<T: Driver> {
> + drm: drm::device::Device<T>,
> + registered: bool,
> + fops: bindings::file_operations,
> + vtable: Pin<Box<bindings::drm_driver>>,
> + _p: PhantomData<T>,
> + _pin: PhantomPinned,
> +}
> +
> +#[cfg(CONFIG_DRM_LEGACY)]
> +macro_rules! drm_legacy_fields {
> + ( $($field:ident: $val:expr),* $(,)? ) => {
> + bindings::drm_driver {
> + $( $field: $val ),*,
> + firstopen: None,
> + preclose: None,
> + dma_ioctl: None,
> + dma_quiescent: None,
> + context_dtor: None,
> + irq_handler: None,
> + irq_preinstall: None,
> + irq_postinstall: None,
> + irq_uninstall: None,
> + get_vblank_counter: None,
> + enable_vblank: None,
> + disable_vblank: None,
> + dev_priv_size: 0,
> + }
> + }
> +}
> +
> +#[cfg(not(CONFIG_DRM_LEGACY))]
> +macro_rules! drm_legacy_fields {
> + ( $($field:ident: $val:expr),* $(,)? ) => {
> + bindings::drm_driver {
> + $( $field: $val ),*
> + }
> + }
> +}
> +
> +/// Registers a DRM device with the rest of the kernel.
> +///
> +/// It automatically picks up THIS_MODULE.
> +#[allow(clippy::crate_in_macro_def)]
> +#[macro_export]
> +macro_rules! drm_device_register {
> + ($reg:expr, $data:expr, $flags:expr $(,)?) => {{
> + $crate::drm::drv::Registration::register($reg, $data, $flags, &crate::THIS_MODULE)
> + }};
> +}
> +
> +impl<T: Driver> Registration<T> {
> + const VTABLE: bindings::drm_driver = drm_legacy_fields! {
> + load: None,
> + open: None, // TODO: File abstraction
> + postclose: None, // TODO: File abstraction
> + lastclose: None,
> + unload: None,
> + release: None,
> + master_set: None,
> + master_drop: None,
> + debugfs_init: None,
> + gem_create_object: T::Object::ALLOC_OPS.gem_create_object,
> + prime_handle_to_fd: T::Object::ALLOC_OPS.prime_handle_to_fd,
> + prime_fd_to_handle: T::Object::ALLOC_OPS.prime_fd_to_handle,
> + gem_prime_import: T::Object::ALLOC_OPS.gem_prime_import,
> + gem_prime_import_sg_table: T::Object::ALLOC_OPS.gem_prime_import_sg_table,
> + gem_prime_mmap: T::Object::ALLOC_OPS.gem_prime_mmap,
> + dumb_create: T::Object::ALLOC_OPS.dumb_create,
> + dumb_map_offset: T::Object::ALLOC_OPS.dumb_map_offset,
> + dumb_destroy: T::Object::ALLOC_OPS.dumb_destroy,
> +
> + major: T::INFO.major,
> + minor: T::INFO.minor,
> + patchlevel: T::INFO.patchlevel,
> + name: T::INFO.name.as_char_ptr() as *mut _,
> + desc: T::INFO.desc.as_char_ptr() as *mut _,
> + date: T::INFO.date.as_char_ptr() as *mut _,
> +
> + driver_features: T::FEATURES,
> + ioctls: T::IOCTLS.as_ptr(),
> + num_ioctls: T::IOCTLS.len() as i32,
> + fops: core::ptr::null_mut(),
> + };
> +
> + /// Creates a new [`Registration`] but does not register it yet.
> + ///
> + /// It is allowed to move.
> + pub fn new(parent: &dyn device::RawDevice) -> Result<Self> {
> + let vtable = Pin::new(Box::try_new(Self::VTABLE)?);
> + let raw_drm = unsafe { bindings::drm_dev_alloc(&*vtable, parent.raw_device()) };
> + let raw_drm = from_kernel_err_ptr(raw_drm)?;
> +
> + // The reference count is one, and now we take ownership of that reference as a
> + // drm::device::Device.
> + let drm = unsafe { drm::device::Device::from_raw(raw_drm) };
> +
> + Ok(Self {
> + drm,
> + registered: false,
> + vtable,
> + fops: Default::default(), // TODO: GEM abstraction
> + _pin: PhantomPinned,
> + _p: PhantomData,
> + })
> + }
> +
> + /// Registers a DRM device with the rest of the kernel.
> + ///
> + /// Users are encouraged to use the [`drm_device_register!()`] macro because it automatically
> + /// picks up the current module.
> + pub fn register(
> + self: Pin<&mut Self>,
> + data: T::Data,
> + flags: usize,
> + module: &'static ThisModule,
> + ) -> Result {
> + if self.registered {
> + // Already registered.
> + return Err(EINVAL);
> + }
> +
> + // SAFETY: We never move out of `this`.
> + let this = unsafe { self.get_unchecked_mut() };
> + let data_pointer = <T::Data as ForeignOwnable>::into_foreign(data);
> + // SAFETY: `drm` is valid per the type invariant
> + unsafe {
> + (*this.drm.raw_mut()).dev_private = data_pointer as *mut _;
> + }
> +
> + this.fops.owner = module.0;
> + this.vtable.fops = &this.fops;
> +
> + // SAFETY: The device is now initialized and ready to be registered.
> + let ret = unsafe { bindings::drm_dev_register(this.drm.raw_mut(), flags as u64) };
> + if ret < 0 {
> + // SAFETY: `data_pointer` was returned by `into_foreign` above.
> + unsafe { T::Data::from_foreign(data_pointer) };
> + return Err(Error::from_kernel_errno(ret));
> + }
> +
> + this.registered = true;
> + Ok(())
> + }
> +
> + /// Returns a reference to the `Device` instance for this registration.
> + pub fn device(&self) -> &drm::device::Device<T> {
> + &self.drm
> + }
> +}
> +
> +// SAFETY: `Registration` doesn't offer any methods or access to fields when shared between threads
> +// or CPUs, so it is safe to share it.
> +unsafe impl<T: Driver> Sync for Registration<T> {}
> +
> +// SAFETY: Registration with and unregistration from the drm subsystem can happen from any thread.
> +// Additionally, `T::Data` (which is dropped during unregistration) is `Send`, so it is ok to move
> +// `Registration` to different threads.
> +#[allow(clippy::non_send_fields_in_send_ty)]
> +unsafe impl<T: Driver> Send for Registration<T> {}
> +
> +impl<T: Driver> Drop for Registration<T> {
> + /// Removes the registration from the kernel if it has completed successfully before.
> + fn drop(&mut self) {
> + if self.registered {
> + // Get a pointer to the data stored in device before destroying it.
> + // SAFETY: `drm` is valid per the type invariant
> + let data_pointer = unsafe { (*self.drm.raw_mut()).dev_private };
> +
> + // SAFETY: Since `registered` is true, `self.drm` is both valid and registered.
> + unsafe { bindings::drm_dev_unregister(self.drm.raw_mut()) };
> +
> + // Free data as well.
> + // SAFETY: `data_pointer` was returned by `into_foreign` during registration.
> + unsafe { <T::Data as ForeignOwnable>::from_foreign(data_pointer) };
> + }
> + }
> +}
> diff --git a/rust/kernel/drm/mod.rs b/rust/kernel/drm/mod.rs
> index 9ec6d7cbcaf3..69376b3c6db9 100644
> --- a/rust/kernel/drm/mod.rs
> +++ b/rust/kernel/drm/mod.rs
> @@ -2,4 +2,6 @@
>
> //! DRM subsystem abstractions.
>
> +pub mod device;
> +pub mod drv;
> pub mod ioctl;
>
> --
> 2.35.1
Cheers,
Bjorn
^ permalink raw reply [flat|nested] 122+ messages in thread* Re: [PATCH RFC 02/18] rust: drm: Add Device and Driver abstractions
2023-03-07 18:19 ` Björn Roy Baron
@ 2023-03-09 6:10 ` Asahi Lina
0 siblings, 0 replies; 122+ messages in thread
From: Asahi Lina @ 2023-03-09 6:10 UTC (permalink / raw)
To: Björn Roy Baron
Cc: Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
David Airlie, Daniel Vetter, Miguel Ojeda, Alex Gaynor,
Wedson Almeida Filho, Boqun Feng, Gary Guo, Sumit Semwal,
Christian König, Luben Tuikov, Jarkko Sakkinen, Dave Hansen,
Alyssa Rosenzweig, Karol Herbst, Ella Stanforth, Faith Ekstrand,
Mary, linux-kernel, dri-devel, rust-for-linux, linux-media,
linaro-mm-sig, linux-sgx, asahi
On 08/03/2023 03.19, Björn Roy Baron wrote:
> ------- Original Message -------
> On Tuesday, March 7th, 2023 at 15:25, Asahi Lina <lina@asahilina.net> wrote:
>
>> Add the initial abstractions for DRM drivers and devices. These go
>> together in one commit since they are fairly tightly coupled types.
>>
>> A few things have been stubbed out, to be implemented as further bits of
>> the DRM subsystem are introduced.
>>
>> Signed-off-by: Asahi Lina lina@asahilina.net
>>
>> ---
[...]
>> +/// Information data for a DRM Driver.
>> +pub struct DriverInfo {
>> + /// Driver major version.
>> + pub major: i32,
>> + /// Driver minor version.
>> + pub minor: i32,
>> + /// Driver patchlevel version.
>> + pub patchlevel: i32,
>> + /// Driver name.
>> + pub name: &'static CStr,
>> + /// Driver description.
>> + pub desc: &'static CStr,
>> + /// Driver date.
>> + pub date: &'static CStr,
>> +}
>> +
>
> Could you please add an Invariants section to the doc comments indicating what requirements these function pointers must satisfy?
I can try (as much as I can divine from the C side anyway...). I guess
you want interface docs for each callback, so like what it must do and
what invariants each one must uphold?
Note that this is a kernel crate-only struct (the fields are not public)
so users can't create their own AllocOps variants anyway (plus AllocImpl
is sealed, on top of that), but I guess it makes sense to document for
internal kernel crate purposes. At some point it might make sense to
allow drivers to override these with proper Rust callbacks (and then the
wrappers need to ensure safety), but right now that's not implemented.
>> +/// Internal memory management operation set, normally created by memory managers (e.g. GEM).
>> +///
>> +/// See `kernel::drm::gem` and `kernel::drm::gem::shmem`.
>> +pub struct AllocOps {
>> + pub(crate) gem_create_object: Option<
>> + unsafe extern "C" fn(
>> + dev: *mut bindings::drm_device,
>> + size: usize,
>> + ) -> *mut bindings::drm_gem_object,
>> + >,
>> + pub(crate) prime_handle_to_fd: Option<
>> + unsafe extern "C" fn(
>> + dev: *mut bindings::drm_device,
>> + file_priv: *mut bindings::drm_file,
>> + handle: u32,
>> + flags: u32,
>> + prime_fd: *mut core::ffi::c_int,
>> + ) -> core::ffi::c_int,
>> + >,
>> + pub(crate) prime_fd_to_handle: Option<
>> + unsafe extern "C" fn(
>> + dev: *mut bindings::drm_device,
>> + file_priv: *mut bindings::drm_file,
>> + prime_fd: core::ffi::c_int,
>> + handle: *mut u32,
>> + ) -> core::ffi::c_int,
>> + >,
>> + pub(crate) gem_prime_import: Option<
>> + unsafe extern "C" fn(
>> + dev: *mut bindings::drm_device,
>> + dma_buf: *mut bindings::dma_buf,
>> + ) -> *mut bindings::drm_gem_object,
>> + >,
>> + pub(crate) gem_prime_import_sg_table: Option<
>> + unsafe extern "C" fn(
>> + dev: *mut bindings::drm_device,
>> + attach: *mut bindings::dma_buf_attachment,
>> + sgt: *mut bindings::sg_table,
>> + ) -> *mut bindings::drm_gem_object,
>> + >,
>> + pub(crate) gem_prime_mmap: Option<
>> + unsafe extern "C" fn(
>> + obj: *mut bindings::drm_gem_object,
>> + vma: *mut bindings::vm_area_struct,
>> + ) -> core::ffi::c_int,
>> + >,
>> + pub(crate) dumb_create: Option<
>> + unsafe extern "C" fn(
>> + file_priv: *mut bindings::drm_file,
>> + dev: *mut bindings::drm_device,
>> + args: *mut bindings::drm_mode_create_dumb,
>> + ) -> core::ffi::c_int,
>> + >,
>> + pub(crate) dumb_map_offset: Option<
>> + unsafe extern "C" fn(
>> + file_priv: *mut bindings::drm_file,
>> + dev: *mut bindings::drm_device,
>> + handle: u32,
>> + offset: *mut u64,
>> + ) -> core::ffi::c_int,
>> + >,
>> + pub(crate) dumb_destroy: Option<
>> + unsafe extern "C" fn(
>> + file_priv: *mut bindings::drm_file,
>> + dev: *mut bindings::drm_device,
>> + handle: u32,
>> + ) -> core::ffi::c_int,
>> + >,
>> +}
>> +
~~ Lina
^ permalink raw reply [flat|nested] 122+ messages in thread
* Re: [PATCH RFC 02/18] rust: drm: Add Device and Driver abstractions
2023-03-07 14:25 ` [PATCH RFC 02/18] rust: drm: Add Device and Driver abstractions Asahi Lina
2023-03-07 18:19 ` Björn Roy Baron
@ 2023-03-10 18:56 ` Boqun Feng
2023-03-11 5:41 ` Boqun Feng
2023-04-05 17:10 ` Daniel Vetter
3 siblings, 0 replies; 122+ messages in thread
From: Boqun Feng @ 2023-03-10 18:56 UTC (permalink / raw)
To: Asahi Lina
Cc: Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
David Airlie, Daniel Vetter, Miguel Ojeda, Alex Gaynor,
Wedson Almeida Filho, Gary Guo, Björn Roy Baron,
Sumit Semwal, Christian König, Luben Tuikov,
Jarkko Sakkinen, Dave Hansen, Alyssa Rosenzweig, Karol Herbst,
Ella Stanforth, Faith Ekstrand, Mary, linux-kernel, dri-devel,
rust-for-linux, linux-media, linaro-mm-sig, linux-sgx, asahi
On Tue, Mar 07, 2023 at 11:25:27PM +0900, Asahi Lina wrote:
[...]
> +
> +// SAFETY: `Device` only holds a pointer to a C device, which is safe to be used from any thread.
> +unsafe impl<T: drm::drv::Driver> Send for Device<T> {}
> +
> +// SAFETY: `Device` only holds a pointer to a C device, references to which are safe to be used
> +// from any thread.
> +unsafe impl<T: drm::drv::Driver> Sync for Device<T> {}
> +
Here is the mind model I use to check whether a type is `Send` or
`Sync`
* If an object of a type can be created on one thread and dropped
on the another thread, then it's `Send`.
* If multiple threads can call the immutable functions (i.e.
functions with `&self`) of the same object of a type, then the
it's `Sync`.
Maybe it's incomplete, but at least I find it useful to determine
whether a type is `Send` or `Sync`: it's not just the struct
representation, the behaviors (functions) of the struct also matter.
If that looks reasonable to you, maybe update the "SAFETY" comments in
the future version? Thanks ;-)
(I know you brought this up in the meeting, sorry I guess I wasn't fully
woken when answering you ;-))
Regards,
Boqun
> +// Make drm::Device work for dev_info!() and friends
> +unsafe impl<T: drm::drv::Driver> device::RawDevice for Device<T> {
> + fn raw_device(&self) -> *mut bindings::device {
> + // SAFETY: ptr must be valid per the type invariant
> + unsafe { (*self.ptr).dev }
> + }
> +}
[...]
^ permalink raw reply [flat|nested] 122+ messages in thread* Re: [PATCH RFC 02/18] rust: drm: Add Device and Driver abstractions
2023-03-07 14:25 ` [PATCH RFC 02/18] rust: drm: Add Device and Driver abstractions Asahi Lina
2023-03-07 18:19 ` Björn Roy Baron
2023-03-10 18:56 ` Boqun Feng
@ 2023-03-11 5:41 ` Boqun Feng
2023-04-05 17:10 ` Daniel Vetter
3 siblings, 0 replies; 122+ messages in thread
From: Boqun Feng @ 2023-03-11 5:41 UTC (permalink / raw)
To: Asahi Lina
Cc: Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
David Airlie, Daniel Vetter, Miguel Ojeda, Alex Gaynor,
Wedson Almeida Filho, Gary Guo, Björn Roy Baron,
Sumit Semwal, Christian König, Luben Tuikov,
Jarkko Sakkinen, Dave Hansen, Alyssa Rosenzweig, Karol Herbst,
Ella Stanforth, Faith Ekstrand, Mary, linux-kernel, dri-devel,
rust-for-linux, linux-media, linaro-mm-sig, linux-sgx, asahi
On Tue, Mar 07, 2023 at 11:25:27PM +0900, Asahi Lina wrote:
> Add the initial abstractions for DRM drivers and devices. These go
> together in one commit since they are fairly tightly coupled types.
>
> A few things have been stubbed out, to be implemented as further bits of
> the DRM subsystem are introduced.
>
> Signed-off-by: Asahi Lina <lina@asahilina.net>
> ---
> rust/bindings/bindings_helper.h | 3 +
> rust/kernel/drm/device.rs | 76 +++++++++
> rust/kernel/drm/drv.rs | 339 ++++++++++++++++++++++++++++++++++++++++
> rust/kernel/drm/mod.rs | 2 +
> 4 files changed, 420 insertions(+)
>
> diff --git a/rust/bindings/bindings_helper.h b/rust/bindings/bindings_helper.h
> index 2687bef1676f..2a999138c4ae 100644
> --- a/rust/bindings/bindings_helper.h
> +++ b/rust/bindings/bindings_helper.h
> @@ -6,10 +6,13 @@
> * Sorted alphabetically.
> */
>
> +#include <drm/drm_device.h>
> +#include <drm/drm_drv.h>
> #include <drm/drm_ioctl.h>
> #include <linux/delay.h>
> #include <linux/device.h>
> #include <linux/dma-mapping.h>
> +#include <linux/fs.h>
> #include <linux/ioctl.h>
> #include <linux/io-pgtable.h>
> #include <linux/ktime.h>
> diff --git a/rust/kernel/drm/device.rs b/rust/kernel/drm/device.rs
> new file mode 100644
> index 000000000000..6007f941137a
> --- /dev/null
> +++ b/rust/kernel/drm/device.rs
> @@ -0,0 +1,76 @@
> +// SPDX-License-Identifier: GPL-2.0 OR MIT
> +
> +//! DRM device.
> +//!
> +//! C header: [`include/linux/drm/drm_device.h`](../../../../include/linux/drm/drm_device.h)
> +
> +use crate::{bindings, device, drm, types::ForeignOwnable};
> +use core::marker::PhantomData;
> +
> +/// Represents a reference to a DRM device. The device is reference-counted and is guaranteed to
> +/// not be dropped while this object is alive.
> +pub struct Device<T: drm::drv::Driver> {
> + // Type invariant: ptr must be a valid and initialized drm_device,
> + // and this value must either own a reference to it or the caller
> + // must ensure that it is never dropped if the reference is borrowed.
> + pub(super) ptr: *mut bindings::drm_device,
> + _p: PhantomData<T>,
> +}
> +
> +impl<T: drm::drv::Driver> Device<T> {
> + // Not intended to be called externally, except via declare_drm_ioctls!()
> + #[doc(hidden)]
> + pub unsafe fn from_raw(raw: *mut bindings::drm_device) -> Device<T> {
> + Device {
> + ptr: raw,
> + _p: PhantomData,
> + }
> + }
> +
> + #[allow(dead_code)]
> + pub(crate) fn raw(&self) -> *const bindings::drm_device {
> + self.ptr
> + }
> +
> + pub(crate) fn raw_mut(&mut self) -> *mut bindings::drm_device {
> + self.ptr
> + }
Since you can always get a *mut bindings::drm_device safely from
a.raw() as *mut _
, this mutable version seems unnecesarry to me. In other words, no way
to prevent getting a *mut bindings::drm_device from only &Device.
Regards,
Boqun
> +
> + /// Returns a borrowed reference to the user data associated with this Device.
> + pub fn data(&self) -> <T::Data as ForeignOwnable>::Borrowed<'_> {
> + unsafe { T::Data::borrow((*self.ptr).dev_private) }
> + }
> +}
> +
[...]
^ permalink raw reply [flat|nested] 122+ messages in thread* Re: [PATCH RFC 02/18] rust: drm: Add Device and Driver abstractions
2023-03-07 14:25 ` [PATCH RFC 02/18] rust: drm: Add Device and Driver abstractions Asahi Lina
` (2 preceding siblings ...)
2023-03-11 5:41 ` Boqun Feng
@ 2023-04-05 17:10 ` Daniel Vetter
3 siblings, 0 replies; 122+ messages in thread
From: Daniel Vetter @ 2023-04-05 17:10 UTC (permalink / raw)
To: Asahi Lina
Cc: Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
David Airlie, Daniel Vetter, Miguel Ojeda, Alex Gaynor,
Wedson Almeida Filho, Boqun Feng, Gary Guo, Björn Roy Baron,
Sumit Semwal, Christian König, Luben Tuikov,
Jarkko Sakkinen, Dave Hansen, Alyssa Rosenzweig, Karol Herbst,
Ella Stanforth, Faith Ekstrand, Mary, linux-kernel, dri-devel,
rust-for-linux, linux-media, linaro-mm-sig, linux-sgx, asahi
On Tue, Mar 07, 2023 at 11:25:27PM +0900, Asahi Lina wrote:
> Add the initial abstractions for DRM drivers and devices. These go
> together in one commit since they are fairly tightly coupled types.
>
> A few things have been stubbed out, to be implemented as further bits of
> the DRM subsystem are introduced.
>
> Signed-off-by: Asahi Lina <lina@asahilina.net>
Ok so this is fairly fundamental lifetime fun and might be fairly
orthogonal to most of the things you actually want to do with a drm driver
(like implement gem or whatever). So separate mail.
So upfront short intro. There's 3 different lifetimes involved in building
a drm driver:
- struct drm_driver. It's refcounted because it's fundamentally an uapi
interface thing, and all the various uapi interfaces that build on top
of this (drm_file, dma_buf, ...) need to hold references on it. It's
supposed to survive for as long as userspace needs it or the underlying
driver is bound, whichever is longer.
- struct device. Refcounted and good for dmesg printing, nothing else.
Yes, because ...
- ... the actual hardware resource, in many places also represented by struct
device. Not refcounted, instead it's limited by hotunplug or more
precisiely, how long your driver is bound to the struct device. You
could make a case that in C this is represented by the bus specific type
(e.g. platform_device), and the bus-specific hooks delineate the
lifetime (for platform devices that's that's from ->probe to ->remove).
Since there's no C type for this I'll call this hwdevice.
I think for rust it would be good if we model a bit more precisely in
rust. It might be possible to use the bus-specific types as the hwdevice,
but that's not entirely right either because each bus device is both
representing the hwdevice and the refcounted struct device.
Now onto lifetimes, or at least how this is usually handled.
- struct device should be obvious, the important part really is that the
rust wrappers should not allow anything to be done with that which is
tied to the hwdevice lifetime. Which is almost everything you want to do
with a struct (platform_)device (aside from pure sw stuff like dmesg
printing).
- the hwdevice is _not_ refcounted. I think in rust this maps to borrow
semantics, to make sure that the reference only stays valid during a
driver callback. The driver core/bus driver ensure that all the various
callbacks (pm_ops, platform_driver, ...) finish before the ->remove
callback starts.
- usually the the link from hwdevice to drm_device is done with a
refcounted drm_device stored with dev_set_drvdata. For rust it'd be nice
if that's the Driver and fully typesafe and automatically cleaned up.
- which brings us to how hwdevice cleanup works in C: That's done with all
the devm_ helpers for practically anything you might want to set up for
hw access: mappings, interrupts, .... Note that there's also
devm_*malloc functions, when drivers use them that's almost always a bug
because generally allocations should stick around with the drm_device
and not go down with the non-refcounted hwdevice lifetime.
For added fun the bus/driver core also uses devm_ to mange things tied
to the refcounted struct device, which works because devm_ nests and
->probe opens up a new devm_ bucket which is torn down at ->remove time.
But luckily drivers should never deal with that, so for them (on the C
side at least) devm_ is the right lifetime model for things tied to the
hwdevice lifetime.
For rust this means that we really should try to tie all the hw related
things into devm or equivalent, and make both sure it's automatically
cleaned up at that point, but also no later (because if you clean up hw
stuff after ->remove you have a driver bug).
- Similarly on the drm_device side we have drmm_. You can have some
refcounted things within the lifetime of drm_device (like dma_buf), but
if things the driver creates survive past the point of drm_device, then
probably something went really wrong. Either a leak or you'll blow up in
the C code.
So again for rust I think we should try to model this, and make sure
(with borrow semantics and avoiding full refcounting like the plague in
driver code) that driver structs and other sw things can't outlive the
drm_device, but also don't hold it alive unduly.
- Since the point of a drm_device is to drive hardware, you need to be
able to safely dereference the drm_device->dev pointer and know whether
it's still a hwdevice (i.e. useful) or just a struct device because the
hw is gone. That's done with drm_dev_enter/exit and making sure that
->remove calls drm_dev_unplug as the very first thing, before it starts
tearing down hw resources like mappings, interrupts, ...
On the C side we entirely rely on review for this, and it just doesn't
work. Unless exhaustively tested, hotunplug just dies, and I think for
more complex drivers this is something where Rust type enforcement could
really shine: We'd need to make sure that a driver can only get at the
hwtype where it's safe (bus/driver core callbacks or drm_dev_enter/exit
as a mutex-guard thing). Furthermore we need to ensure that that
drm_dev_unplug really is the first thing done in ->remove (and by
symmetry drm_dev_register the last thing probe does). I think a neat way
would be if ->probe would return a container of things that implement a
Uapi trait, which has register and unplug functions, and then the rust
glue calls that.
More aggressively would be to outright not implement ->remove for rust
drivers and entirely rely on the devm stack of cleanup actions. This
would still need a type trick to ensure that drm_dev_register is the
very last thing that's called (to make sure the matching drm_dev_unplug
is the first thing).
- Despite that we have refcounted pointers going both ways from
drm_device<->device there's no loop, because the device->drm_device
reference is dropped with hwdevice lifetime (through devm if you're
using devm_drm_dev_alloc in a C driver), which breaks the loop. Note
that the drm_device->device refcount/pointer stays until the very end of
drm_device (need that for dmesg printing), but outside of
drm_dev_enter/exit it's really just a temption for bugs.
- I think ideally drivers themselves should not even try to refcount
drm_device or device, but instead have all it all tied directly. The
exceptions really are only for when you have separate, free-standing
uapi objects (like dma_buf or dma_fence or drm_file), and in those cases
the combo of C code + rust glue should ensure that the refcounting is
done right. If a rust driver has any additional refcounting need for
these structs then I think we've screwed up the data lifetime model.
Apologies for the wall of text. I hope I didn't forget anything crucial,
I've been pondering this for a few weeks now :-)
Imo this doesn't need to be fixed before we merge asahi, but it is
something that I think really should fix because despite years of effort
and all the auto-cleanup infrastructure like devm_ and drmm_ C drivers are
still buggy by default, there's no clear understanding outside of a select
few about the problems ("devm_kmalloc considered harmful" is some actual
talk title), and I think this is something where Rust typing and borrow
checker really could substantially improve the state of the art.
And yes for a soc driver that's all fairly irrelevant, because it's
physically not possible to remove a device, but for most drm drivers it is
absolutely possible to burn them with a hotunplug (hotunplug of device
pass-through to a vm if you can't physically hotunplug the device itself),
so this isn't academic at all.
I'll try and type up the separate mail about semantics of gem drivers and
all that stuff tomorrow.
Cheers, Daniel
> ---
> rust/bindings/bindings_helper.h | 3 +
> rust/kernel/drm/device.rs | 76 +++++++++
> rust/kernel/drm/drv.rs | 339 ++++++++++++++++++++++++++++++++++++++++
> rust/kernel/drm/mod.rs | 2 +
> 4 files changed, 420 insertions(+)
>
> diff --git a/rust/bindings/bindings_helper.h b/rust/bindings/bindings_helper.h
> index 2687bef1676f..2a999138c4ae 100644
> --- a/rust/bindings/bindings_helper.h
> +++ b/rust/bindings/bindings_helper.h
> @@ -6,10 +6,13 @@
> * Sorted alphabetically.
> */
>
> +#include <drm/drm_device.h>
> +#include <drm/drm_drv.h>
> #include <drm/drm_ioctl.h>
> #include <linux/delay.h>
> #include <linux/device.h>
> #include <linux/dma-mapping.h>
> +#include <linux/fs.h>
> #include <linux/ioctl.h>
> #include <linux/io-pgtable.h>
> #include <linux/ktime.h>
> diff --git a/rust/kernel/drm/device.rs b/rust/kernel/drm/device.rs
> new file mode 100644
> index 000000000000..6007f941137a
> --- /dev/null
> +++ b/rust/kernel/drm/device.rs
> @@ -0,0 +1,76 @@
> +// SPDX-License-Identifier: GPL-2.0 OR MIT
> +
> +//! DRM device.
> +//!
> +//! C header: [`include/linux/drm/drm_device.h`](../../../../include/linux/drm/drm_device.h)
> +
> +use crate::{bindings, device, drm, types::ForeignOwnable};
> +use core::marker::PhantomData;
> +
> +/// Represents a reference to a DRM device. The device is reference-counted and is guaranteed to
> +/// not be dropped while this object is alive.
> +pub struct Device<T: drm::drv::Driver> {
> + // Type invariant: ptr must be a valid and initialized drm_device,
> + // and this value must either own a reference to it or the caller
> + // must ensure that it is never dropped if the reference is borrowed.
> + pub(super) ptr: *mut bindings::drm_device,
> + _p: PhantomData<T>,
> +}
> +
> +impl<T: drm::drv::Driver> Device<T> {
> + // Not intended to be called externally, except via declare_drm_ioctls!()
> + #[doc(hidden)]
> + pub unsafe fn from_raw(raw: *mut bindings::drm_device) -> Device<T> {
> + Device {
> + ptr: raw,
> + _p: PhantomData,
> + }
> + }
> +
> + #[allow(dead_code)]
> + pub(crate) fn raw(&self) -> *const bindings::drm_device {
> + self.ptr
> + }
> +
> + pub(crate) fn raw_mut(&mut self) -> *mut bindings::drm_device {
> + self.ptr
> + }
> +
> + /// Returns a borrowed reference to the user data associated with this Device.
> + pub fn data(&self) -> <T::Data as ForeignOwnable>::Borrowed<'_> {
> + unsafe { T::Data::borrow((*self.ptr).dev_private) }
> + }
> +}
> +
> +impl<T: drm::drv::Driver> Drop for Device<T> {
> + fn drop(&mut self) {
> + // SAFETY: By the type invariants, we know that `self` owns a reference, so it is safe to
> + // relinquish it now.
> + unsafe { bindings::drm_dev_put(self.ptr) };
> + }
> +}
> +
> +impl<T: drm::drv::Driver> Clone for Device<T> {
> + fn clone(&self) -> Self {
> + // SAFETY: We get a new reference and then create a new owning object from the raw pointer
> + unsafe {
> + bindings::drm_dev_get(self.ptr);
> + Device::from_raw(self.ptr)
> + }
> + }
> +}
> +
> +// SAFETY: `Device` only holds a pointer to a C device, which is safe to be used from any thread.
> +unsafe impl<T: drm::drv::Driver> Send for Device<T> {}
> +
> +// SAFETY: `Device` only holds a pointer to a C device, references to which are safe to be used
> +// from any thread.
> +unsafe impl<T: drm::drv::Driver> Sync for Device<T> {}
> +
> +// Make drm::Device work for dev_info!() and friends
> +unsafe impl<T: drm::drv::Driver> device::RawDevice for Device<T> {
> + fn raw_device(&self) -> *mut bindings::device {
> + // SAFETY: ptr must be valid per the type invariant
> + unsafe { (*self.ptr).dev }
> + }
> +}
> diff --git a/rust/kernel/drm/drv.rs b/rust/kernel/drm/drv.rs
> new file mode 100644
> index 000000000000..29a465515dc9
> --- /dev/null
> +++ b/rust/kernel/drm/drv.rs
> @@ -0,0 +1,339 @@
> +// SPDX-License-Identifier: GPL-2.0 OR MIT
> +
> +//! DRM driver core.
> +//!
> +//! C header: [`include/linux/drm/drm_drv.h`](../../../../include/linux/drm/drm_drv.h)
> +
> +use crate::{
> + bindings, device, drm,
> + error::code::*,
> + error::from_kernel_err_ptr,
> + error::{Error, Result},
> + prelude::*,
> + private::Sealed,
> + str::CStr,
> + types::ForeignOwnable,
> + ThisModule,
> +};
> +use core::{
> + marker::{PhantomData, PhantomPinned},
> + pin::Pin,
> +};
> +use macros::vtable;
> +
> +/// Driver use the GEM memory manager. This should be set for all modern drivers.
> +pub const FEAT_GEM: u32 = bindings::drm_driver_feature_DRIVER_GEM;
> +/// Driver supports mode setting interfaces (KMS).
> +pub const FEAT_MODESET: u32 = bindings::drm_driver_feature_DRIVER_MODESET;
> +/// Driver supports dedicated render nodes.
> +pub const FEAT_RENDER: u32 = bindings::drm_driver_feature_DRIVER_RENDER;
> +/// Driver supports the full atomic modesetting userspace API.
> +///
> +/// Drivers which only use atomic internally, but do not support the full userspace API (e.g. not
> +/// all properties converted to atomic, or multi-plane updates are not guaranteed to be tear-free)
> +/// should not set this flag.
> +pub const FEAT_ATOMIC: u32 = bindings::drm_driver_feature_DRIVER_ATOMIC;
> +/// Driver supports DRM sync objects for explicit synchronization of command submission.
> +pub const FEAT_SYNCOBJ: u32 = bindings::drm_driver_feature_DRIVER_SYNCOBJ;
> +/// Driver supports the timeline flavor of DRM sync objects for explicit synchronization of command
> +/// submission.
> +pub const FEAT_SYNCOBJ_TIMELINE: u32 = bindings::drm_driver_feature_DRIVER_SYNCOBJ_TIMELINE;
> +
> +/// Information data for a DRM Driver.
> +pub struct DriverInfo {
> + /// Driver major version.
> + pub major: i32,
> + /// Driver minor version.
> + pub minor: i32,
> + /// Driver patchlevel version.
> + pub patchlevel: i32,
> + /// Driver name.
> + pub name: &'static CStr,
> + /// Driver description.
> + pub desc: &'static CStr,
> + /// Driver date.
> + pub date: &'static CStr,
> +}
> +
> +/// Internal memory management operation set, normally created by memory managers (e.g. GEM).
> +///
> +/// See `kernel::drm::gem` and `kernel::drm::gem::shmem`.
> +pub struct AllocOps {
> + pub(crate) gem_create_object: Option<
> + unsafe extern "C" fn(
> + dev: *mut bindings::drm_device,
> + size: usize,
> + ) -> *mut bindings::drm_gem_object,
> + >,
> + pub(crate) prime_handle_to_fd: Option<
> + unsafe extern "C" fn(
> + dev: *mut bindings::drm_device,
> + file_priv: *mut bindings::drm_file,
> + handle: u32,
> + flags: u32,
> + prime_fd: *mut core::ffi::c_int,
> + ) -> core::ffi::c_int,
> + >,
> + pub(crate) prime_fd_to_handle: Option<
> + unsafe extern "C" fn(
> + dev: *mut bindings::drm_device,
> + file_priv: *mut bindings::drm_file,
> + prime_fd: core::ffi::c_int,
> + handle: *mut u32,
> + ) -> core::ffi::c_int,
> + >,
> + pub(crate) gem_prime_import: Option<
> + unsafe extern "C" fn(
> + dev: *mut bindings::drm_device,
> + dma_buf: *mut bindings::dma_buf,
> + ) -> *mut bindings::drm_gem_object,
> + >,
> + pub(crate) gem_prime_import_sg_table: Option<
> + unsafe extern "C" fn(
> + dev: *mut bindings::drm_device,
> + attach: *mut bindings::dma_buf_attachment,
> + sgt: *mut bindings::sg_table,
> + ) -> *mut bindings::drm_gem_object,
> + >,
> + pub(crate) gem_prime_mmap: Option<
> + unsafe extern "C" fn(
> + obj: *mut bindings::drm_gem_object,
> + vma: *mut bindings::vm_area_struct,
> + ) -> core::ffi::c_int,
> + >,
> + pub(crate) dumb_create: Option<
> + unsafe extern "C" fn(
> + file_priv: *mut bindings::drm_file,
> + dev: *mut bindings::drm_device,
> + args: *mut bindings::drm_mode_create_dumb,
> + ) -> core::ffi::c_int,
> + >,
> + pub(crate) dumb_map_offset: Option<
> + unsafe extern "C" fn(
> + file_priv: *mut bindings::drm_file,
> + dev: *mut bindings::drm_device,
> + handle: u32,
> + offset: *mut u64,
> + ) -> core::ffi::c_int,
> + >,
> + pub(crate) dumb_destroy: Option<
> + unsafe extern "C" fn(
> + file_priv: *mut bindings::drm_file,
> + dev: *mut bindings::drm_device,
> + handle: u32,
> + ) -> core::ffi::c_int,
> + >,
> +}
> +
> +/// Trait for memory manager implementations. Implemented internally.
> +pub trait AllocImpl: Sealed {
> + /// The C callback operations for this memory manager.
> + const ALLOC_OPS: AllocOps;
> +}
> +
> +/// A DRM driver implementation.
> +#[vtable]
> +pub trait Driver {
> + /// Context data associated with the DRM driver
> + ///
> + /// Determines the type of the context data passed to each of the methods of the trait.
> + type Data: ForeignOwnable + Sync + Send;
> +
> + /// The type used to manage memory for this driver.
> + ///
> + /// Should be either `drm::gem::Object<T>` or `drm::gem::shmem::Object<T>`.
> + type Object: AllocImpl;
> +
> + /// Driver metadata
> + const INFO: DriverInfo;
> +
> + /// Feature flags
> + const FEATURES: u32;
> +
> + /// IOCTL list. See `kernel::drm::ioctl::declare_drm_ioctls!{}`.
> + const IOCTLS: &'static [drm::ioctl::DrmIoctlDescriptor];
> +}
> +
> +/// A registration of a DRM device
> +///
> +/// # Invariants:
> +///
> +/// drm is always a valid pointer to an allocated drm_device
> +pub struct Registration<T: Driver> {
> + drm: drm::device::Device<T>,
> + registered: bool,
> + fops: bindings::file_operations,
> + vtable: Pin<Box<bindings::drm_driver>>,
> + _p: PhantomData<T>,
> + _pin: PhantomPinned,
> +}
> +
> +#[cfg(CONFIG_DRM_LEGACY)]
> +macro_rules! drm_legacy_fields {
> + ( $($field:ident: $val:expr),* $(,)? ) => {
> + bindings::drm_driver {
> + $( $field: $val ),*,
> + firstopen: None,
> + preclose: None,
> + dma_ioctl: None,
> + dma_quiescent: None,
> + context_dtor: None,
> + irq_handler: None,
> + irq_preinstall: None,
> + irq_postinstall: None,
> + irq_uninstall: None,
> + get_vblank_counter: None,
> + enable_vblank: None,
> + disable_vblank: None,
> + dev_priv_size: 0,
> + }
> + }
> +}
> +
> +#[cfg(not(CONFIG_DRM_LEGACY))]
> +macro_rules! drm_legacy_fields {
> + ( $($field:ident: $val:expr),* $(,)? ) => {
> + bindings::drm_driver {
> + $( $field: $val ),*
> + }
> + }
> +}
> +
> +/// Registers a DRM device with the rest of the kernel.
> +///
> +/// It automatically picks up THIS_MODULE.
> +#[allow(clippy::crate_in_macro_def)]
> +#[macro_export]
> +macro_rules! drm_device_register {
> + ($reg:expr, $data:expr, $flags:expr $(,)?) => {{
> + $crate::drm::drv::Registration::register($reg, $data, $flags, &crate::THIS_MODULE)
> + }};
> +}
> +
> +impl<T: Driver> Registration<T> {
> + const VTABLE: bindings::drm_driver = drm_legacy_fields! {
> + load: None,
> + open: None, // TODO: File abstraction
> + postclose: None, // TODO: File abstraction
> + lastclose: None,
> + unload: None,
> + release: None,
> + master_set: None,
> + master_drop: None,
> + debugfs_init: None,
> + gem_create_object: T::Object::ALLOC_OPS.gem_create_object,
> + prime_handle_to_fd: T::Object::ALLOC_OPS.prime_handle_to_fd,
> + prime_fd_to_handle: T::Object::ALLOC_OPS.prime_fd_to_handle,
> + gem_prime_import: T::Object::ALLOC_OPS.gem_prime_import,
> + gem_prime_import_sg_table: T::Object::ALLOC_OPS.gem_prime_import_sg_table,
> + gem_prime_mmap: T::Object::ALLOC_OPS.gem_prime_mmap,
> + dumb_create: T::Object::ALLOC_OPS.dumb_create,
> + dumb_map_offset: T::Object::ALLOC_OPS.dumb_map_offset,
> + dumb_destroy: T::Object::ALLOC_OPS.dumb_destroy,
> +
> + major: T::INFO.major,
> + minor: T::INFO.minor,
> + patchlevel: T::INFO.patchlevel,
> + name: T::INFO.name.as_char_ptr() as *mut _,
> + desc: T::INFO.desc.as_char_ptr() as *mut _,
> + date: T::INFO.date.as_char_ptr() as *mut _,
> +
> + driver_features: T::FEATURES,
> + ioctls: T::IOCTLS.as_ptr(),
> + num_ioctls: T::IOCTLS.len() as i32,
> + fops: core::ptr::null_mut(),
> + };
> +
> + /// Creates a new [`Registration`] but does not register it yet.
> + ///
> + /// It is allowed to move.
> + pub fn new(parent: &dyn device::RawDevice) -> Result<Self> {
> + let vtable = Pin::new(Box::try_new(Self::VTABLE)?);
> + let raw_drm = unsafe { bindings::drm_dev_alloc(&*vtable, parent.raw_device()) };
> + let raw_drm = from_kernel_err_ptr(raw_drm)?;
> +
> + // The reference count is one, and now we take ownership of that reference as a
> + // drm::device::Device.
> + let drm = unsafe { drm::device::Device::from_raw(raw_drm) };
> +
> + Ok(Self {
> + drm,
> + registered: false,
> + vtable,
> + fops: Default::default(), // TODO: GEM abstraction
> + _pin: PhantomPinned,
> + _p: PhantomData,
> + })
> + }
> +
> + /// Registers a DRM device with the rest of the kernel.
> + ///
> + /// Users are encouraged to use the [`drm_device_register!()`] macro because it automatically
> + /// picks up the current module.
> + pub fn register(
> + self: Pin<&mut Self>,
> + data: T::Data,
> + flags: usize,
> + module: &'static ThisModule,
> + ) -> Result {
> + if self.registered {
> + // Already registered.
> + return Err(EINVAL);
> + }
> +
> + // SAFETY: We never move out of `this`.
> + let this = unsafe { self.get_unchecked_mut() };
> + let data_pointer = <T::Data as ForeignOwnable>::into_foreign(data);
> + // SAFETY: `drm` is valid per the type invariant
> + unsafe {
> + (*this.drm.raw_mut()).dev_private = data_pointer as *mut _;
> + }
> +
> + this.fops.owner = module.0;
> + this.vtable.fops = &this.fops;
> +
> + // SAFETY: The device is now initialized and ready to be registered.
> + let ret = unsafe { bindings::drm_dev_register(this.drm.raw_mut(), flags as u64) };
> + if ret < 0 {
> + // SAFETY: `data_pointer` was returned by `into_foreign` above.
> + unsafe { T::Data::from_foreign(data_pointer) };
> + return Err(Error::from_kernel_errno(ret));
> + }
> +
> + this.registered = true;
> + Ok(())
> + }
> +
> + /// Returns a reference to the `Device` instance for this registration.
> + pub fn device(&self) -> &drm::device::Device<T> {
> + &self.drm
> + }
> +}
> +
> +// SAFETY: `Registration` doesn't offer any methods or access to fields when shared between threads
> +// or CPUs, so it is safe to share it.
> +unsafe impl<T: Driver> Sync for Registration<T> {}
> +
> +// SAFETY: Registration with and unregistration from the drm subsystem can happen from any thread.
> +// Additionally, `T::Data` (which is dropped during unregistration) is `Send`, so it is ok to move
> +// `Registration` to different threads.
> +#[allow(clippy::non_send_fields_in_send_ty)]
> +unsafe impl<T: Driver> Send for Registration<T> {}
> +
> +impl<T: Driver> Drop for Registration<T> {
> + /// Removes the registration from the kernel if it has completed successfully before.
> + fn drop(&mut self) {
> + if self.registered {
> + // Get a pointer to the data stored in device before destroying it.
> + // SAFETY: `drm` is valid per the type invariant
> + let data_pointer = unsafe { (*self.drm.raw_mut()).dev_private };
> +
> + // SAFETY: Since `registered` is true, `self.drm` is both valid and registered.
> + unsafe { bindings::drm_dev_unregister(self.drm.raw_mut()) };
> +
> + // Free data as well.
> + // SAFETY: `data_pointer` was returned by `into_foreign` during registration.
> + unsafe { <T::Data as ForeignOwnable>::from_foreign(data_pointer) };
> + }
> + }
> +}
> diff --git a/rust/kernel/drm/mod.rs b/rust/kernel/drm/mod.rs
> index 9ec6d7cbcaf3..69376b3c6db9 100644
> --- a/rust/kernel/drm/mod.rs
> +++ b/rust/kernel/drm/mod.rs
> @@ -2,4 +2,6 @@
>
> //! DRM subsystem abstractions.
>
> +pub mod device;
> +pub mod drv;
> pub mod ioctl;
>
> --
> 2.35.1
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
^ permalink raw reply [flat|nested] 122+ messages in thread
* [PATCH RFC 03/18] rust: drm: file: Add File abstraction
2023-03-07 14:25 [PATCH RFC 00/18] Rust DRM subsystem abstractions (& preview AGX driver) Asahi Lina
2023-03-07 14:25 ` [PATCH RFC 01/18] rust: drm: ioctl: Add DRM ioctl abstraction Asahi Lina
2023-03-07 14:25 ` [PATCH RFC 02/18] rust: drm: Add Device and Driver abstractions Asahi Lina
@ 2023-03-07 14:25 ` Asahi Lina
2023-03-09 21:16 ` Faith Ekstrand
2023-03-07 14:25 ` [PATCH RFC 04/18] rust: drm: gem: Add GEM object abstraction Asahi Lina
` (15 subsequent siblings)
18 siblings, 1 reply; 122+ messages in thread
From: Asahi Lina @ 2023-03-07 14:25 UTC (permalink / raw)
To: Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
David Airlie, Daniel Vetter, Miguel Ojeda, Alex Gaynor,
Wedson Almeida Filho, Boqun Feng, Gary Guo, Björn Roy Baron,
Sumit Semwal, Christian König, Luben Tuikov,
Jarkko Sakkinen, Dave Hansen
Cc: Alyssa Rosenzweig, Karol Herbst, Ella Stanforth, Faith Ekstrand,
Mary, linux-kernel, dri-devel, rust-for-linux, linux-media,
linaro-mm-sig, linux-sgx, asahi, Asahi Lina
A DRM File is the DRM counterpart to a kernel file structure,
representing an open DRM file descriptor. Add a Rust abstraction to
allow drivers to implement their own File types that implement the
DriverFile trait.
Signed-off-by: Asahi Lina <lina@asahilina.net>
---
rust/bindings/bindings_helper.h | 1 +
rust/kernel/drm/drv.rs | 7 ++-
rust/kernel/drm/file.rs | 113 ++++++++++++++++++++++++++++++++++++++++
rust/kernel/drm/mod.rs | 1 +
4 files changed, 120 insertions(+), 2 deletions(-)
diff --git a/rust/bindings/bindings_helper.h b/rust/bindings/bindings_helper.h
index 2a999138c4ae..7d7828faf89c 100644
--- a/rust/bindings/bindings_helper.h
+++ b/rust/bindings/bindings_helper.h
@@ -8,6 +8,7 @@
#include <drm/drm_device.h>
#include <drm/drm_drv.h>
+#include <drm/drm_file.h>
#include <drm/drm_ioctl.h>
#include <linux/delay.h>
#include <linux/device.h>
diff --git a/rust/kernel/drm/drv.rs b/rust/kernel/drm/drv.rs
index 29a465515dc9..1dcb651e1417 100644
--- a/rust/kernel/drm/drv.rs
+++ b/rust/kernel/drm/drv.rs
@@ -144,6 +144,9 @@ pub trait Driver {
/// Should be either `drm::gem::Object<T>` or `drm::gem::shmem::Object<T>`.
type Object: AllocImpl;
+ /// The type used to represent a DRM File (client)
+ type File: drm::file::DriverFile;
+
/// Driver metadata
const INFO: DriverInfo;
@@ -213,8 +216,8 @@ macro_rules! drm_device_register {
impl<T: Driver> Registration<T> {
const VTABLE: bindings::drm_driver = drm_legacy_fields! {
load: None,
- open: None, // TODO: File abstraction
- postclose: None, // TODO: File abstraction
+ open: Some(drm::file::open_callback::<T::File>),
+ postclose: Some(drm::file::postclose_callback::<T::File>),
lastclose: None,
unload: None,
release: None,
diff --git a/rust/kernel/drm/file.rs b/rust/kernel/drm/file.rs
new file mode 100644
index 000000000000..48751e93c38a
--- /dev/null
+++ b/rust/kernel/drm/file.rs
@@ -0,0 +1,113 @@
+// SPDX-License-Identifier: GPL-2.0 OR MIT
+
+//! DRM File objects.
+//!
+//! C header: [`include/linux/drm/drm_file.h`](../../../../include/linux/drm/drm_file.h)
+
+use crate::{bindings, drm, error::Result};
+use alloc::boxed::Box;
+use core::marker::PhantomData;
+use core::ops::Deref;
+
+/// Trait that must be implemented by DRM drivers to represent a DRM File (a client instance).
+pub trait DriverFile {
+ /// The parent `Driver` implementation for this `DriverFile`.
+ type Driver: drm::drv::Driver;
+
+ /// Open a new file (called when a client opens the DRM device).
+ fn open(device: &drm::device::Device<Self::Driver>) -> Result<Box<Self>>;
+}
+
+/// An open DRM File.
+///
+/// # Invariants
+/// `raw` is a valid pointer to a `drm_file` struct.
+#[repr(transparent)]
+pub struct File<T: DriverFile> {
+ raw: *mut bindings::drm_file,
+ _p: PhantomData<T>,
+}
+
+pub(super) unsafe extern "C" fn open_callback<T: DriverFile>(
+ raw_dev: *mut bindings::drm_device,
+ raw_file: *mut bindings::drm_file,
+) -> core::ffi::c_int {
+ let drm = core::mem::ManuallyDrop::new(unsafe { drm::device::Device::from_raw(raw_dev) });
+ // SAFETY: This reference won't escape this function
+ let file = unsafe { &mut *raw_file };
+
+ let inner = match T::open(&drm) {
+ Err(e) => {
+ return e.to_kernel_errno();
+ }
+ Ok(i) => i,
+ };
+
+ file.driver_priv = Box::into_raw(inner) as *mut _;
+
+ 0
+}
+
+pub(super) unsafe extern "C" fn postclose_callback<T: DriverFile>(
+ _dev: *mut bindings::drm_device,
+ raw_file: *mut bindings::drm_file,
+) {
+ // SAFETY: This reference won't escape this function
+ let file = unsafe { &*raw_file };
+
+ // Drop the DriverFile
+ unsafe { Box::from_raw(file.driver_priv as *mut T) };
+}
+
+impl<T: DriverFile> File<T> {
+ // Not intended to be called externally, except via declare_drm_ioctls!()
+ #[doc(hidden)]
+ pub unsafe fn from_raw(raw_file: *mut bindings::drm_file) -> File<T> {
+ File {
+ raw: raw_file,
+ _p: PhantomData,
+ }
+ }
+
+ #[allow(dead_code)]
+ /// Return the raw pointer to the underlying `drm_file`.
+ pub(super) fn raw(&self) -> *const bindings::drm_file {
+ self.raw
+ }
+
+ /// Return an immutable reference to the raw `drm_file` structure.
+ pub(super) fn file(&self) -> &bindings::drm_file {
+ unsafe { &*self.raw }
+ }
+}
+
+impl<T: DriverFile> Deref for File<T> {
+ type Target = T;
+
+ fn deref(&self) -> &T {
+ unsafe { &*(self.file().driver_priv as *const T) }
+ }
+}
+
+impl<T: DriverFile> crate::private::Sealed for File<T> {}
+
+/// Generic trait to allow users that don't care about driver specifics to accept any File<T>.
+///
+/// # Safety
+/// Must only be implemented for File<T> and return the pointer, following the normal invariants
+/// of that type.
+pub unsafe trait GenericFile: crate::private::Sealed {
+ /// Returns the raw const pointer to the `struct drm_file`
+ fn raw(&self) -> *const bindings::drm_file;
+ /// Returns the raw mut pointer to the `struct drm_file`
+ fn raw_mut(&mut self) -> *mut bindings::drm_file;
+}
+
+unsafe impl<T: DriverFile> GenericFile for File<T> {
+ fn raw(&self) -> *const bindings::drm_file {
+ self.raw
+ }
+ fn raw_mut(&mut self) -> *mut bindings::drm_file {
+ self.raw
+ }
+}
diff --git a/rust/kernel/drm/mod.rs b/rust/kernel/drm/mod.rs
index 69376b3c6db9..a767942d0b52 100644
--- a/rust/kernel/drm/mod.rs
+++ b/rust/kernel/drm/mod.rs
@@ -4,4 +4,5 @@
pub mod device;
pub mod drv;
+pub mod file;
pub mod ioctl;
--
2.35.1
^ permalink raw reply related [flat|nested] 122+ messages in thread* Re: [PATCH RFC 03/18] rust: drm: file: Add File abstraction
2023-03-07 14:25 ` [PATCH RFC 03/18] rust: drm: file: Add File abstraction Asahi Lina
@ 2023-03-09 21:16 ` Faith Ekstrand
2023-03-09 22:16 ` Asahi Lina
0 siblings, 1 reply; 122+ messages in thread
From: Faith Ekstrand @ 2023-03-09 21:16 UTC (permalink / raw)
To: Asahi Lina, Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
David Airlie, Daniel Vetter, Miguel Ojeda, Alex Gaynor,
Wedson Almeida Filho, Boqun Feng, Gary Guo, Björn Roy Baron,
Sumit Semwal, Christian König, Luben Tuikov,
Jarkko Sakkinen, Dave Hansen
Cc: Alyssa Rosenzweig, Karol Herbst, Ella Stanforth, Mary,
linux-kernel, dri-devel, rust-for-linux, linux-media,
linaro-mm-sig, linux-sgx, asahi
On Tue, 2023-03-07 at 23:25 +0900, Asahi Lina wrote:
> A DRM File is the DRM counterpart to a kernel file structure,
> representing an open DRM file descriptor. Add a Rust abstraction to
> allow drivers to implement their own File types that implement the
> DriverFile trait.
>
> Signed-off-by: Asahi Lina <lina@asahilina.net>
> ---
> rust/bindings/bindings_helper.h | 1 +
> rust/kernel/drm/drv.rs | 7 ++-
> rust/kernel/drm/file.rs | 113
> ++++++++++++++++++++++++++++++++++++++++
> rust/kernel/drm/mod.rs | 1 +
> 4 files changed, 120 insertions(+), 2 deletions(-)
>
> diff --git a/rust/bindings/bindings_helper.h
> b/rust/bindings/bindings_helper.h
> index 2a999138c4ae..7d7828faf89c 100644
> --- a/rust/bindings/bindings_helper.h
> +++ b/rust/bindings/bindings_helper.h
> @@ -8,6 +8,7 @@
>
> #include <drm/drm_device.h>
> #include <drm/drm_drv.h>
> +#include <drm/drm_file.h>
> #include <drm/drm_ioctl.h>
> #include <linux/delay.h>
> #include <linux/device.h>
> diff --git a/rust/kernel/drm/drv.rs b/rust/kernel/drm/drv.rs
> index 29a465515dc9..1dcb651e1417 100644
> --- a/rust/kernel/drm/drv.rs
> +++ b/rust/kernel/drm/drv.rs
> @@ -144,6 +144,9 @@ pub trait Driver {
> /// Should be either `drm::gem::Object<T>` or
> `drm::gem::shmem::Object<T>`.
> type Object: AllocImpl;
>
> + /// The type used to represent a DRM File (client)
> + type File: drm::file::DriverFile;
> +
> /// Driver metadata
> const INFO: DriverInfo;
>
> @@ -213,8 +216,8 @@ macro_rules! drm_device_register {
> impl<T: Driver> Registration<T> {
> const VTABLE: bindings::drm_driver = drm_legacy_fields! {
> load: None,
> - open: None, // TODO: File abstraction
> - postclose: None, // TODO: File abstraction
> + open: Some(drm::file::open_callback::<T::File>),
> + postclose: Some(drm::file::postclose_callback::<T::File>),
> lastclose: None,
> unload: None,
> release: None,
> diff --git a/rust/kernel/drm/file.rs b/rust/kernel/drm/file.rs
> new file mode 100644
> index 000000000000..48751e93c38a
> --- /dev/null
> +++ b/rust/kernel/drm/file.rs
> @@ -0,0 +1,113 @@
> +// SPDX-License-Identifier: GPL-2.0 OR MIT
> +
> +//! DRM File objects.
> +//!
> +//! C header:
> [`include/linux/drm/drm_file.h`](../../../../include/linux/drm/drm_fi
> le.h)
> +
> +use crate::{bindings, drm, error::Result};
> +use alloc::boxed::Box;
> +use core::marker::PhantomData;
> +use core::ops::Deref;
> +
> +/// Trait that must be implemented by DRM drivers to represent a DRM
> File (a client instance).
> +pub trait DriverFile {
> + /// The parent `Driver` implementation for this `DriverFile`.
> + type Driver: drm::drv::Driver;
> +
> + /// Open a new file (called when a client opens the DRM device).
> + fn open(device: &drm::device::Device<Self::Driver>) ->
> Result<Box<Self>>;
> +}
> +
> +/// An open DRM File.
> +///
> +/// # Invariants
> +/// `raw` is a valid pointer to a `drm_file` struct.
> +#[repr(transparent)]
> +pub struct File<T: DriverFile> {
> + raw: *mut bindings::drm_file,
> + _p: PhantomData<T>,
> +}
> +
> +pub(super) unsafe extern "C" fn open_callback<T: DriverFile>(
> + raw_dev: *mut bindings::drm_device,
> + raw_file: *mut bindings::drm_file,
> +) -> core::ffi::c_int {
> + let drm = core::mem::ManuallyDrop::new(unsafe {
> drm::device::Device::from_raw(raw_dev) });
Maybe you can help educate me a bit here... This feels like a really
sketchy pattern. We're creating a Device from a pointer, an operation
which inherently consumes a reference but then marking it ManuallyDrop
so drm_device_put() never gets called. It took me a while but I think
I figured out what you're trying to do: Make it so all the Rust stuff
works with Device, not drm_device but it still feels really wrong. It
works, it just feels like there's a lot of unsafe abstraction juggling
happening here and I expect this operation is going to be pretty common
in the Rust abstraction layer.
Am I missing something?
~Faith
> + // SAFETY: This reference won't escape this function
> + let file = unsafe { &mut *raw_file };
> +
> + let inner = match T::open(&drm) {
> + Err(e) => {
> + return e.to_kernel_errno();
> + }
> + Ok(i) => i,
> + };
> +
> + file.driver_priv = Box::into_raw(inner) as *mut _;
> +
> + 0
> +}
> +
> +pub(super) unsafe extern "C" fn postclose_callback<T: DriverFile>(
> + _dev: *mut bindings::drm_device,
> + raw_file: *mut bindings::drm_file,
> +) {
> + // SAFETY: This reference won't escape this function
> + let file = unsafe { &*raw_file };
> +
> + // Drop the DriverFile
> + unsafe { Box::from_raw(file.driver_priv as *mut T) };
> +}
> +
> +impl<T: DriverFile> File<T> {
> + // Not intended to be called externally, except via
> declare_drm_ioctls!()
> + #[doc(hidden)]
> + pub unsafe fn from_raw(raw_file: *mut bindings::drm_file) ->
> File<T> {
> + File {
> + raw: raw_file,
> + _p: PhantomData,
> + }
> + }
> +
> + #[allow(dead_code)]
> + /// Return the raw pointer to the underlying `drm_file`.
> + pub(super) fn raw(&self) -> *const bindings::drm_file {
> + self.raw
> + }
> +
> + /// Return an immutable reference to the raw `drm_file`
> structure.
> + pub(super) fn file(&self) -> &bindings::drm_file {
> + unsafe { &*self.raw }
> + }
> +}
> +
> +impl<T: DriverFile> Deref for File<T> {
> + type Target = T;
> +
> + fn deref(&self) -> &T {
> + unsafe { &*(self.file().driver_priv as *const T) }
> + }
> +}
> +
> +impl<T: DriverFile> crate::private::Sealed for File<T> {}
> +
> +/// Generic trait to allow users that don't care about driver
> specifics to accept any File<T>.
> +///
> +/// # Safety
> +/// Must only be implemented for File<T> and return the pointer,
> following the normal invariants
> +/// of that type.
> +pub unsafe trait GenericFile: crate::private::Sealed {
> + /// Returns the raw const pointer to the `struct drm_file`
> + fn raw(&self) -> *const bindings::drm_file;
> + /// Returns the raw mut pointer to the `struct drm_file`
> + fn raw_mut(&mut self) -> *mut bindings::drm_file;
> +}
> +
> +unsafe impl<T: DriverFile> GenericFile for File<T> {
> + fn raw(&self) -> *const bindings::drm_file {
> + self.raw
> + }
> + fn raw_mut(&mut self) -> *mut bindings::drm_file {
> + self.raw
> + }
> +}
> diff --git a/rust/kernel/drm/mod.rs b/rust/kernel/drm/mod.rs
> index 69376b3c6db9..a767942d0b52 100644
> --- a/rust/kernel/drm/mod.rs
> +++ b/rust/kernel/drm/mod.rs
> @@ -4,4 +4,5 @@
>
> pub mod device;
> pub mod drv;
> +pub mod file;
> pub mod ioctl;
>
^ permalink raw reply [flat|nested] 122+ messages in thread* Re: [PATCH RFC 03/18] rust: drm: file: Add File abstraction
2023-03-09 21:16 ` Faith Ekstrand
@ 2023-03-09 22:16 ` Asahi Lina
2023-03-13 17:49 ` Faith Ekstrand
0 siblings, 1 reply; 122+ messages in thread
From: Asahi Lina @ 2023-03-09 22:16 UTC (permalink / raw)
To: Faith Ekstrand, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Daniel Vetter, Miguel Ojeda,
Alex Gaynor, Wedson Almeida Filho, Boqun Feng, Gary Guo,
Björn Roy Baron, Sumit Semwal, Christian König,
Luben Tuikov, Jarkko Sakkinen, Dave Hansen
Cc: Alyssa Rosenzweig, Karol Herbst, Ella Stanforth, Mary,
linux-kernel, dri-devel, rust-for-linux, linux-media,
linaro-mm-sig, linux-sgx, asahi
On 10/03/2023 06.16, Faith Ekstrand wrote:
> On Tue, 2023-03-07 at 23:25 +0900, Asahi Lina wrote:
>> A DRM File is the DRM counterpart to a kernel file structure,
>> representing an open DRM file descriptor. Add a Rust abstraction to
>> allow drivers to implement their own File types that implement the
>> DriverFile trait.
>>
>> Signed-off-by: Asahi Lina <lina@asahilina.net>
>> ---
>> rust/bindings/bindings_helper.h | 1 +
>> rust/kernel/drm/drv.rs | 7 ++-
>> rust/kernel/drm/file.rs | 113
>> ++++++++++++++++++++++++++++++++++++++++
>> rust/kernel/drm/mod.rs | 1 +
>> 4 files changed, 120 insertions(+), 2 deletions(-)
>>
>> diff --git a/rust/bindings/bindings_helper.h
>> b/rust/bindings/bindings_helper.h
>> index 2a999138c4ae..7d7828faf89c 100644
>> --- a/rust/bindings/bindings_helper.h
>> +++ b/rust/bindings/bindings_helper.h
>> @@ -8,6 +8,7 @@
>>
>> #include <drm/drm_device.h>
>> #include <drm/drm_drv.h>
>> +#include <drm/drm_file.h>
>> #include <drm/drm_ioctl.h>
>> #include <linux/delay.h>
>> #include <linux/device.h>
>> diff --git a/rust/kernel/drm/drv.rs b/rust/kernel/drm/drv.rs
>> index 29a465515dc9..1dcb651e1417 100644
>> --- a/rust/kernel/drm/drv.rs
>> +++ b/rust/kernel/drm/drv.rs
>> @@ -144,6 +144,9 @@ pub trait Driver {
>> /// Should be either `drm::gem::Object<T>` or
>> `drm::gem::shmem::Object<T>`.
>> type Object: AllocImpl;
>>
>> + /// The type used to represent a DRM File (client)
>> + type File: drm::file::DriverFile;
>> +
>> /// Driver metadata
>> const INFO: DriverInfo;
>>
>> @@ -213,8 +216,8 @@ macro_rules! drm_device_register {
>> impl<T: Driver> Registration<T> {
>> const VTABLE: bindings::drm_driver = drm_legacy_fields! {
>> load: None,
>> - open: None, // TODO: File abstraction
>> - postclose: None, // TODO: File abstraction
>> + open: Some(drm::file::open_callback::<T::File>),
>> + postclose: Some(drm::file::postclose_callback::<T::File>),
>> lastclose: None,
>> unload: None,
>> release: None,
>> diff --git a/rust/kernel/drm/file.rs b/rust/kernel/drm/file.rs
>> new file mode 100644
>> index 000000000000..48751e93c38a
>> --- /dev/null
>> +++ b/rust/kernel/drm/file.rs
>> @@ -0,0 +1,113 @@
>> +// SPDX-License-Identifier: GPL-2.0 OR MIT
>> +
>> +//! DRM File objects.
>> +//!
>> +//! C header:
>> [`include/linux/drm/drm_file.h`](../../../../include/linux/drm/drm_fi
>> le.h)
>> +
>> +use crate::{bindings, drm, error::Result};
>> +use alloc::boxed::Box;
>> +use core::marker::PhantomData;
>> +use core::ops::Deref;
>> +
>> +/// Trait that must be implemented by DRM drivers to represent a DRM
>> File (a client instance).
>> +pub trait DriverFile {
>> + /// The parent `Driver` implementation for this `DriverFile`.
>> + type Driver: drm::drv::Driver;
>> +
>> + /// Open a new file (called when a client opens the DRM device).
>> + fn open(device: &drm::device::Device<Self::Driver>) ->
>> Result<Box<Self>>;
>> +}
>> +
>> +/// An open DRM File.
>> +///
>> +/// # Invariants
>> +/// `raw` is a valid pointer to a `drm_file` struct.
>> +#[repr(transparent)]
>> +pub struct File<T: DriverFile> {
>> + raw: *mut bindings::drm_file,
>> + _p: PhantomData<T>,
>> +}
>> +
>> +pub(super) unsafe extern "C" fn open_callback<T: DriverFile>(
>> + raw_dev: *mut bindings::drm_device,
>> + raw_file: *mut bindings::drm_file,
>> +) -> core::ffi::c_int {
>> + let drm = core::mem::ManuallyDrop::new(unsafe {
>> drm::device::Device::from_raw(raw_dev) });
>
> Maybe you can help educate me a bit here... This feels like a really
> sketchy pattern. We're creating a Device from a pointer, an operation
> which inherently consumes a reference but then marking it ManuallyDrop
> so drm_device_put() never gets called. It took me a while but I think
> I figured out what you're trying to do: Make it so all the Rust stuff
> works with Device, not drm_device but it still feels really wrong. It
> works, it just feels like there's a lot of unsafe abstraction juggling
> happening here and I expect this operation is going to be pretty common
> in the Rust abstraction layer.
So I think this is going to be a pretty common pattern in this kind of
abstraction. The problem is that, of course, in C there is no
distinction between an owned reference and a borrowed one. Here we have
a borrowed reference to a struct drm_device, and we need to turn it into
a &Device (which is the Rust equivalent type). But for &Device to exist
we need a Device to exist in the first place, and Device normally
implies ownership of the underlying drm_device.
We could just acquire a reference here, but then we're needlessly
grabbing a ref only to drop it at the end of the function, which is
pointless when the caller is holding another reference for us while the
callback runs. And of course Rust likes to claim to offer zero-cost
abstractions, so it would be kind of sad to have to do that... ^^
Just doing drm::device::Device::from_raw(raw_dev) is a ticking time
bomb, because we haven't acquired a reference (which would normally be
required). If that Device ever gets dropped, we've messed up the
refcounting and stolen the caller's reference. We could try to ensure it
gets passed to core::mem::forget in all paths out, but that gets
error-prone very quickly when trying to cover error paths. So instead,
we put it into a ManuallyDrop. That takes care of neutering the ref
drop, so we don't have to worry about messing that up. Then the only
remaining safety requirement is that that the ManuallyDrop<Device> never
escape the callback function, and that's easy to ensure: we only pass a
&ref to the user (which via auto-deref ends up being a &Device), and
then nothing bad can happen. If the user wants an owned reference to the
device to keep around, they can call .clone() on it and that's when the
incref happens.
Basically, ManuallyDrop<T> where T is a reference counted type
represents a borrowed reference to a T coming from the C side. You can
see another use of this pattern in gem::Object, which contains a
ManuallyDrop<Device> that represents a borrowed reference to the device
that owns that object. The DRM core (as far as I know!) guarantees that
DRM devices outlive all of their GEM objects, so we can materialize a
borrowed reference and as long as it never leaves the GEM object, it
will be sound. Then we can take &Device references from it whenever we
want, and the usual Rust borrow checker rules ensure we can't do
something illegal.
~~ Lina
^ permalink raw reply [flat|nested] 122+ messages in thread* Re: [PATCH RFC 03/18] rust: drm: file: Add File abstraction
2023-03-09 22:16 ` Asahi Lina
@ 2023-03-13 17:49 ` Faith Ekstrand
2023-03-14 2:07 ` Boqun Feng
0 siblings, 1 reply; 122+ messages in thread
From: Faith Ekstrand @ 2023-03-13 17:49 UTC (permalink / raw)
To: Asahi Lina, Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
David Airlie, Daniel Vetter, Miguel Ojeda, Alex Gaynor,
Wedson Almeida Filho, Boqun Feng, Gary Guo, Björn Roy Baron,
Sumit Semwal, Christian König, Luben Tuikov,
Jarkko Sakkinen, Dave Hansen
Cc: Alyssa Rosenzweig, Karol Herbst, Ella Stanforth, Mary,
linux-kernel, dri-devel, rust-for-linux, linux-media,
linaro-mm-sig, linux-sgx, asahi
On Fri, 2023-03-10 at 07:16 +0900, Asahi Lina wrote:
> On 10/03/2023 06.16, Faith Ekstrand wrote:
> > On Tue, 2023-03-07 at 23:25 +0900, Asahi Lina wrote:
> > > A DRM File is the DRM counterpart to a kernel file structure,
> > > representing an open DRM file descriptor. Add a Rust abstraction
> > > to
> > > allow drivers to implement their own File types that implement
> > > the
> > > DriverFile trait.
> > >
> > > Signed-off-by: Asahi Lina <lina@asahilina.net>
> > > ---
> > > rust/bindings/bindings_helper.h | 1 +
> > > rust/kernel/drm/drv.rs | 7 ++-
> > > rust/kernel/drm/file.rs | 113
> > > ++++++++++++++++++++++++++++++++++++++++
> > > rust/kernel/drm/mod.rs | 1 +
> > > 4 files changed, 120 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/rust/bindings/bindings_helper.h
> > > b/rust/bindings/bindings_helper.h
> > > index 2a999138c4ae..7d7828faf89c 100644
> > > --- a/rust/bindings/bindings_helper.h
> > > +++ b/rust/bindings/bindings_helper.h
> > > @@ -8,6 +8,7 @@
> > >
> > > #include <drm/drm_device.h>
> > > #include <drm/drm_drv.h>
> > > +#include <drm/drm_file.h>
> > > #include <drm/drm_ioctl.h>
> > > #include <linux/delay.h>
> > > #include <linux/device.h>
> > > diff --git a/rust/kernel/drm/drv.rs b/rust/kernel/drm/drv.rs
> > > index 29a465515dc9..1dcb651e1417 100644
> > > --- a/rust/kernel/drm/drv.rs
> > > +++ b/rust/kernel/drm/drv.rs
> > > @@ -144,6 +144,9 @@ pub trait Driver {
> > > /// Should be either `drm::gem::Object<T>` or
> > > `drm::gem::shmem::Object<T>`.
> > > type Object: AllocImpl;
> > >
> > > + /// The type used to represent a DRM File (client)
> > > + type File: drm::file::DriverFile;
> > > +
> > > /// Driver metadata
> > > const INFO: DriverInfo;
> > >
> > > @@ -213,8 +216,8 @@ macro_rules! drm_device_register {
> > > impl<T: Driver> Registration<T> {
> > > const VTABLE: bindings::drm_driver = drm_legacy_fields! {
> > > load: None,
> > > - open: None, // TODO: File abstraction
> > > - postclose: None, // TODO: File abstraction
> > > + open: Some(drm::file::open_callback::<T::File>),
> > > + postclose:
> > > Some(drm::file::postclose_callback::<T::File>),
> > > lastclose: None,
> > > unload: None,
> > > release: None,
> > > diff --git a/rust/kernel/drm/file.rs b/rust/kernel/drm/file.rs
> > > new file mode 100644
> > > index 000000000000..48751e93c38a
> > > --- /dev/null
> > > +++ b/rust/kernel/drm/file.rs
> > > @@ -0,0 +1,113 @@
> > > +// SPDX-License-Identifier: GPL-2.0 OR MIT
> > > +
> > > +//! DRM File objects.
> > > +//!
> > > +//! C header:
> > > [`include/linux/drm/drm_file.h`](../../../../include/linux/drm/dr
> > > m_fi
> > > le.h)
> > > +
> > > +use crate::{bindings, drm, error::Result};
> > > +use alloc::boxed::Box;
> > > +use core::marker::PhantomData;
> > > +use core::ops::Deref;
> > > +
> > > +/// Trait that must be implemented by DRM drivers to represent a
> > > DRM
> > > File (a client instance).
> > > +pub trait DriverFile {
> > > + /// The parent `Driver` implementation for this
> > > `DriverFile`.
> > > + type Driver: drm::drv::Driver;
> > > +
> > > + /// Open a new file (called when a client opens the DRM
> > > device).
> > > + fn open(device: &drm::device::Device<Self::Driver>) ->
> > > Result<Box<Self>>;
> > > +}
> > > +
> > > +/// An open DRM File.
> > > +///
> > > +/// # Invariants
> > > +/// `raw` is a valid pointer to a `drm_file` struct.
> > > +#[repr(transparent)]
> > > +pub struct File<T: DriverFile> {
> > > + raw: *mut bindings::drm_file,
> > > + _p: PhantomData<T>,
> > > +}
> > > +
> > > +pub(super) unsafe extern "C" fn open_callback<T: DriverFile>(
> > > + raw_dev: *mut bindings::drm_device,
> > > + raw_file: *mut bindings::drm_file,
> > > +) -> core::ffi::c_int {
> > > + let drm = core::mem::ManuallyDrop::new(unsafe {
> > > drm::device::Device::from_raw(raw_dev) });
> >
> > Maybe you can help educate me a bit here... This feels like a
> > really
> > sketchy pattern. We're creating a Device from a pointer, an
> > operation
> > which inherently consumes a reference but then marking it
> > ManuallyDrop
> > so drm_device_put() never gets called. It took me a while but I
> > think
> > I figured out what you're trying to do: Make it so all the Rust
> > stuff
> > works with Device, not drm_device but it still feels really wrong.
> > It
> > works, it just feels like there's a lot of unsafe abstraction
> > juggling
> > happening here and I expect this operation is going to be pretty
> > common
> > in the Rust abstraction layer.
>
> So I think this is going to be a pretty common pattern in this kind
> of
> abstraction. The problem is that, of course, in C there is no
> distinction between an owned reference and a borrowed one. Here we
> have
> a borrowed reference to a struct drm_device, and we need to turn it
> into
> a &Device (which is the Rust equivalent type). But for &Device to
> exist
> we need a Device to exist in the first place, and Device normally
> implies ownership of the underlying drm_device.
Thanks! Putting it in terms of borrow really helps clear up the
difference.
> We could just acquire a reference here, but then we're needlessly
> grabbing a ref only to drop it at the end of the function, which is
> pointless when the caller is holding another reference for us while
> the
> callback runs. And of course Rust likes to claim to offer zero-cost
> abstractions, so it would be kind of sad to have to do that... ^^
Yeah, I agree we don't want to take extra references.
> Just doing drm::device::Device::from_raw(raw_dev) is a ticking time
> bomb, because we haven't acquired a reference (which would normally
> be
> required). If that Device ever gets dropped, we've messed up the
> refcounting and stolen the caller's reference. We could try to ensure
> it
> gets passed to core::mem::forget in all paths out, but that gets
> error-prone very quickly when trying to cover error paths. So
> instead,
> we put it into a ManuallyDrop. That takes care of neutering the ref
> drop, so we don't have to worry about messing that up. Then the only
> remaining safety requirement is that that the ManuallyDrop<Device>
> never
> escape the callback function, and that's easy to ensure: we only pass
> a
> &ref to the user (which via auto-deref ends up being a &Device), and
> then nothing bad can happen. If the user wants an owned reference to
> the
> device to keep around, they can call .clone() on it and that's when
> the
> incref happens.
>
> Basically, ManuallyDrop<T> where T is a reference counted type
> represents a borrowed reference to a T coming from the C side. You
> can
> see another use of this pattern in gem::Object, which contains a
> ManuallyDrop<Device> that represents a borrowed reference to the
> device
> that owns that object. The DRM core (as far as I know!) guarantees
> that
> DRM devices outlive all of their GEM objects, so we can materialize a
> borrowed reference and as long as it never leaves the GEM object, it
> will be sound. Then we can take &Device references from it whenever
> we
> want, and the usual Rust borrow checker rules ensure we can't do
> something illegal.
Ok, that all matches my understanding of what I thought was going on. I
do wonder if it would be good to wrap this up in a
struct DeviceBorrow {
dev: ManuallyDrop<Device>
}
impl DeviceBorrow {
pub unsafe fn from_raw(*mut bindings::drm_device) -> DeviceBorrow;
}
impl Deref<Device> for DeviceBorrow {
...
}
with documentation, etc. Seeing a ManuallyDrop which is never dropped
sets my rust senses tingling. Maybe that's too much typing for each
object? I don't want to add a bunch of extra work but this seems like
a pretty common pattern we're going to hit everywhere.
~Faith
^ permalink raw reply [flat|nested] 122+ messages in thread* Re: [PATCH RFC 03/18] rust: drm: file: Add File abstraction
2023-03-13 17:49 ` Faith Ekstrand
@ 2023-03-14 2:07 ` Boqun Feng
2023-04-05 11:25 ` Daniel Vetter
0 siblings, 1 reply; 122+ messages in thread
From: Boqun Feng @ 2023-03-14 2:07 UTC (permalink / raw)
To: Faith Ekstrand
Cc: Asahi Lina, Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
David Airlie, Daniel Vetter, Miguel Ojeda, Alex Gaynor,
Wedson Almeida Filho, Gary Guo, Björn Roy Baron,
Sumit Semwal, Christian König, Luben Tuikov,
Jarkko Sakkinen, Dave Hansen, Alyssa Rosenzweig, Karol Herbst,
Ella Stanforth, Mary, linux-kernel, dri-devel, rust-for-linux,
linux-media, linaro-mm-sig, linux-sgx, asahi
On Mon, Mar 13, 2023 at 12:49:57PM -0500, Faith Ekstrand wrote:
> On Fri, 2023-03-10 at 07:16 +0900, Asahi Lina wrote:
> > On 10/03/2023 06.16, Faith Ekstrand wrote:
> > > On Tue, 2023-03-07 at 23:25 +0900, Asahi Lina wrote:
> > > > A DRM File is the DRM counterpart to a kernel file structure,
> > > > representing an open DRM file descriptor. Add a Rust abstraction
> > > > to
> > > > allow drivers to implement their own File types that implement
> > > > the
> > > > DriverFile trait.
> > > >
> > > > Signed-off-by: Asahi Lina <lina@asahilina.net>
> > > > ---
> > > > rust/bindings/bindings_helper.h | 1 +
> > > > rust/kernel/drm/drv.rs | 7 ++-
> > > > rust/kernel/drm/file.rs | 113
> > > > ++++++++++++++++++++++++++++++++++++++++
> > > > rust/kernel/drm/mod.rs | 1 +
> > > > 4 files changed, 120 insertions(+), 2 deletions(-)
> > > >
> > > > diff --git a/rust/bindings/bindings_helper.h
> > > > b/rust/bindings/bindings_helper.h
> > > > index 2a999138c4ae..7d7828faf89c 100644
> > > > --- a/rust/bindings/bindings_helper.h
> > > > +++ b/rust/bindings/bindings_helper.h
> > > > @@ -8,6 +8,7 @@
> > > >
> > > > #include <drm/drm_device.h>
> > > > #include <drm/drm_drv.h>
> > > > +#include <drm/drm_file.h>
> > > > #include <drm/drm_ioctl.h>
> > > > #include <linux/delay.h>
> > > > #include <linux/device.h>
> > > > diff --git a/rust/kernel/drm/drv.rs b/rust/kernel/drm/drv.rs
> > > > index 29a465515dc9..1dcb651e1417 100644
> > > > --- a/rust/kernel/drm/drv.rs
> > > > +++ b/rust/kernel/drm/drv.rs
> > > > @@ -144,6 +144,9 @@ pub trait Driver {
> > > > /// Should be either `drm::gem::Object<T>` or
> > > > `drm::gem::shmem::Object<T>`.
> > > > type Object: AllocImpl;
> > > >
> > > > + /// The type used to represent a DRM File (client)
> > > > + type File: drm::file::DriverFile;
> > > > +
> > > > /// Driver metadata
> > > > const INFO: DriverInfo;
> > > >
> > > > @@ -213,8 +216,8 @@ macro_rules! drm_device_register {
> > > > impl<T: Driver> Registration<T> {
> > > > const VTABLE: bindings::drm_driver = drm_legacy_fields! {
> > > > load: None,
> > > > - open: None, // TODO: File abstraction
> > > > - postclose: None, // TODO: File abstraction
> > > > + open: Some(drm::file::open_callback::<T::File>),
> > > > + postclose:
> > > > Some(drm::file::postclose_callback::<T::File>),
> > > > lastclose: None,
> > > > unload: None,
> > > > release: None,
> > > > diff --git a/rust/kernel/drm/file.rs b/rust/kernel/drm/file.rs
> > > > new file mode 100644
> > > > index 000000000000..48751e93c38a
> > > > --- /dev/null
> > > > +++ b/rust/kernel/drm/file.rs
> > > > @@ -0,0 +1,113 @@
> > > > +// SPDX-License-Identifier: GPL-2.0 OR MIT
> > > > +
> > > > +//! DRM File objects.
> > > > +//!
> > > > +//! C header:
> > > > [`include/linux/drm/drm_file.h`](../../../../include/linux/drm/dr
> > > > m_fi
> > > > le.h)
> > > > +
> > > > +use crate::{bindings, drm, error::Result};
> > > > +use alloc::boxed::Box;
> > > > +use core::marker::PhantomData;
> > > > +use core::ops::Deref;
> > > > +
> > > > +/// Trait that must be implemented by DRM drivers to represent a
> > > > DRM
> > > > File (a client instance).
> > > > +pub trait DriverFile {
> > > > + /// The parent `Driver` implementation for this
> > > > `DriverFile`.
> > > > + type Driver: drm::drv::Driver;
> > > > +
> > > > + /// Open a new file (called when a client opens the DRM
> > > > device).
> > > > + fn open(device: &drm::device::Device<Self::Driver>) ->
> > > > Result<Box<Self>>;
> > > > +}
> > > > +
> > > > +/// An open DRM File.
> > > > +///
> > > > +/// # Invariants
> > > > +/// `raw` is a valid pointer to a `drm_file` struct.
> > > > +#[repr(transparent)]
> > > > +pub struct File<T: DriverFile> {
> > > > + raw: *mut bindings::drm_file,
> > > > + _p: PhantomData<T>,
> > > > +}
> > > > +
> > > > +pub(super) unsafe extern "C" fn open_callback<T: DriverFile>(
> > > > + raw_dev: *mut bindings::drm_device,
> > > > + raw_file: *mut bindings::drm_file,
> > > > +) -> core::ffi::c_int {
> > > > + let drm = core::mem::ManuallyDrop::new(unsafe {
> > > > drm::device::Device::from_raw(raw_dev) });
> > >
> > > Maybe you can help educate me a bit here... This feels like a
> > > really
> > > sketchy pattern. We're creating a Device from a pointer, an
> > > operation
> > > which inherently consumes a reference but then marking it
> > > ManuallyDrop
> > > so drm_device_put() never gets called. It took me a while but I
> > > think
> > > I figured out what you're trying to do: Make it so all the Rust
> > > stuff
> > > works with Device, not drm_device but it still feels really wrong.
> > > It
> > > works, it just feels like there's a lot of unsafe abstraction
> > > juggling
> > > happening here and I expect this operation is going to be pretty
> > > common
> > > in the Rust abstraction layer.
> >
> > So I think this is going to be a pretty common pattern in this kind
> > of
> > abstraction. The problem is that, of course, in C there is no
> > distinction between an owned reference and a borrowed one. Here we
> > have
> > a borrowed reference to a struct drm_device, and we need to turn it
> > into
> > a &Device (which is the Rust equivalent type). But for &Device to
> > exist
> > we need a Device to exist in the first place, and Device normally
> > implies ownership of the underlying drm_device.
>
> Thanks! Putting it in terms of borrow really helps clear up the
> difference.
>
> > We could just acquire a reference here, but then we're needlessly
> > grabbing a ref only to drop it at the end of the function, which is
> > pointless when the caller is holding another reference for us while
> > the
> > callback runs. And of course Rust likes to claim to offer zero-cost
> > abstractions, so it would be kind of sad to have to do that... ^^
>
> Yeah, I agree we don't want to take extra references.
>
> > Just doing drm::device::Device::from_raw(raw_dev) is a ticking time
> > bomb, because we haven't acquired a reference (which would normally
> > be
> > required). If that Device ever gets dropped, we've messed up the
> > refcounting and stolen the caller's reference. We could try to ensure
> > it
> > gets passed to core::mem::forget in all paths out, but that gets
> > error-prone very quickly when trying to cover error paths. So
> > instead,
> > we put it into a ManuallyDrop. That takes care of neutering the ref
> > drop, so we don't have to worry about messing that up. Then the only
> > remaining safety requirement is that that the ManuallyDrop<Device>
> > never
> > escape the callback function, and that's easy to ensure: we only pass
> > a
> > &ref to the user (which via auto-deref ends up being a &Device), and
> > then nothing bad can happen. If the user wants an owned reference to
> > the
> > device to keep around, they can call .clone() on it and that's when
> > the
> > incref happens.
> >
> > Basically, ManuallyDrop<T> where T is a reference counted type
> > represents a borrowed reference to a T coming from the C side. You
> > can
> > see another use of this pattern in gem::Object, which contains a
> > ManuallyDrop<Device> that represents a borrowed reference to the
> > device
> > that owns that object. The DRM core (as far as I know!) guarantees
> > that
> > DRM devices outlive all of their GEM objects, so we can materialize a
> > borrowed reference and as long as it never leaves the GEM object, it
> > will be sound. Then we can take &Device references from it whenever
> > we
> > want, and the usual Rust borrow checker rules ensure we can't do
> > something illegal.
>
> Ok, that all matches my understanding of what I thought was going on. I
> do wonder if it would be good to wrap this up in a
>
> struct DeviceBorrow {
> dev: ManuallyDrop<Device>
> }
>
> impl DeviceBorrow {
> pub unsafe fn from_raw(*mut bindings::drm_device) -> DeviceBorrow;
> }
>
> impl Deref<Device> for DeviceBorrow {
> ...
> }
>
> with documentation, etc. Seeing a ManuallyDrop which is never dropped
> sets my rust senses tingling. Maybe that's too much typing for each
> object? I don't want to add a bunch of extra work but this seems like
> a pretty common pattern we're going to hit everywhere.
>
I just want to mention, there is a different way to do the abstraction
here:
similar to https://lore.kernel.org/rust-for-linux/ZA9l0EHCRRr%2Fmyoq@boqun-archlinux
* Define Device as tranparent represention of struct drm_device:
#[repr(transparent)]
struct Device(Opaque<bindings::drm_device>);
* impl `AlwaysRefCounted`[1] for `Device`, therefore we can use
`ARef<Device>`[2] as a smart pointer to `drm_device`.
* drm_device related methods are still implemented in `impl Device`
* In `open_callback`, we can just get a `&Device` from `*mut
bindings::drm_device` unsafely, and that's all. Or introduce a helper
function if we want:
pub unsafe fn with_device<F>(ptr: *mut drm_device, f: F) -> Result
where
F: FnOnce(&Device) -> Result
{
let d = unsafe { &*ptr };
f(d)
}
The main difference is that we now treat a pointer to drm_device as a
reference to the device, not the owner.
It seems we need to also change our driver/device framework to use this
approach, but it looks better to me.
Regards,
Boqun
[1]: https://rust-for-linux.github.io/docs/kernel/trait.AlwaysRefCounted.html
[2]: https://rust-for-linux.github.io/docs/kernel/struct.ARef.html
> ~Faith
^ permalink raw reply [flat|nested] 122+ messages in thread* Re: [PATCH RFC 03/18] rust: drm: file: Add File abstraction
2023-03-14 2:07 ` Boqun Feng
@ 2023-04-05 11:25 ` Daniel Vetter
0 siblings, 0 replies; 122+ messages in thread
From: Daniel Vetter @ 2023-04-05 11:25 UTC (permalink / raw)
To: Boqun Feng
Cc: Faith Ekstrand, Asahi Lina, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Daniel Vetter, Miguel Ojeda,
Alex Gaynor, Wedson Almeida Filho, Gary Guo,
Björn Roy Baron, Sumit Semwal, Christian König,
Luben Tuikov, Jarkko Sakkinen, Dave Hansen, Alyssa Rosenzweig,
Karol Herbst, Ella Stanforth, Mary, linux-kernel, dri-devel,
rust-for-linux, linux-media, linaro-mm-sig, linux-sgx, asahi
On Mon, Mar 13, 2023 at 07:07:09PM -0700, Boqun Feng wrote:
> On Mon, Mar 13, 2023 at 12:49:57PM -0500, Faith Ekstrand wrote:
> > On Fri, 2023-03-10 at 07:16 +0900, Asahi Lina wrote:
> > > On 10/03/2023 06.16, Faith Ekstrand wrote:
> > > > On Tue, 2023-03-07 at 23:25 +0900, Asahi Lina wrote:
> > > > > A DRM File is the DRM counterpart to a kernel file structure,
> > > > > representing an open DRM file descriptor. Add a Rust abstraction
> > > > > to
> > > > > allow drivers to implement their own File types that implement
> > > > > the
> > > > > DriverFile trait.
> > > > >
> > > > > Signed-off-by: Asahi Lina <lina@asahilina.net>
> > > > > ---
> > > > > rust/bindings/bindings_helper.h | 1 +
> > > > > rust/kernel/drm/drv.rs | 7 ++-
> > > > > rust/kernel/drm/file.rs | 113
> > > > > ++++++++++++++++++++++++++++++++++++++++
> > > > > rust/kernel/drm/mod.rs | 1 +
> > > > > 4 files changed, 120 insertions(+), 2 deletions(-)
> > > > >
> > > > > diff --git a/rust/bindings/bindings_helper.h
> > > > > b/rust/bindings/bindings_helper.h
> > > > > index 2a999138c4ae..7d7828faf89c 100644
> > > > > --- a/rust/bindings/bindings_helper.h
> > > > > +++ b/rust/bindings/bindings_helper.h
> > > > > @@ -8,6 +8,7 @@
> > > > >
> > > > > #include <drm/drm_device.h>
> > > > > #include <drm/drm_drv.h>
> > > > > +#include <drm/drm_file.h>
> > > > > #include <drm/drm_ioctl.h>
> > > > > #include <linux/delay.h>
> > > > > #include <linux/device.h>
> > > > > diff --git a/rust/kernel/drm/drv.rs b/rust/kernel/drm/drv.rs
> > > > > index 29a465515dc9..1dcb651e1417 100644
> > > > > --- a/rust/kernel/drm/drv.rs
> > > > > +++ b/rust/kernel/drm/drv.rs
> > > > > @@ -144,6 +144,9 @@ pub trait Driver {
> > > > > /// Should be either `drm::gem::Object<T>` or
> > > > > `drm::gem::shmem::Object<T>`.
> > > > > type Object: AllocImpl;
> > > > >
> > > > > + /// The type used to represent a DRM File (client)
> > > > > + type File: drm::file::DriverFile;
> > > > > +
> > > > > /// Driver metadata
> > > > > const INFO: DriverInfo;
> > > > >
> > > > > @@ -213,8 +216,8 @@ macro_rules! drm_device_register {
> > > > > impl<T: Driver> Registration<T> {
> > > > > const VTABLE: bindings::drm_driver = drm_legacy_fields! {
> > > > > load: None,
> > > > > - open: None, // TODO: File abstraction
> > > > > - postclose: None, // TODO: File abstraction
> > > > > + open: Some(drm::file::open_callback::<T::File>),
> > > > > + postclose:
> > > > > Some(drm::file::postclose_callback::<T::File>),
> > > > > lastclose: None,
> > > > > unload: None,
> > > > > release: None,
> > > > > diff --git a/rust/kernel/drm/file.rs b/rust/kernel/drm/file.rs
> > > > > new file mode 100644
> > > > > index 000000000000..48751e93c38a
> > > > > --- /dev/null
> > > > > +++ b/rust/kernel/drm/file.rs
> > > > > @@ -0,0 +1,113 @@
> > > > > +// SPDX-License-Identifier: GPL-2.0 OR MIT
> > > > > +
> > > > > +//! DRM File objects.
> > > > > +//!
> > > > > +//! C header:
> > > > > [`include/linux/drm/drm_file.h`](../../../../include/linux/drm/dr
> > > > > m_fi
> > > > > le.h)
> > > > > +
> > > > > +use crate::{bindings, drm, error::Result};
> > > > > +use alloc::boxed::Box;
> > > > > +use core::marker::PhantomData;
> > > > > +use core::ops::Deref;
> > > > > +
> > > > > +/// Trait that must be implemented by DRM drivers to represent a
> > > > > DRM
> > > > > File (a client instance).
> > > > > +pub trait DriverFile {
> > > > > + /// The parent `Driver` implementation for this
> > > > > `DriverFile`.
> > > > > + type Driver: drm::drv::Driver;
> > > > > +
> > > > > + /// Open a new file (called when a client opens the DRM
> > > > > device).
> > > > > + fn open(device: &drm::device::Device<Self::Driver>) ->
> > > > > Result<Box<Self>>;
> > > > > +}
> > > > > +
> > > > > +/// An open DRM File.
> > > > > +///
> > > > > +/// # Invariants
> > > > > +/// `raw` is a valid pointer to a `drm_file` struct.
> > > > > +#[repr(transparent)]
> > > > > +pub struct File<T: DriverFile> {
> > > > > + raw: *mut bindings::drm_file,
> > > > > + _p: PhantomData<T>,
> > > > > +}
> > > > > +
> > > > > +pub(super) unsafe extern "C" fn open_callback<T: DriverFile>(
> > > > > + raw_dev: *mut bindings::drm_device,
> > > > > + raw_file: *mut bindings::drm_file,
> > > > > +) -> core::ffi::c_int {
> > > > > + let drm = core::mem::ManuallyDrop::new(unsafe {
> > > > > drm::device::Device::from_raw(raw_dev) });
> > > >
> > > > Maybe you can help educate me a bit here... This feels like a
> > > > really
> > > > sketchy pattern. We're creating a Device from a pointer, an
> > > > operation
> > > > which inherently consumes a reference but then marking it
> > > > ManuallyDrop
> > > > so drm_device_put() never gets called. It took me a while but I
> > > > think
> > > > I figured out what you're trying to do: Make it so all the Rust
> > > > stuff
> > > > works with Device, not drm_device but it still feels really wrong.
> > > > It
> > > > works, it just feels like there's a lot of unsafe abstraction
> > > > juggling
> > > > happening here and I expect this operation is going to be pretty
> > > > common
> > > > in the Rust abstraction layer.
> > >
> > > So I think this is going to be a pretty common pattern in this kind
> > > of
> > > abstraction. The problem is that, of course, in C there is no
> > > distinction between an owned reference and a borrowed one. Here we
> > > have
> > > a borrowed reference to a struct drm_device, and we need to turn it
> > > into
> > > a &Device (which is the Rust equivalent type). But for &Device to
> > > exist
> > > we need a Device to exist in the first place, and Device normally
> > > implies ownership of the underlying drm_device.
> >
> > Thanks! Putting it in terms of borrow really helps clear up the
> > difference.
> >
> > > We could just acquire a reference here, but then we're needlessly
> > > grabbing a ref only to drop it at the end of the function, which is
> > > pointless when the caller is holding another reference for us while
> > > the
> > > callback runs. And of course Rust likes to claim to offer zero-cost
> > > abstractions, so it would be kind of sad to have to do that... ^^
> >
> > Yeah, I agree we don't want to take extra references.
> >
> > > Just doing drm::device::Device::from_raw(raw_dev) is a ticking time
> > > bomb, because we haven't acquired a reference (which would normally
> > > be
> > > required). If that Device ever gets dropped, we've messed up the
> > > refcounting and stolen the caller's reference. We could try to ensure
> > > it
> > > gets passed to core::mem::forget in all paths out, but that gets
> > > error-prone very quickly when trying to cover error paths. So
> > > instead,
> > > we put it into a ManuallyDrop. That takes care of neutering the ref
> > > drop, so we don't have to worry about messing that up. Then the only
> > > remaining safety requirement is that that the ManuallyDrop<Device>
> > > never
> > > escape the callback function, and that's easy to ensure: we only pass
> > > a
> > > &ref to the user (which via auto-deref ends up being a &Device), and
> > > then nothing bad can happen. If the user wants an owned reference to
> > > the
> > > device to keep around, they can call .clone() on it and that's when
> > > the
> > > incref happens.
> > >
> > > Basically, ManuallyDrop<T> where T is a reference counted type
> > > represents a borrowed reference to a T coming from the C side. You
> > > can
> > > see another use of this pattern in gem::Object, which contains a
> > > ManuallyDrop<Device> that represents a borrowed reference to the
> > > device
> > > that owns that object. The DRM core (as far as I know!) guarantees
> > > that
> > > DRM devices outlive all of their GEM objects, so we can materialize a
> > > borrowed reference and as long as it never leaves the GEM object, it
> > > will be sound. Then we can take &Device references from it whenever
> > > we
> > > want, and the usual Rust borrow checker rules ensure we can't do
> > > something illegal.
> >
> > Ok, that all matches my understanding of what I thought was going on. I
> > do wonder if it would be good to wrap this up in a
> >
> > struct DeviceBorrow {
> > dev: ManuallyDrop<Device>
> > }
> >
> > impl DeviceBorrow {
> > pub unsafe fn from_raw(*mut bindings::drm_device) -> DeviceBorrow;
> > }
> >
> > impl Deref<Device> for DeviceBorrow {
> > ...
> > }
> >
> > with documentation, etc. Seeing a ManuallyDrop which is never dropped
> > sets my rust senses tingling. Maybe that's too much typing for each
> > object? I don't want to add a bunch of extra work but this seems like
> > a pretty common pattern we're going to hit everywhere.
> >
>
> I just want to mention, there is a different way to do the abstraction
> here:
>
> similar to https://lore.kernel.org/rust-for-linux/ZA9l0EHCRRr%2Fmyoq@boqun-archlinux
>
> * Define Device as tranparent represention of struct drm_device:
>
> #[repr(transparent)]
> struct Device(Opaque<bindings::drm_device>);
>
> * impl `AlwaysRefCounted`[1] for `Device`, therefore we can use
> `ARef<Device>`[2] as a smart pointer to `drm_device`.
>
> * drm_device related methods are still implemented in `impl Device`
>
> * In `open_callback`, we can just get a `&Device` from `*mut
> bindings::drm_device` unsafely, and that's all. Or introduce a helper
> function if we want:
>
> pub unsafe fn with_device<F>(ptr: *mut drm_device, f: F) -> Result
> where
> F: FnOnce(&Device) -> Result
> {
> let d = unsafe { &*ptr };
> f(d)
> }
>
> The main difference is that we now treat a pointer to drm_device as a
> reference to the device, not the owner.
>
> It seems we need to also change our driver/device framework to use this
> approach, but it looks better to me.
So I really don't have enough rust clue to have any useful opinion on how
the glue should look like, but semantically the struct drm_file should
only ever be borrowed as a parameter to a driver hook, so that rust can
guarantee that the driver doesn't do anything funny and uses it beyond the
end of that function. This holds for all the callbacks like open/close or
also all the ioctl.
The other semantic thing is that that the ioctls should be able to rely on
open having fully constructed the thing. I think the trait and dependent
type stuff ensure that?
What I've missed (but maybe just looked in the wrong place) is that the
ioctl support (and really anything else where the driver gets a struct
drm_file on the C side, but I don't think there is anything else) should
also make sure you get the right driver-specific type and not something
else.
I did notice the FIXME in the first patch, I guess if it makes
landing all this easier we could also keep this as a todo item to improve
once things landed. That btw holds for a lot of the big "how to map
semantics correctly to rust" questions I'm throwing up here. Maybe a
Documentation/gpu/rust.rst file would be good to include, with these todo
items noted instead of just FIXME sprinkled in patches? At least for
things that will take more effort to polish.
-Daniel
>
> Regards,
> Boqun
>
> [1]: https://rust-for-linux.github.io/docs/kernel/trait.AlwaysRefCounted.html
> [2]: https://rust-for-linux.github.io/docs/kernel/struct.ARef.html
>
> > ~Faith
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
^ permalink raw reply [flat|nested] 122+ messages in thread
* [PATCH RFC 04/18] rust: drm: gem: Add GEM object abstraction
2023-03-07 14:25 [PATCH RFC 00/18] Rust DRM subsystem abstractions (& preview AGX driver) Asahi Lina
` (2 preceding siblings ...)
2023-03-07 14:25 ` [PATCH RFC 03/18] rust: drm: file: Add File abstraction Asahi Lina
@ 2023-03-07 14:25 ` Asahi Lina
2023-04-05 11:08 ` Daniel Vetter
2023-03-07 14:25 ` [PATCH RFC 05/18] drm/gem-shmem: Export VM ops functions Asahi Lina
` (14 subsequent siblings)
18 siblings, 1 reply; 122+ messages in thread
From: Asahi Lina @ 2023-03-07 14:25 UTC (permalink / raw)
To: Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
David Airlie, Daniel Vetter, Miguel Ojeda, Alex Gaynor,
Wedson Almeida Filho, Boqun Feng, Gary Guo, Björn Roy Baron,
Sumit Semwal, Christian König, Luben Tuikov,
Jarkko Sakkinen, Dave Hansen
Cc: Alyssa Rosenzweig, Karol Herbst, Ella Stanforth, Faith Ekstrand,
Mary, linux-kernel, dri-devel, rust-for-linux, linux-media,
linaro-mm-sig, linux-sgx, asahi, Asahi Lina
The DRM GEM subsystem is the DRM memory management subsystem used by
most modern drivers. Add a Rust abstraction to allow Rust DRM driver
implementations to use it.
Signed-off-by: Asahi Lina <lina@asahilina.net>
---
rust/bindings/bindings_helper.h | 1 +
rust/helpers.c | 23 +++
rust/kernel/drm/drv.rs | 4 +-
rust/kernel/drm/gem/mod.rs | 374 ++++++++++++++++++++++++++++++++++++++++
rust/kernel/drm/mod.rs | 1 +
5 files changed, 401 insertions(+), 2 deletions(-)
diff --git a/rust/bindings/bindings_helper.h b/rust/bindings/bindings_helper.h
index 7d7828faf89c..7183dfe6473f 100644
--- a/rust/bindings/bindings_helper.h
+++ b/rust/bindings/bindings_helper.h
@@ -9,6 +9,7 @@
#include <drm/drm_device.h>
#include <drm/drm_drv.h>
#include <drm/drm_file.h>
+#include <drm/drm_gem.h>
#include <drm/drm_ioctl.h>
#include <linux/delay.h>
#include <linux/device.h>
diff --git a/rust/helpers.c b/rust/helpers.c
index 73b2ce607f27..78ec4162b03b 100644
--- a/rust/helpers.c
+++ b/rust/helpers.c
@@ -18,6 +18,7 @@
* accidentally exposed.
*/
+#include <drm/drm_gem.h>
#include <linux/bug.h>
#include <linux/build_bug.h>
#include <linux/device.h>
@@ -374,6 +375,28 @@ void rust_helper_init_completion(struct completion *c)
}
EXPORT_SYMBOL_GPL(rust_helper_init_completion);
+#ifdef CONFIG_DRM
+
+void rust_helper_drm_gem_object_get(struct drm_gem_object *obj)
+{
+ drm_gem_object_get(obj);
+}
+EXPORT_SYMBOL_GPL(rust_helper_drm_gem_object_get);
+
+void rust_helper_drm_gem_object_put(struct drm_gem_object *obj)
+{
+ drm_gem_object_put(obj);
+}
+EXPORT_SYMBOL_GPL(rust_helper_drm_gem_object_put);
+
+__u64 rust_helper_drm_vma_node_offset_addr(struct drm_vma_offset_node *node)
+{
+ return drm_vma_node_offset_addr(node);
+}
+EXPORT_SYMBOL_GPL(rust_helper_drm_vma_node_offset_addr);
+
+#endif
+
/*
* We use `bindgen`'s `--size_t-is-usize` option to bind the C `size_t` type
* as the Rust `usize` type, so we can use it in contexts where Rust
diff --git a/rust/kernel/drm/drv.rs b/rust/kernel/drm/drv.rs
index 1dcb651e1417..c138352cb489 100644
--- a/rust/kernel/drm/drv.rs
+++ b/rust/kernel/drm/drv.rs
@@ -126,7 +126,7 @@ pub struct AllocOps {
}
/// Trait for memory manager implementations. Implemented internally.
-pub trait AllocImpl: Sealed {
+pub trait AllocImpl: Sealed + drm::gem::IntoGEMObject {
/// The C callback operations for this memory manager.
const ALLOC_OPS: AllocOps;
}
@@ -263,7 +263,7 @@ impl<T: Driver> Registration<T> {
drm,
registered: false,
vtable,
- fops: Default::default(), // TODO: GEM abstraction
+ fops: drm::gem::create_fops(),
_pin: PhantomPinned,
_p: PhantomData,
})
diff --git a/rust/kernel/drm/gem/mod.rs b/rust/kernel/drm/gem/mod.rs
new file mode 100644
index 000000000000..8a7d99613718
--- /dev/null
+++ b/rust/kernel/drm/gem/mod.rs
@@ -0,0 +1,374 @@
+// SPDX-License-Identifier: GPL-2.0 OR MIT
+
+//! DRM GEM API
+//!
+//! C header: [`include/linux/drm/drm_gem.h`](../../../../include/linux/drm/drm_gem.h)
+
+use alloc::boxed::Box;
+
+use crate::{
+ bindings,
+ drm::{device, drv, file},
+ error::{to_result, Result},
+ prelude::*,
+};
+use core::{mem, mem::ManuallyDrop, ops::Deref, ops::DerefMut};
+
+/// GEM object functions, which must be implemented by drivers.
+pub trait BaseDriverObject<T: BaseObject>: Sync + Send + Sized {
+ /// Create a new driver data object for a GEM object of a given size.
+ fn new(dev: &device::Device<T::Driver>, size: usize) -> Result<Self>;
+
+ /// Open a new handle to an existing object, associated with a File.
+ fn open(
+ _obj: &<<T as IntoGEMObject>::Driver as drv::Driver>::Object,
+ _file: &file::File<<<T as IntoGEMObject>::Driver as drv::Driver>::File>,
+ ) -> Result {
+ Ok(())
+ }
+
+ /// Close a handle to an existing object, associated with a File.
+ fn close(
+ _obj: &<<T as IntoGEMObject>::Driver as drv::Driver>::Object,
+ _file: &file::File<<<T as IntoGEMObject>::Driver as drv::Driver>::File>,
+ ) {
+ }
+}
+
+/// Trait that represents a GEM object subtype
+pub trait IntoGEMObject: Sized + crate::private::Sealed {
+ /// Owning driver for this type
+ type Driver: drv::Driver;
+
+ /// Returns a pointer to the raw `drm_gem_object` structure, which must be valid as long as
+ /// this owning object is valid.
+ fn gem_obj(&self) -> *mut bindings::drm_gem_object;
+
+ /// Returns a reference to the raw `drm_gem_object` structure, which must be valid as long as
+ /// this owning object is valid.
+ fn gem_ref(&self) -> &bindings::drm_gem_object {
+ // SAFETY: gem_obj() must be valid per the above requirement.
+ unsafe { &*self.gem_obj() }
+ }
+
+ /// Converts a pointer to a `drm_gem_object` into a pointer to this type.
+ fn from_gem_obj(obj: *mut bindings::drm_gem_object) -> *mut Self;
+}
+
+/// Trait which must be implemented by drivers using base GEM objects.
+pub trait DriverObject: BaseDriverObject<Object<Self>> {
+ /// Parent `Driver` for this object.
+ type Driver: drv::Driver;
+}
+
+unsafe extern "C" fn free_callback<T: DriverObject>(obj: *mut bindings::drm_gem_object) {
+ // SAFETY: All of our objects are Object<T>.
+ let this = crate::container_of!(obj, Object<T>, obj) as *mut Object<T>;
+
+ // SAFETY: The pointer we got has to be valid
+ unsafe { bindings::drm_gem_object_release(obj) };
+
+ // SAFETY: All of our objects are allocated via Box<>, and we're in the
+ // free callback which guarantees this object has zero remaining references,
+ // so we can drop it
+ unsafe { Box::from_raw(this) };
+}
+
+unsafe extern "C" fn open_callback<T: BaseDriverObject<U>, U: BaseObject>(
+ raw_obj: *mut bindings::drm_gem_object,
+ raw_file: *mut bindings::drm_file,
+) -> core::ffi::c_int {
+ // SAFETY: The pointer we got has to be valid.
+ let file = unsafe {
+ file::File::<<<U as IntoGEMObject>::Driver as drv::Driver>::File>::from_raw(raw_file)
+ };
+ let obj =
+ <<<U as IntoGEMObject>::Driver as drv::Driver>::Object as IntoGEMObject>::from_gem_obj(
+ raw_obj,
+ );
+
+ // SAFETY: from_gem_obj() returns a valid pointer as long as the type is
+ // correct and the raw_obj we got is valid.
+ match T::open(unsafe { &*obj }, &file) {
+ Err(e) => e.to_kernel_errno(),
+ Ok(()) => 0,
+ }
+}
+
+unsafe extern "C" fn close_callback<T: BaseDriverObject<U>, U: BaseObject>(
+ raw_obj: *mut bindings::drm_gem_object,
+ raw_file: *mut bindings::drm_file,
+) {
+ // SAFETY: The pointer we got has to be valid.
+ let file = unsafe {
+ file::File::<<<U as IntoGEMObject>::Driver as drv::Driver>::File>::from_raw(raw_file)
+ };
+ let obj =
+ <<<U as IntoGEMObject>::Driver as drv::Driver>::Object as IntoGEMObject>::from_gem_obj(
+ raw_obj,
+ );
+
+ // SAFETY: from_gem_obj() returns a valid pointer as long as the type is
+ // correct and the raw_obj we got is valid.
+ T::close(unsafe { &*obj }, &file);
+}
+
+impl<T: DriverObject> IntoGEMObject for Object<T> {
+ type Driver = T::Driver;
+
+ fn gem_obj(&self) -> *mut bindings::drm_gem_object {
+ &self.obj as *const _ as *mut _
+ }
+
+ fn from_gem_obj(obj: *mut bindings::drm_gem_object) -> *mut Object<T> {
+ crate::container_of!(obj, Object<T>, obj) as *mut Object<T>
+ }
+}
+
+/// Base operations shared by all GEM object classes
+pub trait BaseObject: IntoGEMObject {
+ /// Returns the size of the object in bytes.
+ fn size(&self) -> usize {
+ self.gem_ref().size
+ }
+
+ /// Creates a new reference to the object.
+ fn reference(&self) -> ObjectRef<Self> {
+ // SAFETY: Having a reference to an Object implies holding a GEM reference
+ unsafe {
+ bindings::drm_gem_object_get(self.gem_obj());
+ }
+ ObjectRef {
+ ptr: self as *const _,
+ }
+ }
+
+ /// Creates a new handle for the object associated with a given `File`
+ /// (or returns an existing one).
+ fn create_handle(
+ &self,
+ file: &file::File<<<Self as IntoGEMObject>::Driver as drv::Driver>::File>,
+ ) -> Result<u32> {
+ let mut handle: u32 = 0;
+ // SAFETY: The arguments are all valid per the type invariants.
+ to_result(unsafe {
+ bindings::drm_gem_handle_create(file.raw() as *mut _, self.gem_obj(), &mut handle)
+ })?;
+ Ok(handle)
+ }
+
+ /// Looks up an object by its handle for a given `File`.
+ fn lookup_handle(
+ file: &file::File<<<Self as IntoGEMObject>::Driver as drv::Driver>::File>,
+ handle: u32,
+ ) -> Result<ObjectRef<Self>> {
+ // SAFETY: The arguments are all valid per the type invariants.
+ let ptr = unsafe { bindings::drm_gem_object_lookup(file.raw() as *mut _, handle) };
+
+ if ptr.is_null() {
+ Err(ENOENT)
+ } else {
+ Ok(ObjectRef {
+ ptr: ptr as *const _,
+ })
+ }
+ }
+
+ /// Creates an mmap offset to map the object from userspace.
+ fn create_mmap_offset(&self) -> Result<u64> {
+ // SAFETY: The arguments are valid per the type invariant.
+ to_result(unsafe {
+ // TODO: is this threadsafe?
+ bindings::drm_gem_create_mmap_offset(self.gem_obj())
+ })?;
+ Ok(unsafe {
+ bindings::drm_vma_node_offset_addr(&self.gem_ref().vma_node as *const _ as *mut _)
+ })
+ }
+}
+
+impl<T: IntoGEMObject> BaseObject for T {}
+
+/// A base GEM object.
+#[repr(C)]
+pub struct Object<T: DriverObject> {
+ obj: bindings::drm_gem_object,
+ // The DRM core ensures the Device exists as long as its objects exist, so we don't need to
+ // manage the reference count here.
+ dev: ManuallyDrop<device::Device<T::Driver>>,
+ inner: T,
+}
+
+impl<T: DriverObject> Object<T> {
+ /// The size of this object's structure.
+ pub const SIZE: usize = mem::size_of::<Self>();
+
+ const OBJECT_FUNCS: bindings::drm_gem_object_funcs = bindings::drm_gem_object_funcs {
+ free: Some(free_callback::<T>),
+ open: Some(open_callback::<T, Object<T>>),
+ close: Some(close_callback::<T, Object<T>>),
+ print_info: None,
+ export: None,
+ pin: None,
+ unpin: None,
+ get_sg_table: None,
+ vmap: None,
+ vunmap: None,
+ mmap: None,
+ vm_ops: core::ptr::null_mut(),
+ };
+
+ /// Create a new GEM object.
+ pub fn new(dev: &device::Device<T::Driver>, size: usize) -> Result<UniqueObjectRef<Self>> {
+ let mut obj: Box<Self> = Box::try_new(Self {
+ // SAFETY: This struct is expected to be zero-initialized
+ obj: unsafe { mem::zeroed() },
+ // SAFETY: The drm subsystem guarantees that the drm_device will live as long as
+ // the GEM object lives, so we can conjure a reference out of thin air.
+ dev: ManuallyDrop::new(unsafe { device::Device::from_raw(dev.ptr) }),
+ inner: T::new(dev, size)?,
+ })?;
+
+ obj.obj.funcs = &Self::OBJECT_FUNCS;
+ to_result(unsafe {
+ bindings::drm_gem_object_init(dev.raw() as *mut _, &mut obj.obj, size)
+ })?;
+
+ let obj_ref = UniqueObjectRef {
+ ptr: Box::leak(obj),
+ };
+
+ Ok(obj_ref)
+ }
+
+ /// Returns the `Device` that owns this GEM object.
+ pub fn dev(&self) -> &device::Device<T::Driver> {
+ &self.dev
+ }
+}
+
+impl<T: DriverObject> crate::private::Sealed for Object<T> {}
+
+impl<T: DriverObject> Deref for Object<T> {
+ type Target = T;
+
+ fn deref(&self) -> &Self::Target {
+ &self.inner
+ }
+}
+
+impl<T: DriverObject> DerefMut for Object<T> {
+ fn deref_mut(&mut self) -> &mut Self::Target {
+ &mut self.inner
+ }
+}
+
+impl<T: DriverObject> drv::AllocImpl for Object<T> {
+ const ALLOC_OPS: drv::AllocOps = drv::AllocOps {
+ gem_create_object: None,
+ prime_handle_to_fd: Some(bindings::drm_gem_prime_handle_to_fd),
+ prime_fd_to_handle: Some(bindings::drm_gem_prime_fd_to_handle),
+ gem_prime_import: None,
+ gem_prime_import_sg_table: None,
+ gem_prime_mmap: Some(bindings::drm_gem_prime_mmap),
+ dumb_create: None,
+ dumb_map_offset: None,
+ dumb_destroy: None,
+ };
+}
+
+/// A reference-counted shared reference to a base GEM object.
+pub struct ObjectRef<T: IntoGEMObject> {
+ // Invariant: the pointer is valid and initialized, and this ObjectRef owns a reference to it.
+ ptr: *const T,
+}
+
+/// SAFETY: GEM object references are safe to share between threads.
+unsafe impl<T: IntoGEMObject> Send for ObjectRef<T> {}
+unsafe impl<T: IntoGEMObject> Sync for ObjectRef<T> {}
+
+impl<T: IntoGEMObject> Clone for ObjectRef<T> {
+ fn clone(&self) -> Self {
+ self.reference()
+ }
+}
+
+impl<T: IntoGEMObject> Drop for ObjectRef<T> {
+ fn drop(&mut self) {
+ // SAFETY: Having an ObjectRef implies holding a GEM reference.
+ // The free callback will take care of deallocation.
+ unsafe {
+ bindings::drm_gem_object_put((*self.ptr).gem_obj());
+ }
+ }
+}
+
+impl<T: IntoGEMObject> Deref for ObjectRef<T> {
+ type Target = T;
+
+ fn deref(&self) -> &Self::Target {
+ // SAFETY: The pointer is valid per the invariant
+ unsafe { &*self.ptr }
+ }
+}
+
+/// A unique reference to a base GEM object.
+pub struct UniqueObjectRef<T: IntoGEMObject> {
+ // Invariant: the pointer is valid and initialized, and this ObjectRef owns the only reference
+ // to it.
+ ptr: *mut T,
+}
+
+impl<T: IntoGEMObject> UniqueObjectRef<T> {
+ /// Downgrade this reference to a shared reference.
+ pub fn into_ref(self) -> ObjectRef<T> {
+ let ptr = self.ptr as *const _;
+ core::mem::forget(self);
+
+ ObjectRef { ptr }
+ }
+}
+
+impl<T: IntoGEMObject> Drop for UniqueObjectRef<T> {
+ fn drop(&mut self) {
+ // SAFETY: Having a UniqueObjectRef implies holding a GEM
+ // reference. The free callback will take care of deallocation.
+ unsafe {
+ bindings::drm_gem_object_put((*self.ptr).gem_obj());
+ }
+ }
+}
+
+impl<T: IntoGEMObject> Deref for UniqueObjectRef<T> {
+ type Target = T;
+
+ fn deref(&self) -> &Self::Target {
+ // SAFETY: The pointer is valid per the invariant
+ unsafe { &*self.ptr }
+ }
+}
+
+impl<T: IntoGEMObject> DerefMut for UniqueObjectRef<T> {
+ fn deref_mut(&mut self) -> &mut Self::Target {
+ // SAFETY: The pointer is valid per the invariant
+ unsafe { &mut *self.ptr }
+ }
+}
+
+pub(super) fn create_fops() -> bindings::file_operations {
+ bindings::file_operations {
+ owner: core::ptr::null_mut(),
+ open: Some(bindings::drm_open),
+ release: Some(bindings::drm_release),
+ unlocked_ioctl: Some(bindings::drm_ioctl),
+ #[cfg(CONFIG_COMPAT)]
+ compat_ioctl: Some(bindings::drm_compat_ioctl),
+ #[cfg(not(CONFIG_COMPAT))]
+ compat_ioctl: None,
+ poll: Some(bindings::drm_poll),
+ read: Some(bindings::drm_read),
+ llseek: Some(bindings::noop_llseek),
+ mmap: Some(bindings::drm_gem_mmap),
+ ..Default::default()
+ }
+}
diff --git a/rust/kernel/drm/mod.rs b/rust/kernel/drm/mod.rs
index a767942d0b52..c44760a1332f 100644
--- a/rust/kernel/drm/mod.rs
+++ b/rust/kernel/drm/mod.rs
@@ -5,4 +5,5 @@
pub mod device;
pub mod drv;
pub mod file;
+pub mod gem;
pub mod ioctl;
--
2.35.1
^ permalink raw reply related [flat|nested] 122+ messages in thread* Re: [PATCH RFC 04/18] rust: drm: gem: Add GEM object abstraction
2023-03-07 14:25 ` [PATCH RFC 04/18] rust: drm: gem: Add GEM object abstraction Asahi Lina
@ 2023-04-05 11:08 ` Daniel Vetter
2023-04-05 11:19 ` Miguel Ojeda
0 siblings, 1 reply; 122+ messages in thread
From: Daniel Vetter @ 2023-04-05 11:08 UTC (permalink / raw)
To: Asahi Lina
Cc: Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
David Airlie, Daniel Vetter, Miguel Ojeda, Alex Gaynor,
Wedson Almeida Filho, Boqun Feng, Gary Guo, Björn Roy Baron,
Sumit Semwal, Christian König, Luben Tuikov,
Jarkko Sakkinen, Dave Hansen, Alyssa Rosenzweig, Karol Herbst,
Ella Stanforth, Faith Ekstrand, Mary, linux-kernel, dri-devel,
rust-for-linux, linux-media, linaro-mm-sig, linux-sgx, asahi
Meta: I'm trying to unblock myself by limiting each reply to a narrow-ish
topic. Otherwise it's just too much. Here's the first.
On Tue, Mar 07, 2023 at 11:25:29PM +0900, Asahi Lina wrote:
> The DRM GEM subsystem is the DRM memory management subsystem used by
> most modern drivers. Add a Rust abstraction to allow Rust DRM driver
> implementations to use it.
>
> Signed-off-by: Asahi Lina <lina@asahilina.net>
> ---
> rust/bindings/bindings_helper.h | 1 +
> rust/helpers.c | 23 +++
> rust/kernel/drm/drv.rs | 4 +-
> rust/kernel/drm/gem/mod.rs | 374 ++++++++++++++++++++++++++++++++++++++++
> rust/kernel/drm/mod.rs | 1 +
> 5 files changed, 401 insertions(+), 2 deletions(-)
>
> diff --git a/rust/bindings/bindings_helper.h b/rust/bindings/bindings_helper.h
> index 7d7828faf89c..7183dfe6473f 100644
> --- a/rust/bindings/bindings_helper.h
> +++ b/rust/bindings/bindings_helper.h
> @@ -9,6 +9,7 @@
> #include <drm/drm_device.h>
> #include <drm/drm_drv.h>
> #include <drm/drm_file.h>
> +#include <drm/drm_gem.h>
> #include <drm/drm_ioctl.h>
> #include <linux/delay.h>
> #include <linux/device.h>
> diff --git a/rust/helpers.c b/rust/helpers.c
> index 73b2ce607f27..78ec4162b03b 100644
> --- a/rust/helpers.c
> +++ b/rust/helpers.c
> @@ -18,6 +18,7 @@
> * accidentally exposed.
> */
>
> +#include <drm/drm_gem.h>
> #include <linux/bug.h>
> #include <linux/build_bug.h>
> #include <linux/device.h>
> @@ -374,6 +375,28 @@ void rust_helper_init_completion(struct completion *c)
> }
> EXPORT_SYMBOL_GPL(rust_helper_init_completion);
>
> +#ifdef CONFIG_DRM
> +
> +void rust_helper_drm_gem_object_get(struct drm_gem_object *obj)
> +{
> + drm_gem_object_get(obj);
> +}
> +EXPORT_SYMBOL_GPL(rust_helper_drm_gem_object_get);
> +
> +void rust_helper_drm_gem_object_put(struct drm_gem_object *obj)
> +{
> + drm_gem_object_put(obj);
> +}
> +EXPORT_SYMBOL_GPL(rust_helper_drm_gem_object_put);
> +
> +__u64 rust_helper_drm_vma_node_offset_addr(struct drm_vma_offset_node *node)
> +{
> + return drm_vma_node_offset_addr(node);
> +}
> +EXPORT_SYMBOL_GPL(rust_helper_drm_vma_node_offset_addr);
Uh all the rust helper wrappers for all the kernel in a single file does
not sound good. Can we not split these up into each subsystem, and then
maybe instead of sprinkling #ifdef all over a .c file Make the compilation
of that file conditional on rust support (plus whatever other Kconfig gate
the other c files has already)?
Otherwise if rust adoption picks up there's going to be endless amounts of
cross-subsystem conflicts.
Also similarly, can we perhaps split up the bindings_helper.h file in a
per-subsystem way?
> +
> +#endif
> +
> /*
> * We use `bindgen`'s `--size_t-is-usize` option to bind the C `size_t` type
> * as the Rust `usize` type, so we can use it in contexts where Rust
> diff --git a/rust/kernel/drm/drv.rs b/rust/kernel/drm/drv.rs
> index 1dcb651e1417..c138352cb489 100644
> --- a/rust/kernel/drm/drv.rs
> +++ b/rust/kernel/drm/drv.rs
> @@ -126,7 +126,7 @@ pub struct AllocOps {
Similary I guess this needs to be all under rust for rust reasons. I'm
assuming that the plan is that rust patches in here get acked/reviewed by
rust people, but then merged through the drm subsystem? At least long term
I think that's the least painful way.
Meaning we need a MAINTAINERS entry for rust/kernel/drm which adds
dri-devel for review and the usual git repos somewhere earlier in the
series.
-Daniel
> }
>
> /// Trait for memory manager implementations. Implemented internally.
> -pub trait AllocImpl: Sealed {
> +pub trait AllocImpl: Sealed + drm::gem::IntoGEMObject {
> /// The C callback operations for this memory manager.
> const ALLOC_OPS: AllocOps;
> }
> @@ -263,7 +263,7 @@ impl<T: Driver> Registration<T> {
> drm,
> registered: false,
> vtable,
> - fops: Default::default(), // TODO: GEM abstraction
> + fops: drm::gem::create_fops(),
> _pin: PhantomPinned,
> _p: PhantomData,
> })
> diff --git a/rust/kernel/drm/gem/mod.rs b/rust/kernel/drm/gem/mod.rs
> new file mode 100644
> index 000000000000..8a7d99613718
> --- /dev/null
> +++ b/rust/kernel/drm/gem/mod.rs
> @@ -0,0 +1,374 @@
> +// SPDX-License-Identifier: GPL-2.0 OR MIT
> +
> +//! DRM GEM API
> +//!
> +//! C header: [`include/linux/drm/drm_gem.h`](../../../../include/linux/drm/drm_gem.h)
> +
> +use alloc::boxed::Box;
> +
> +use crate::{
> + bindings,
> + drm::{device, drv, file},
> + error::{to_result, Result},
> + prelude::*,
> +};
> +use core::{mem, mem::ManuallyDrop, ops::Deref, ops::DerefMut};
> +
> +/// GEM object functions, which must be implemented by drivers.
> +pub trait BaseDriverObject<T: BaseObject>: Sync + Send + Sized {
> + /// Create a new driver data object for a GEM object of a given size.
> + fn new(dev: &device::Device<T::Driver>, size: usize) -> Result<Self>;
> +
> + /// Open a new handle to an existing object, associated with a File.
> + fn open(
> + _obj: &<<T as IntoGEMObject>::Driver as drv::Driver>::Object,
> + _file: &file::File<<<T as IntoGEMObject>::Driver as drv::Driver>::File>,
> + ) -> Result {
> + Ok(())
> + }
> +
> + /// Close a handle to an existing object, associated with a File.
> + fn close(
> + _obj: &<<T as IntoGEMObject>::Driver as drv::Driver>::Object,
> + _file: &file::File<<<T as IntoGEMObject>::Driver as drv::Driver>::File>,
> + ) {
> + }
> +}
> +
> +/// Trait that represents a GEM object subtype
> +pub trait IntoGEMObject: Sized + crate::private::Sealed {
> + /// Owning driver for this type
> + type Driver: drv::Driver;
> +
> + /// Returns a pointer to the raw `drm_gem_object` structure, which must be valid as long as
> + /// this owning object is valid.
> + fn gem_obj(&self) -> *mut bindings::drm_gem_object;
> +
> + /// Returns a reference to the raw `drm_gem_object` structure, which must be valid as long as
> + /// this owning object is valid.
> + fn gem_ref(&self) -> &bindings::drm_gem_object {
> + // SAFETY: gem_obj() must be valid per the above requirement.
> + unsafe { &*self.gem_obj() }
> + }
> +
> + /// Converts a pointer to a `drm_gem_object` into a pointer to this type.
> + fn from_gem_obj(obj: *mut bindings::drm_gem_object) -> *mut Self;
> +}
> +
> +/// Trait which must be implemented by drivers using base GEM objects.
> +pub trait DriverObject: BaseDriverObject<Object<Self>> {
> + /// Parent `Driver` for this object.
> + type Driver: drv::Driver;
> +}
> +
> +unsafe extern "C" fn free_callback<T: DriverObject>(obj: *mut bindings::drm_gem_object) {
> + // SAFETY: All of our objects are Object<T>.
> + let this = crate::container_of!(obj, Object<T>, obj) as *mut Object<T>;
> +
> + // SAFETY: The pointer we got has to be valid
> + unsafe { bindings::drm_gem_object_release(obj) };
> +
> + // SAFETY: All of our objects are allocated via Box<>, and we're in the
> + // free callback which guarantees this object has zero remaining references,
> + // so we can drop it
> + unsafe { Box::from_raw(this) };
> +}
> +
> +unsafe extern "C" fn open_callback<T: BaseDriverObject<U>, U: BaseObject>(
> + raw_obj: *mut bindings::drm_gem_object,
> + raw_file: *mut bindings::drm_file,
> +) -> core::ffi::c_int {
> + // SAFETY: The pointer we got has to be valid.
> + let file = unsafe {
> + file::File::<<<U as IntoGEMObject>::Driver as drv::Driver>::File>::from_raw(raw_file)
> + };
> + let obj =
> + <<<U as IntoGEMObject>::Driver as drv::Driver>::Object as IntoGEMObject>::from_gem_obj(
> + raw_obj,
> + );
> +
> + // SAFETY: from_gem_obj() returns a valid pointer as long as the type is
> + // correct and the raw_obj we got is valid.
> + match T::open(unsafe { &*obj }, &file) {
> + Err(e) => e.to_kernel_errno(),
> + Ok(()) => 0,
> + }
> +}
> +
> +unsafe extern "C" fn close_callback<T: BaseDriverObject<U>, U: BaseObject>(
> + raw_obj: *mut bindings::drm_gem_object,
> + raw_file: *mut bindings::drm_file,
> +) {
> + // SAFETY: The pointer we got has to be valid.
> + let file = unsafe {
> + file::File::<<<U as IntoGEMObject>::Driver as drv::Driver>::File>::from_raw(raw_file)
> + };
> + let obj =
> + <<<U as IntoGEMObject>::Driver as drv::Driver>::Object as IntoGEMObject>::from_gem_obj(
> + raw_obj,
> + );
> +
> + // SAFETY: from_gem_obj() returns a valid pointer as long as the type is
> + // correct and the raw_obj we got is valid.
> + T::close(unsafe { &*obj }, &file);
> +}
> +
> +impl<T: DriverObject> IntoGEMObject for Object<T> {
> + type Driver = T::Driver;
> +
> + fn gem_obj(&self) -> *mut bindings::drm_gem_object {
> + &self.obj as *const _ as *mut _
> + }
> +
> + fn from_gem_obj(obj: *mut bindings::drm_gem_object) -> *mut Object<T> {
> + crate::container_of!(obj, Object<T>, obj) as *mut Object<T>
> + }
> +}
> +
> +/// Base operations shared by all GEM object classes
> +pub trait BaseObject: IntoGEMObject {
> + /// Returns the size of the object in bytes.
> + fn size(&self) -> usize {
> + self.gem_ref().size
> + }
> +
> + /// Creates a new reference to the object.
> + fn reference(&self) -> ObjectRef<Self> {
> + // SAFETY: Having a reference to an Object implies holding a GEM reference
> + unsafe {
> + bindings::drm_gem_object_get(self.gem_obj());
> + }
> + ObjectRef {
> + ptr: self as *const _,
> + }
> + }
> +
> + /// Creates a new handle for the object associated with a given `File`
> + /// (or returns an existing one).
> + fn create_handle(
> + &self,
> + file: &file::File<<<Self as IntoGEMObject>::Driver as drv::Driver>::File>,
> + ) -> Result<u32> {
> + let mut handle: u32 = 0;
> + // SAFETY: The arguments are all valid per the type invariants.
> + to_result(unsafe {
> + bindings::drm_gem_handle_create(file.raw() as *mut _, self.gem_obj(), &mut handle)
> + })?;
> + Ok(handle)
> + }
> +
> + /// Looks up an object by its handle for a given `File`.
> + fn lookup_handle(
> + file: &file::File<<<Self as IntoGEMObject>::Driver as drv::Driver>::File>,
> + handle: u32,
> + ) -> Result<ObjectRef<Self>> {
> + // SAFETY: The arguments are all valid per the type invariants.
> + let ptr = unsafe { bindings::drm_gem_object_lookup(file.raw() as *mut _, handle) };
> +
> + if ptr.is_null() {
> + Err(ENOENT)
> + } else {
> + Ok(ObjectRef {
> + ptr: ptr as *const _,
> + })
> + }
> + }
> +
> + /// Creates an mmap offset to map the object from userspace.
> + fn create_mmap_offset(&self) -> Result<u64> {
> + // SAFETY: The arguments are valid per the type invariant.
> + to_result(unsafe {
> + // TODO: is this threadsafe?
> + bindings::drm_gem_create_mmap_offset(self.gem_obj())
> + })?;
> + Ok(unsafe {
> + bindings::drm_vma_node_offset_addr(&self.gem_ref().vma_node as *const _ as *mut _)
> + })
> + }
> +}
> +
> +impl<T: IntoGEMObject> BaseObject for T {}
> +
> +/// A base GEM object.
> +#[repr(C)]
> +pub struct Object<T: DriverObject> {
> + obj: bindings::drm_gem_object,
> + // The DRM core ensures the Device exists as long as its objects exist, so we don't need to
> + // manage the reference count here.
> + dev: ManuallyDrop<device::Device<T::Driver>>,
> + inner: T,
> +}
> +
> +impl<T: DriverObject> Object<T> {
> + /// The size of this object's structure.
> + pub const SIZE: usize = mem::size_of::<Self>();
> +
> + const OBJECT_FUNCS: bindings::drm_gem_object_funcs = bindings::drm_gem_object_funcs {
> + free: Some(free_callback::<T>),
> + open: Some(open_callback::<T, Object<T>>),
> + close: Some(close_callback::<T, Object<T>>),
> + print_info: None,
> + export: None,
> + pin: None,
> + unpin: None,
> + get_sg_table: None,
> + vmap: None,
> + vunmap: None,
> + mmap: None,
> + vm_ops: core::ptr::null_mut(),
> + };
> +
> + /// Create a new GEM object.
> + pub fn new(dev: &device::Device<T::Driver>, size: usize) -> Result<UniqueObjectRef<Self>> {
> + let mut obj: Box<Self> = Box::try_new(Self {
> + // SAFETY: This struct is expected to be zero-initialized
> + obj: unsafe { mem::zeroed() },
> + // SAFETY: The drm subsystem guarantees that the drm_device will live as long as
> + // the GEM object lives, so we can conjure a reference out of thin air.
> + dev: ManuallyDrop::new(unsafe { device::Device::from_raw(dev.ptr) }),
> + inner: T::new(dev, size)?,
> + })?;
> +
> + obj.obj.funcs = &Self::OBJECT_FUNCS;
> + to_result(unsafe {
> + bindings::drm_gem_object_init(dev.raw() as *mut _, &mut obj.obj, size)
> + })?;
> +
> + let obj_ref = UniqueObjectRef {
> + ptr: Box::leak(obj),
> + };
> +
> + Ok(obj_ref)
> + }
> +
> + /// Returns the `Device` that owns this GEM object.
> + pub fn dev(&self) -> &device::Device<T::Driver> {
> + &self.dev
> + }
> +}
> +
> +impl<T: DriverObject> crate::private::Sealed for Object<T> {}
> +
> +impl<T: DriverObject> Deref for Object<T> {
> + type Target = T;
> +
> + fn deref(&self) -> &Self::Target {
> + &self.inner
> + }
> +}
> +
> +impl<T: DriverObject> DerefMut for Object<T> {
> + fn deref_mut(&mut self) -> &mut Self::Target {
> + &mut self.inner
> + }
> +}
> +
> +impl<T: DriverObject> drv::AllocImpl for Object<T> {
> + const ALLOC_OPS: drv::AllocOps = drv::AllocOps {
> + gem_create_object: None,
> + prime_handle_to_fd: Some(bindings::drm_gem_prime_handle_to_fd),
> + prime_fd_to_handle: Some(bindings::drm_gem_prime_fd_to_handle),
> + gem_prime_import: None,
> + gem_prime_import_sg_table: None,
> + gem_prime_mmap: Some(bindings::drm_gem_prime_mmap),
> + dumb_create: None,
> + dumb_map_offset: None,
> + dumb_destroy: None,
> + };
> +}
> +
> +/// A reference-counted shared reference to a base GEM object.
> +pub struct ObjectRef<T: IntoGEMObject> {
> + // Invariant: the pointer is valid and initialized, and this ObjectRef owns a reference to it.
> + ptr: *const T,
> +}
> +
> +/// SAFETY: GEM object references are safe to share between threads.
> +unsafe impl<T: IntoGEMObject> Send for ObjectRef<T> {}
> +unsafe impl<T: IntoGEMObject> Sync for ObjectRef<T> {}
> +
> +impl<T: IntoGEMObject> Clone for ObjectRef<T> {
> + fn clone(&self) -> Self {
> + self.reference()
> + }
> +}
> +
> +impl<T: IntoGEMObject> Drop for ObjectRef<T> {
> + fn drop(&mut self) {
> + // SAFETY: Having an ObjectRef implies holding a GEM reference.
> + // The free callback will take care of deallocation.
> + unsafe {
> + bindings::drm_gem_object_put((*self.ptr).gem_obj());
> + }
> + }
> +}
> +
> +impl<T: IntoGEMObject> Deref for ObjectRef<T> {
> + type Target = T;
> +
> + fn deref(&self) -> &Self::Target {
> + // SAFETY: The pointer is valid per the invariant
> + unsafe { &*self.ptr }
> + }
> +}
> +
> +/// A unique reference to a base GEM object.
> +pub struct UniqueObjectRef<T: IntoGEMObject> {
> + // Invariant: the pointer is valid and initialized, and this ObjectRef owns the only reference
> + // to it.
> + ptr: *mut T,
> +}
> +
> +impl<T: IntoGEMObject> UniqueObjectRef<T> {
> + /// Downgrade this reference to a shared reference.
> + pub fn into_ref(self) -> ObjectRef<T> {
> + let ptr = self.ptr as *const _;
> + core::mem::forget(self);
> +
> + ObjectRef { ptr }
> + }
> +}
> +
> +impl<T: IntoGEMObject> Drop for UniqueObjectRef<T> {
> + fn drop(&mut self) {
> + // SAFETY: Having a UniqueObjectRef implies holding a GEM
> + // reference. The free callback will take care of deallocation.
> + unsafe {
> + bindings::drm_gem_object_put((*self.ptr).gem_obj());
> + }
> + }
> +}
> +
> +impl<T: IntoGEMObject> Deref for UniqueObjectRef<T> {
> + type Target = T;
> +
> + fn deref(&self) -> &Self::Target {
> + // SAFETY: The pointer is valid per the invariant
> + unsafe { &*self.ptr }
> + }
> +}
> +
> +impl<T: IntoGEMObject> DerefMut for UniqueObjectRef<T> {
> + fn deref_mut(&mut self) -> &mut Self::Target {
> + // SAFETY: The pointer is valid per the invariant
> + unsafe { &mut *self.ptr }
> + }
> +}
> +
> +pub(super) fn create_fops() -> bindings::file_operations {
> + bindings::file_operations {
> + owner: core::ptr::null_mut(),
> + open: Some(bindings::drm_open),
> + release: Some(bindings::drm_release),
> + unlocked_ioctl: Some(bindings::drm_ioctl),
> + #[cfg(CONFIG_COMPAT)]
> + compat_ioctl: Some(bindings::drm_compat_ioctl),
> + #[cfg(not(CONFIG_COMPAT))]
> + compat_ioctl: None,
> + poll: Some(bindings::drm_poll),
> + read: Some(bindings::drm_read),
> + llseek: Some(bindings::noop_llseek),
> + mmap: Some(bindings::drm_gem_mmap),
> + ..Default::default()
> + }
> +}
> diff --git a/rust/kernel/drm/mod.rs b/rust/kernel/drm/mod.rs
> index a767942d0b52..c44760a1332f 100644
> --- a/rust/kernel/drm/mod.rs
> +++ b/rust/kernel/drm/mod.rs
> @@ -5,4 +5,5 @@
> pub mod device;
> pub mod drv;
> pub mod file;
> +pub mod gem;
> pub mod ioctl;
>
> --
> 2.35.1
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
^ permalink raw reply [flat|nested] 122+ messages in thread* Re: [PATCH RFC 04/18] rust: drm: gem: Add GEM object abstraction
2023-04-05 11:08 ` Daniel Vetter
@ 2023-04-05 11:19 ` Miguel Ojeda
2023-04-05 11:22 ` Daniel Vetter
0 siblings, 1 reply; 122+ messages in thread
From: Miguel Ojeda @ 2023-04-05 11:19 UTC (permalink / raw)
To: Asahi Lina, Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
David Airlie, Miguel Ojeda, Alex Gaynor, Wedson Almeida Filho,
Boqun Feng, Gary Guo, Björn Roy Baron, Sumit Semwal,
Christian König, Luben Tuikov, Jarkko Sakkinen, Dave Hansen,
Alyssa Rosenzweig, Karol Herbst, Ella Stanforth, Faith Ekstrand,
Mary, linux-kernel, dri-devel, rust-for-linux, linux-media,
linaro-mm-sig, linux-sgx, asahi
Cc: Daniel Vetter
On Wed, Apr 5, 2023 at 1:08 PM Daniel Vetter <daniel@ffwll.ch> wrote:
>
> Uh all the rust helper wrappers for all the kernel in a single file does
> not sound good. Can we not split these up into each subsystem, and then
> maybe instead of sprinkling #ifdef all over a .c file Make the compilation
> of that file conditional on rust support (plus whatever other Kconfig gate
> the other c files has already)?
Indeed, the plan is splitting the `kernel` crate and giving each
subsystem its own crate, bindings, helpers, etc.
Cheers,
Miguel
^ permalink raw reply [flat|nested] 122+ messages in thread
* Re: [PATCH RFC 04/18] rust: drm: gem: Add GEM object abstraction
2023-04-05 11:19 ` Miguel Ojeda
@ 2023-04-05 11:22 ` Daniel Vetter
2023-04-05 12:32 ` Miguel Ojeda
0 siblings, 1 reply; 122+ messages in thread
From: Daniel Vetter @ 2023-04-05 11:22 UTC (permalink / raw)
To: Miguel Ojeda
Cc: Asahi Lina, Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
David Airlie, Miguel Ojeda, Alex Gaynor, Wedson Almeida Filho,
Boqun Feng, Gary Guo, Björn Roy Baron, Sumit Semwal,
Christian König, Luben Tuikov, Jarkko Sakkinen, Dave Hansen,
Alyssa Rosenzweig, Karol Herbst, Ella Stanforth, Faith Ekstrand,
Mary, linux-kernel, dri-devel, rust-for-linux, linux-media,
linaro-mm-sig, linux-sgx, asahi, Daniel Vetter
On Wed, Apr 05, 2023 at 01:19:47PM +0200, Miguel Ojeda wrote:
> On Wed, Apr 5, 2023 at 1:08 PM Daniel Vetter <daniel@ffwll.ch> wrote:
> >
> > Uh all the rust helper wrappers for all the kernel in a single file does
> > not sound good. Can we not split these up into each subsystem, and then
> > maybe instead of sprinkling #ifdef all over a .c file Make the compilation
> > of that file conditional on rust support (plus whatever other Kconfig gate
> > the other c files has already)?
>
> Indeed, the plan is splitting the `kernel` crate and giving each
> subsystem its own crate, bindings, helpers, etc.
Ok if this is just interim I think it's fine. Would still be good to have
the MAINTAINERS entry though even just to cover the interim state. Least
because I'm assuming that when things are split up you'd still want to
keep the rust list on cc for the rust parts, even when they move into
subsystems?
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
^ permalink raw reply [flat|nested] 122+ messages in thread
* Re: [PATCH RFC 04/18] rust: drm: gem: Add GEM object abstraction
2023-04-05 11:22 ` Daniel Vetter
@ 2023-04-05 12:32 ` Miguel Ojeda
2023-04-05 12:36 ` Daniel Vetter
0 siblings, 1 reply; 122+ messages in thread
From: Miguel Ojeda @ 2023-04-05 12:32 UTC (permalink / raw)
To: Miguel Ojeda, Asahi Lina, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Miguel Ojeda, Alex Gaynor,
Wedson Almeida Filho, Boqun Feng, Gary Guo, Björn Roy Baron,
Sumit Semwal, Christian König, Luben Tuikov,
Jarkko Sakkinen, Dave Hansen, Alyssa Rosenzweig, Karol Herbst,
Ella Stanforth, Faith Ekstrand, Mary, linux-kernel, dri-devel,
rust-for-linux, linux-media, linaro-mm-sig, linux-sgx, asahi
Cc: Daniel Vetter
On Wed, Apr 5, 2023 at 1:23 PM Daniel Vetter <daniel@ffwll.ch> wrote:
>
> Ok if this is just interim I think it's fine. Would still be good to have
> the MAINTAINERS entry though even just to cover the interim state. Least
> because I'm assuming that when things are split up you'd still want to
> keep the rust list on cc for the rust parts, even when they move into
> subsystems?
Sorry, I missed to reply the second part of your email -- replying here.
Currently, the subsystem's code is under `rust/` (though modules can
go already into other folders). One of the reasons was technical
simplicity, and a nice side effect is that we could bootstrap things
while getting C maintainers involved over time.
To accomplish that, the guidelines for contributing Rust code are that
the respective maintainers need to be at least Cc'd, even if the files
do not hit the `F:` fields for the time being -- see [1]. But, for us,
ideally, the maintainers will take the changes through their tree,
instead of going through the Rust one, since that is the end goal.
And, of course, if you already want to have `F:` fields for the Rust
code, that is even better! (Whether those should be in the same entry
or in a new one, it is up to you, of course, and whether it is a
different set of people / level of support / etc.)
Then, when the `kernel` crate split happens, we can move the code
directly under whatever folders it should be naturally, when their
maintainers are ready. For some subsystems, that may mean they do not
need any `F:` fields since they are already covered (e.g. if they did
not create a new entry for Rust code only). And for cases like yours,
where you already had `F:` fields, it means the move of the files can
be done right away as soon as the split happens.
In short, we would definitely welcome if you add `F:` fields already
(whether in existing or new entries) -- it would mean you are ahead of
the curve! :)
As for the mailing list, yes, for the time being, I ask that all
changes to please be sent to the Rust list, so that everybody that
wants to follow the Rust progress has everything in a single place, so
that we try to remain consistent in the beginning on e.g. coding
guidelines, so that Rust reviewers can help spot mistakes, and so on
and so forth.
But, as Rust grows in the kernel, as systems become non-experimental,
and as maintainers take ownership of the code, that should eventually
go away and let things be as usual with C code. Then the Rust
subsystem (and its list) will become smaller, and it will be the
subsystem (and the discussion place) for anything not covered by other
subsystems, such as core Rust abstractions and types, Rust
infrastructure and so on.
How does that sound?
[1] https://rust-for-linux.com/contributing#the-rust-subsystem (I may
reorganize this to be Rust's `P:` field, by the way)
Cheers,
Miguel
^ permalink raw reply [flat|nested] 122+ messages in thread
* Re: [PATCH RFC 04/18] rust: drm: gem: Add GEM object abstraction
2023-04-05 12:32 ` Miguel Ojeda
@ 2023-04-05 12:36 ` Daniel Vetter
0 siblings, 0 replies; 122+ messages in thread
From: Daniel Vetter @ 2023-04-05 12:36 UTC (permalink / raw)
To: Miguel Ojeda
Cc: Asahi Lina, Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
David Airlie, Miguel Ojeda, Alex Gaynor, Wedson Almeida Filho,
Boqun Feng, Gary Guo, Björn Roy Baron, Sumit Semwal,
Christian König, Luben Tuikov, Jarkko Sakkinen, Dave Hansen,
Alyssa Rosenzweig, Karol Herbst, Ella Stanforth, Faith Ekstrand,
Mary, linux-kernel, dri-devel, rust-for-linux, linux-media,
linaro-mm-sig, linux-sgx, asahi, Daniel Vetter
On Wed, Apr 05, 2023 at 02:32:12PM +0200, Miguel Ojeda wrote:
> On Wed, Apr 5, 2023 at 1:23 PM Daniel Vetter <daniel@ffwll.ch> wrote:
> >
> > Ok if this is just interim I think it's fine. Would still be good to have
> > the MAINTAINERS entry though even just to cover the interim state. Least
> > because I'm assuming that when things are split up you'd still want to
> > keep the rust list on cc for the rust parts, even when they move into
> > subsystems?
>
> Sorry, I missed to reply the second part of your email -- replying here.
>
> Currently, the subsystem's code is under `rust/` (though modules can
> go already into other folders). One of the reasons was technical
> simplicity, and a nice side effect is that we could bootstrap things
> while getting C maintainers involved over time.
>
> To accomplish that, the guidelines for contributing Rust code are that
> the respective maintainers need to be at least Cc'd, even if the files
> do not hit the `F:` fields for the time being -- see [1]. But, for us,
> ideally, the maintainers will take the changes through their tree,
> instead of going through the Rust one, since that is the end goal.
>
> And, of course, if you already want to have `F:` fields for the Rust
> code, that is even better! (Whether those should be in the same entry
> or in a new one, it is up to you, of course, and whether it is a
> different set of people / level of support / etc.)
>
> Then, when the `kernel` crate split happens, we can move the code
> directly under whatever folders it should be naturally, when their
> maintainers are ready. For some subsystems, that may mean they do not
> need any `F:` fields since they are already covered (e.g. if they did
> not create a new entry for Rust code only). And for cases like yours,
> where you already had `F:` fields, it means the move of the files can
> be done right away as soon as the split happens.
>
> In short, we would definitely welcome if you add `F:` fields already
> (whether in existing or new entries) -- it would mean you are ahead of
> the curve! :)
>
> As for the mailing list, yes, for the time being, I ask that all
> changes to please be sent to the Rust list, so that everybody that
> wants to follow the Rust progress has everything in a single place, so
> that we try to remain consistent in the beginning on e.g. coding
> guidelines, so that Rust reviewers can help spot mistakes, and so on
> and so forth.
>
> But, as Rust grows in the kernel, as systems become non-experimental,
> and as maintainers take ownership of the code, that should eventually
> go away and let things be as usual with C code. Then the Rust
> subsystem (and its list) will become smaller, and it will be the
> subsystem (and the discussion place) for anything not covered by other
> subsystems, such as core Rust abstractions and types, Rust
> infrastructure and so on.
>
> How does that sound?
Yeah sounds all great!
I think interim at least a separate rust drm entry
would be good, to make sure we always cc both rust and dri-devel. Once
it's too much for you and you generally trust the dri-devel folks to not
design stupid interfaces, we can then drop that and only ping rust folks
when needed. I do expect that's some years out though.
-Daniel
>
> [1] https://rust-for-linux.com/contributing#the-rust-subsystem (I may
> reorganize this to be Rust's `P:` field, by the way)
>
> Cheers,
> Miguel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
^ permalink raw reply [flat|nested] 122+ messages in thread
* [PATCH RFC 05/18] drm/gem-shmem: Export VM ops functions
2023-03-07 14:25 [PATCH RFC 00/18] Rust DRM subsystem abstractions (& preview AGX driver) Asahi Lina
` (3 preceding siblings ...)
2023-03-07 14:25 ` [PATCH RFC 04/18] rust: drm: gem: Add GEM object abstraction Asahi Lina
@ 2023-03-07 14:25 ` Asahi Lina
2023-03-07 14:25 ` [PATCH RFC 06/18] rust: drm: gem: shmem: Add DRM shmem helper abstraction Asahi Lina
` (13 subsequent siblings)
18 siblings, 0 replies; 122+ messages in thread
From: Asahi Lina @ 2023-03-07 14:25 UTC (permalink / raw)
To: Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
David Airlie, Daniel Vetter, Miguel Ojeda, Alex Gaynor,
Wedson Almeida Filho, Boqun Feng, Gary Guo, Björn Roy Baron,
Sumit Semwal, Christian König, Luben Tuikov,
Jarkko Sakkinen, Dave Hansen
Cc: Alyssa Rosenzweig, Karol Herbst, Ella Stanforth, Faith Ekstrand,
Mary, linux-kernel, dri-devel, rust-for-linux, linux-media,
linaro-mm-sig, linux-sgx, asahi, Asahi Lina
There doesn't seem to be a way for the Rust bindings to get a
compile-time constant reference to drm_gem_shmem_vm_ops, so we need to
duplicate that structure in Rust... this isn't nice...
Signed-off-by: Asahi Lina <lina@asahilina.net>
---
drivers/gpu/drm/drm_gem_shmem_helper.c | 9 ++++++---
include/drm/drm_gem_shmem_helper.h | 3 +++
2 files changed, 9 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/drm_gem_shmem_helper.c b/drivers/gpu/drm/drm_gem_shmem_helper.c
index 75185a960fc4..10c09819410e 100644
--- a/drivers/gpu/drm/drm_gem_shmem_helper.c
+++ b/drivers/gpu/drm/drm_gem_shmem_helper.c
@@ -534,7 +534,7 @@ int drm_gem_shmem_dumb_create(struct drm_file *file, struct drm_device *dev,
}
EXPORT_SYMBOL_GPL(drm_gem_shmem_dumb_create);
-static vm_fault_t drm_gem_shmem_fault(struct vm_fault *vmf)
+vm_fault_t drm_gem_shmem_fault(struct vm_fault *vmf)
{
struct vm_area_struct *vma = vmf->vma;
struct drm_gem_object *obj = vma->vm_private_data;
@@ -563,8 +563,9 @@ static vm_fault_t drm_gem_shmem_fault(struct vm_fault *vmf)
return ret;
}
+EXPORT_SYMBOL_GPL(drm_gem_shmem_fault);
-static void drm_gem_shmem_vm_open(struct vm_area_struct *vma)
+void drm_gem_shmem_vm_open(struct vm_area_struct *vma)
{
struct drm_gem_object *obj = vma->vm_private_data;
struct drm_gem_shmem_object *shmem = to_drm_gem_shmem_obj(obj);
@@ -585,8 +586,9 @@ static void drm_gem_shmem_vm_open(struct vm_area_struct *vma)
drm_gem_vm_open(vma);
}
+EXPORT_SYMBOL_GPL(drm_gem_shmem_vm_open);
-static void drm_gem_shmem_vm_close(struct vm_area_struct *vma)
+void drm_gem_shmem_vm_close(struct vm_area_struct *vma)
{
struct drm_gem_object *obj = vma->vm_private_data;
struct drm_gem_shmem_object *shmem = to_drm_gem_shmem_obj(obj);
@@ -594,6 +596,7 @@ static void drm_gem_shmem_vm_close(struct vm_area_struct *vma)
drm_gem_shmem_put_pages(shmem);
drm_gem_vm_close(vma);
}
+EXPORT_SYMBOL_GPL(drm_gem_shmem_vm_close);
const struct vm_operations_struct drm_gem_shmem_vm_ops = {
.fault = drm_gem_shmem_fault,
diff --git a/include/drm/drm_gem_shmem_helper.h b/include/drm/drm_gem_shmem_helper.h
index a2201b2488c5..b9f349b3ed76 100644
--- a/include/drm/drm_gem_shmem_helper.h
+++ b/include/drm/drm_gem_shmem_helper.h
@@ -138,6 +138,9 @@ void drm_gem_shmem_print_info(const struct drm_gem_shmem_object *shmem,
struct drm_printer *p, unsigned int indent);
extern const struct vm_operations_struct drm_gem_shmem_vm_ops;
+vm_fault_t drm_gem_shmem_fault(struct vm_fault *vmf);
+void drm_gem_shmem_vm_open(struct vm_area_struct *vma);
+void drm_gem_shmem_vm_close(struct vm_area_struct *vma);
/*
* GEM object functions
--
2.35.1
^ permalink raw reply related [flat|nested] 122+ messages in thread* [PATCH RFC 06/18] rust: drm: gem: shmem: Add DRM shmem helper abstraction
2023-03-07 14:25 [PATCH RFC 00/18] Rust DRM subsystem abstractions (& preview AGX driver) Asahi Lina
` (4 preceding siblings ...)
2023-03-07 14:25 ` [PATCH RFC 05/18] drm/gem-shmem: Export VM ops functions Asahi Lina
@ 2023-03-07 14:25 ` Asahi Lina
2023-03-08 13:38 ` Maíra Canal
2023-03-07 14:25 ` [PATCH RFC 07/18] rust: drm: mm: Add DRM MM Range Allocator abstraction Asahi Lina
` (12 subsequent siblings)
18 siblings, 1 reply; 122+ messages in thread
From: Asahi Lina @ 2023-03-07 14:25 UTC (permalink / raw)
To: Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
David Airlie, Daniel Vetter, Miguel Ojeda, Alex Gaynor,
Wedson Almeida Filho, Boqun Feng, Gary Guo, Björn Roy Baron,
Sumit Semwal, Christian König, Luben Tuikov,
Jarkko Sakkinen, Dave Hansen
Cc: Alyssa Rosenzweig, Karol Herbst, Ella Stanforth, Faith Ekstrand,
Mary, linux-kernel, dri-devel, rust-for-linux, linux-media,
linaro-mm-sig, linux-sgx, asahi, Asahi Lina
The DRM shmem helper includes common code useful for drivers which
allocate GEM objects as anonymous shmem. Add a Rust abstraction for
this. Drivers can choose the raw GEM implementation or the shmem layer,
depending on their needs.
Signed-off-by: Asahi Lina <lina@asahilina.net>
---
drivers/gpu/drm/Kconfig | 5 +
rust/bindings/bindings_helper.h | 2 +
rust/helpers.c | 67 +++++++
rust/kernel/drm/gem/mod.rs | 3 +
rust/kernel/drm/gem/shmem.rs | 381 ++++++++++++++++++++++++++++++++++++++++
5 files changed, 458 insertions(+)
diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index dab8f0f9aa96..70a983a17ac2 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -34,6 +34,11 @@ config RUST_DRM
bool "Rust support for the DRM subsystem"
depends on DRM=y
+config RUST_DRM_GEM_SHMEM_HELPER
+ bool
+ depends on RUST_DRM
+ select DRM_GEM_SHMEM_HELPER
+
config DRM_MIPI_DBI
tristate
depends on DRM
diff --git a/rust/bindings/bindings_helper.h b/rust/bindings/bindings_helper.h
index 7183dfe6473f..9f152d373df8 100644
--- a/rust/bindings/bindings_helper.h
+++ b/rust/bindings/bindings_helper.h
@@ -10,6 +10,7 @@
#include <drm/drm_drv.h>
#include <drm/drm_file.h>
#include <drm/drm_gem.h>
+#include <drm/drm_gem_shmem_helper.h>
#include <drm/drm_ioctl.h>
#include <linux/delay.h>
#include <linux/device.h>
@@ -17,6 +18,7 @@
#include <linux/fs.h>
#include <linux/ioctl.h>
#include <linux/io-pgtable.h>
+#include <linux/iosys-map.h>
#include <linux/ktime.h>
#include <linux/of.h>
#include <linux/of_address.h>
diff --git a/rust/helpers.c b/rust/helpers.c
index 78ec4162b03b..388ff1100ea5 100644
--- a/rust/helpers.c
+++ b/rust/helpers.c
@@ -19,6 +19,7 @@
*/
#include <drm/drm_gem.h>
+#include <drm/drm_gem_shmem_helper.h>
#include <linux/bug.h>
#include <linux/build_bug.h>
#include <linux/device.h>
@@ -375,6 +376,18 @@ void rust_helper_init_completion(struct completion *c)
}
EXPORT_SYMBOL_GPL(rust_helper_init_completion);
+dma_addr_t rust_helper_sg_dma_address(const struct scatterlist *sg)
+{
+ return sg_dma_address(sg);
+}
+EXPORT_SYMBOL_GPL(rust_helper_sg_dma_address);
+
+int rust_helper_sg_dma_len(const struct scatterlist *sg)
+{
+ return sg_dma_len(sg);
+}
+EXPORT_SYMBOL_GPL(rust_helper_sg_dma_len);
+
#ifdef CONFIG_DRM
void rust_helper_drm_gem_object_get(struct drm_gem_object *obj)
@@ -395,6 +408,60 @@ __u64 rust_helper_drm_vma_node_offset_addr(struct drm_vma_offset_node *node)
}
EXPORT_SYMBOL_GPL(rust_helper_drm_vma_node_offset_addr);
+#ifdef CONFIG_DRM_GEM_SHMEM_HELPER
+
+void rust_helper_drm_gem_shmem_object_free(struct drm_gem_object *obj)
+{
+ return drm_gem_shmem_object_free(obj);
+}
+EXPORT_SYMBOL_GPL(rust_helper_drm_gem_shmem_object_free);
+
+void rust_helper_drm_gem_shmem_object_print_info(struct drm_printer *p, unsigned int indent,
+ const struct drm_gem_object *obj)
+{
+ drm_gem_shmem_object_print_info(p, indent, obj);
+}
+EXPORT_SYMBOL_GPL(rust_helper_drm_gem_shmem_object_print_info);
+
+int rust_helper_drm_gem_shmem_object_pin(struct drm_gem_object *obj)
+{
+ return drm_gem_shmem_object_pin(obj);
+}
+EXPORT_SYMBOL_GPL(rust_helper_drm_gem_shmem_object_pin);
+
+void rust_helper_drm_gem_shmem_object_unpin(struct drm_gem_object *obj)
+{
+ drm_gem_shmem_object_unpin(obj);
+}
+EXPORT_SYMBOL_GPL(rust_helper_drm_gem_shmem_object_unpin);
+
+struct sg_table *rust_helper_drm_gem_shmem_object_get_sg_table(struct drm_gem_object *obj)
+{
+ return drm_gem_shmem_object_get_sg_table(obj);
+}
+EXPORT_SYMBOL_GPL(rust_helper_drm_gem_shmem_object_get_sg_table);
+
+int rust_helper_drm_gem_shmem_object_vmap(struct drm_gem_object *obj,
+ struct iosys_map *map)
+{
+ return drm_gem_shmem_object_vmap(obj, map);
+}
+EXPORT_SYMBOL_GPL(rust_helper_drm_gem_shmem_object_vmap);
+
+void rust_helper_drm_gem_shmem_object_vunmap(struct drm_gem_object *obj,
+ struct iosys_map *map)
+{
+ drm_gem_shmem_object_vunmap(obj, map);
+}
+EXPORT_SYMBOL_GPL(rust_helper_drm_gem_shmem_object_vunmap);
+
+int rust_helper_drm_gem_shmem_object_mmap(struct drm_gem_object *obj, struct vm_area_struct *vma)
+{
+ return drm_gem_shmem_object_mmap(obj, vma);
+}
+EXPORT_SYMBOL_GPL(rust_helper_drm_gem_shmem_object_mmap);
+
+#endif
#endif
/*
diff --git a/rust/kernel/drm/gem/mod.rs b/rust/kernel/drm/gem/mod.rs
index 8a7d99613718..e66bdef35c2e 100644
--- a/rust/kernel/drm/gem/mod.rs
+++ b/rust/kernel/drm/gem/mod.rs
@@ -4,6 +4,9 @@
//!
//! C header: [`include/linux/drm/drm_gem.h`](../../../../include/linux/drm/drm_gem.h)
+#[cfg(CONFIG_RUST_DRM_GEM_SHMEM_HELPER)]
+pub mod shmem;
+
use alloc::boxed::Box;
use crate::{
diff --git a/rust/kernel/drm/gem/shmem.rs b/rust/kernel/drm/gem/shmem.rs
new file mode 100644
index 000000000000..15446ea1113e
--- /dev/null
+++ b/rust/kernel/drm/gem/shmem.rs
@@ -0,0 +1,381 @@
+// SPDX-License-Identifier: GPL-2.0
+
+//! DRM GEM shmem helper objects
+//!
+//! C header: [`include/linux/drm/drm_gem_shmem_helper.h`](../../../../include/linux/drm/drm_gem_shmem_helper.h)
+
+use crate::drm::{device, drv, gem};
+use crate::{
+ error::{from_kernel_err_ptr, to_result},
+ prelude::*,
+};
+use core::{
+ marker::PhantomData,
+ mem,
+ mem::{ManuallyDrop, MaybeUninit},
+ ops::{Deref, DerefMut},
+ ptr::addr_of_mut,
+ slice,
+};
+
+use gem::BaseObject;
+
+/// Trait which must be implemented by drivers using shmem-backed GEM objects.
+pub trait DriverObject: gem::BaseDriverObject<Object<Self>> {
+ /// Parent `Driver` for this object.
+ type Driver: drv::Driver;
+}
+
+// FIXME: This is terrible and I don't know how to avoid it
+#[cfg(CONFIG_NUMA)]
+macro_rules! vm_numa_fields {
+ ( $($field:ident: $val:expr),* $(,)? ) => {
+ bindings::vm_operations_struct {
+ $( $field: $val ),*,
+ set_policy: None,
+ get_policy: None,
+ }
+ }
+}
+
+#[cfg(not(CONFIG_NUMA))]
+macro_rules! vm_numa_fields {
+ ( $($field:ident: $val:expr),* $(,)? ) => {
+ bindings::vm_operations_struct {
+ $( $field: $val ),*
+ }
+ }
+}
+
+const SHMEM_VM_OPS: bindings::vm_operations_struct = vm_numa_fields! {
+ open: Some(bindings::drm_gem_shmem_vm_open),
+ close: Some(bindings::drm_gem_shmem_vm_close),
+ may_split: None,
+ mremap: None,
+ mprotect: None,
+ fault: Some(bindings::drm_gem_shmem_fault),
+ huge_fault: None,
+ map_pages: None,
+ pagesize: None,
+ page_mkwrite: None,
+ pfn_mkwrite: None,
+ access: None,
+ name: None,
+ find_special_page: None,
+};
+
+/// A shmem-backed GEM object.
+#[repr(C)]
+pub struct Object<T: DriverObject> {
+ obj: bindings::drm_gem_shmem_object,
+ // The DRM core ensures the Device exists as long as its objects exist, so we don't need to
+ // manage the reference count here.
+ dev: ManuallyDrop<device::Device<T::Driver>>,
+ inner: T,
+}
+
+unsafe extern "C" fn gem_create_object<T: DriverObject>(
+ raw_dev: *mut bindings::drm_device,
+ size: usize,
+) -> *mut bindings::drm_gem_object {
+ // SAFETY: GEM ensures the device lives as long as its objects live,
+ // so we can conjure up a reference from thin air and never drop it.
+ let dev = ManuallyDrop::new(unsafe { device::Device::from_raw(raw_dev) });
+
+ let inner = match T::new(&*dev, size) {
+ Ok(v) => v,
+ Err(e) => return e.to_ptr(),
+ };
+
+ let p = unsafe {
+ bindings::krealloc(
+ core::ptr::null(),
+ Object::<T>::SIZE,
+ bindings::GFP_KERNEL | bindings::__GFP_ZERO,
+ ) as *mut Object<T>
+ };
+
+ if p.is_null() {
+ return ENOMEM.to_ptr();
+ }
+
+ // SAFETY: p is valid as long as the alloc succeeded
+ unsafe {
+ addr_of_mut!((*p).dev).write(dev);
+ addr_of_mut!((*p).inner).write(inner);
+ }
+
+ // SAFETY: drm_gem_shmem_object is safe to zero-init, and
+ // the rest of Object has been initialized
+ let new: &mut Object<T> = unsafe { &mut *(p as *mut _) };
+
+ new.obj.base.funcs = &Object::<T>::VTABLE;
+ &mut new.obj.base
+}
+
+unsafe extern "C" fn free_callback<T: DriverObject>(obj: *mut bindings::drm_gem_object) {
+ // SAFETY: All of our objects are Object<T>.
+ let p = crate::container_of!(obj, Object<T>, obj) as *mut Object<T>;
+
+ // SAFETY: p is never used after this
+ unsafe {
+ core::ptr::drop_in_place(&mut (*p).inner);
+ }
+
+ // SAFETY: This pointer has to be valid, since p is valid
+ unsafe {
+ bindings::drm_gem_shmem_free(&mut (*p).obj);
+ }
+}
+
+impl<T: DriverObject> Object<T> {
+ /// The size of this object's structure.
+ const SIZE: usize = mem::size_of::<Self>();
+
+ /// `drm_gem_object_funcs` vtable suitable for GEM shmem objects.
+ const VTABLE: bindings::drm_gem_object_funcs = bindings::drm_gem_object_funcs {
+ free: Some(free_callback::<T>),
+ open: Some(super::open_callback::<T, Object<T>>),
+ close: Some(super::close_callback::<T, Object<T>>),
+ print_info: Some(bindings::drm_gem_shmem_object_print_info),
+ export: None,
+ pin: Some(bindings::drm_gem_shmem_object_pin),
+ unpin: Some(bindings::drm_gem_shmem_object_unpin),
+ get_sg_table: Some(bindings::drm_gem_shmem_object_get_sg_table),
+ vmap: Some(bindings::drm_gem_shmem_object_vmap),
+ vunmap: Some(bindings::drm_gem_shmem_object_vunmap),
+ mmap: Some(bindings::drm_gem_shmem_object_mmap),
+ vm_ops: &SHMEM_VM_OPS,
+ };
+
+ // SAFETY: Must only be used with DRM functions that are thread-safe
+ unsafe fn mut_shmem(&self) -> *mut bindings::drm_gem_shmem_object {
+ &self.obj as *const _ as *mut _
+ }
+
+ /// Create a new shmem-backed DRM object of the given size.
+ pub fn new(dev: &device::Device<T::Driver>, size: usize) -> Result<gem::UniqueObjectRef<Self>> {
+ // SAFETY: This function can be called as long as the ALLOC_OPS are set properly
+ // for this driver, and the gem_create_object is called.
+ let p = unsafe { bindings::drm_gem_shmem_create(dev.raw() as *mut _, size) };
+ let p = crate::container_of!(p, Object<T>, obj) as *mut _;
+
+ // SAFETY: The gem_create_object callback ensures this is a valid Object<T>,
+ // so we can take a unique reference to it.
+ let obj_ref = gem::UniqueObjectRef { ptr: p };
+
+ Ok(obj_ref)
+ }
+
+ /// Returns the `Device` that owns this GEM object.
+ pub fn dev(&self) -> &device::Device<T::Driver> {
+ &self.dev
+ }
+
+ /// Creates (if necessary) and returns a scatter-gather table of DMA pages for this object.
+ ///
+ /// This will pin the object in memory.
+ pub fn sg_table(&self) -> Result<SGTable<T>> {
+ // SAFETY: drm_gem_shmem_get_pages_sgt is thread-safe.
+ let sgt = from_kernel_err_ptr(unsafe {
+ bindings::drm_gem_shmem_get_pages_sgt(self.mut_shmem())
+ })?;
+
+ Ok(SGTable {
+ sgt,
+ _owner: self.reference(),
+ })
+ }
+
+ /// Creates and returns a virtual kernel memory mapping for this object.
+ pub fn vmap(&self) -> Result<VMap<T>> {
+ let mut map: MaybeUninit<bindings::iosys_map> = MaybeUninit::uninit();
+
+ // SAFETY: drm_gem_shmem_vmap is thread-safe
+ to_result(unsafe { bindings::drm_gem_shmem_vmap(self.mut_shmem(), map.as_mut_ptr()) })?;
+
+ // SAFETY: if drm_gem_shmem_vmap did not fail, map is initialized now
+ let map = unsafe { map.assume_init() };
+
+ Ok(VMap {
+ map,
+ owner: self.reference(),
+ })
+ }
+
+ /// Set the write-combine flag for this object.
+ ///
+ /// Should be called before any mappings are made.
+ pub fn set_wc(&mut self, map_wc: bool) {
+ unsafe { (*self.mut_shmem()).map_wc = map_wc };
+ }
+}
+
+impl<T: DriverObject> Deref for Object<T> {
+ type Target = T;
+
+ fn deref(&self) -> &Self::Target {
+ &self.inner
+ }
+}
+
+impl<T: DriverObject> DerefMut for Object<T> {
+ fn deref_mut(&mut self) -> &mut Self::Target {
+ &mut self.inner
+ }
+}
+
+impl<T: DriverObject> crate::private::Sealed for Object<T> {}
+
+impl<T: DriverObject> gem::IntoGEMObject for Object<T> {
+ type Driver = T::Driver;
+
+ fn gem_obj(&self) -> *mut bindings::drm_gem_object {
+ &self.obj.base as *const _ as *mut _
+ }
+
+ fn from_gem_obj(obj: *mut bindings::drm_gem_object) -> *mut Object<T> {
+ crate::container_of!(obj, Object<T>, obj) as *mut Object<T>
+ }
+}
+
+impl<T: DriverObject> drv::AllocImpl for Object<T> {
+ const ALLOC_OPS: drv::AllocOps = drv::AllocOps {
+ gem_create_object: Some(gem_create_object::<T>),
+ prime_handle_to_fd: Some(bindings::drm_gem_prime_handle_to_fd),
+ prime_fd_to_handle: Some(bindings::drm_gem_prime_fd_to_handle),
+ gem_prime_import: None,
+ gem_prime_import_sg_table: Some(bindings::drm_gem_shmem_prime_import_sg_table),
+ gem_prime_mmap: Some(bindings::drm_gem_prime_mmap),
+ dumb_create: Some(bindings::drm_gem_shmem_dumb_create),
+ dumb_map_offset: None,
+ dumb_destroy: None,
+ };
+}
+
+/// A virtual mapping for a shmem-backed GEM object in kernel address space.
+pub struct VMap<T: DriverObject> {
+ map: bindings::iosys_map,
+ owner: gem::ObjectRef<Object<T>>,
+}
+
+impl<T: DriverObject> VMap<T> {
+ /// Returns a const raw pointer to the start of the mapping.
+ pub fn as_ptr(&self) -> *const core::ffi::c_void {
+ // SAFETY: The shmem helpers always return non-iomem maps
+ unsafe { self.map.__bindgen_anon_1.vaddr }
+ }
+
+ /// Returns a mutable raw pointer to the start of the mapping.
+ pub fn as_mut_ptr(&mut self) -> *mut core::ffi::c_void {
+ // SAFETY: The shmem helpers always return non-iomem maps
+ unsafe { self.map.__bindgen_anon_1.vaddr }
+ }
+
+ /// Returns a byte slice view of the mapping.
+ pub fn as_slice(&self) -> &[u8] {
+ // SAFETY: The vmap maps valid memory up to the owner size
+ unsafe { slice::from_raw_parts(self.as_ptr() as *const u8, self.owner.size()) }
+ }
+
+ /// Returns mutable a byte slice view of the mapping.
+ pub fn as_mut_slice(&mut self) -> &mut [u8] {
+ // SAFETY: The vmap maps valid memory up to the owner size
+ unsafe { slice::from_raw_parts_mut(self.as_mut_ptr() as *mut u8, self.owner.size()) }
+ }
+
+ /// Borrows a reference to the object that owns this virtual mapping.
+ pub fn owner(&self) -> &gem::ObjectRef<Object<T>> {
+ &self.owner
+ }
+}
+
+impl<T: DriverObject> Drop for VMap<T> {
+ fn drop(&mut self) {
+ // SAFETY: This function is thread-safe
+ unsafe {
+ bindings::drm_gem_shmem_vunmap(self.owner.mut_shmem(), &mut self.map);
+ }
+ }
+}
+
+/// SAFETY: `iosys_map` objects are safe to send across threads.
+unsafe impl<T: DriverObject> Send for VMap<T> {}
+unsafe impl<T: DriverObject> Sync for VMap<T> {}
+
+/// A single scatter-gather entry, representing a span of pages in the device's DMA address space.
+///
+/// For devices not behind a standalone IOMMU, this corresponds to physical addresses.
+#[repr(transparent)]
+pub struct SGEntry(bindings::scatterlist);
+
+impl SGEntry {
+ /// Returns the starting DMA address of this span
+ pub fn dma_address(&self) -> usize {
+ (unsafe { bindings::sg_dma_address(&self.0) }) as usize
+ }
+
+ /// Returns the length of this span in bytes
+ pub fn dma_len(&self) -> usize {
+ (unsafe { bindings::sg_dma_len(&self.0) }) as usize
+ }
+}
+
+/// A scatter-gather table of DMA address spans for a GEM shmem object.
+///
+/// # Invariants
+/// `sgt` must be a valid pointer to the `sg_table`, which must correspond to the owned
+/// object in `_owner` (which ensures it remains valid).
+pub struct SGTable<T: DriverObject> {
+ sgt: *const bindings::sg_table,
+ _owner: gem::ObjectRef<Object<T>>,
+}
+
+impl<T: DriverObject> SGTable<T> {
+ /// Returns an iterator through the SGTable's entries
+ pub fn iter(&'_ self) -> SGTableIter<'_> {
+ SGTableIter {
+ left: unsafe { (*self.sgt).nents } as usize,
+ sg: unsafe { (*self.sgt).sgl },
+ _p: PhantomData,
+ }
+ }
+}
+
+impl<'a, T: DriverObject> IntoIterator for &'a SGTable<T> {
+ type Item = &'a SGEntry;
+ type IntoIter = SGTableIter<'a>;
+
+ fn into_iter(self) -> Self::IntoIter {
+ self.iter()
+ }
+}
+
+/// SAFETY: `sg_table` objects are safe to send across threads.
+unsafe impl<T: DriverObject> Send for SGTable<T> {}
+unsafe impl<T: DriverObject> Sync for SGTable<T> {}
+
+/// An iterator through `SGTable` entries.
+///
+/// # Invariants
+/// `sg` must be a valid pointer to the scatterlist, which must outlive our lifetime.
+pub struct SGTableIter<'a> {
+ sg: *mut bindings::scatterlist,
+ left: usize,
+ _p: PhantomData<&'a ()>,
+}
+
+impl<'a> Iterator for SGTableIter<'a> {
+ type Item = &'a SGEntry;
+
+ fn next(&mut self) -> Option<Self::Item> {
+ if self.left == 0 {
+ None
+ } else {
+ let sg = self.sg;
+ self.sg = unsafe { bindings::sg_next(self.sg) };
+ self.left -= 1;
+ Some(unsafe { &(*(sg as *const SGEntry)) })
+ }
+ }
+}
--
2.35.1
^ permalink raw reply related [flat|nested] 122+ messages in thread* Re: [PATCH RFC 06/18] rust: drm: gem: shmem: Add DRM shmem helper abstraction
2023-03-07 14:25 ` [PATCH RFC 06/18] rust: drm: gem: shmem: Add DRM shmem helper abstraction Asahi Lina
@ 2023-03-08 13:38 ` Maíra Canal
2023-03-09 5:25 ` Asahi Lina
0 siblings, 1 reply; 122+ messages in thread
From: Maíra Canal @ 2023-03-08 13:38 UTC (permalink / raw)
To: Asahi Lina, Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
David Airlie, Daniel Vetter, Miguel Ojeda, Alex Gaynor,
Wedson Almeida Filho, Boqun Feng, Gary Guo, Björn Roy Baron,
Sumit Semwal, Christian König, Luben Tuikov,
Jarkko Sakkinen, Dave Hansen
Cc: linaro-mm-sig, rust-for-linux, Karol Herbst, asahi, linux-kernel,
dri-devel, Mary, Alyssa Rosenzweig, linux-sgx, Ella Stanforth,
Faith Ekstrand, linux-media
On 3/7/23 11:25, Asahi Lina wrote:
> The DRM shmem helper includes common code useful for drivers which
> allocate GEM objects as anonymous shmem. Add a Rust abstraction for
> this. Drivers can choose the raw GEM implementation or the shmem layer,
> depending on their needs.
>
> Signed-off-by: Asahi Lina <lina@asahilina.net>
> ---
> drivers/gpu/drm/Kconfig | 5 +
> rust/bindings/bindings_helper.h | 2 +
> rust/helpers.c | 67 +++++++
> rust/kernel/drm/gem/mod.rs | 3 +
> rust/kernel/drm/gem/shmem.rs | 381 ++++++++++++++++++++++++++++++++++++++++
> 5 files changed, 458 insertions(+)
>
[...]
> +unsafe extern "C" fn gem_create_object<T: DriverObject>(
> + raw_dev: *mut bindings::drm_device,
> + size: usize,
> +) -> *mut bindings::drm_gem_object {
> + // SAFETY: GEM ensures the device lives as long as its objects live,
> + // so we can conjure up a reference from thin air and never drop it.
> + let dev = ManuallyDrop::new(unsafe { device::Device::from_raw(raw_dev) });
> +
> + let inner = match T::new(&*dev, size) {
> + Ok(v) => v,
> + Err(e) => return e.to_ptr(),
> + };
> +
> + let p = unsafe {
> + bindings::krealloc(
> + core::ptr::null(),
> + Object::<T>::SIZE,
> + bindings::GFP_KERNEL | bindings::__GFP_ZERO,
> + ) as *mut Object<T>
> + };
> +
> + if p.is_null() {
> + return ENOMEM.to_ptr();
> + }
> +
> + // SAFETY: p is valid as long as the alloc succeeded
> + unsafe {
> + addr_of_mut!((*p).dev).write(dev);
> + addr_of_mut!((*p).inner).write(inner);
> + }
> +
> + // SAFETY: drm_gem_shmem_object is safe to zero-init, and
> + // the rest of Object has been initialized
> + let new: &mut Object<T> = unsafe { &mut *(p as *mut _) };
> +
> + new.obj.base.funcs = &Object::<T>::VTABLE;
> + &mut new.obj.base
> +}
It would be nice to allow to set wc inside the gem_create_object callback,
as some drivers do it so, like v3d, vc4, panfrost, lima...
Best Regards,
- Maíra Canal
> +
> +unsafe extern "C" fn free_callback<T: DriverObject>(obj: *mut bindings::drm_gem_object) {
> + // SAFETY: All of our objects are Object<T>.
> + let p = crate::container_of!(obj, Object<T>, obj) as *mut Object<T>;
> +
> + // SAFETY: p is never used after this
> + unsafe {
> + core::ptr::drop_in_place(&mut (*p).inner);
> + }
> +
> + // SAFETY: This pointer has to be valid, since p is valid
> + unsafe {
> + bindings::drm_gem_shmem_free(&mut (*p).obj);
> + }
> +}
> +
> +impl<T: DriverObject> Object<T> {
> + /// The size of this object's structure.
> + const SIZE: usize = mem::size_of::<Self>();
> +
> + /// `drm_gem_object_funcs` vtable suitable for GEM shmem objects.
> + const VTABLE: bindings::drm_gem_object_funcs = bindings::drm_gem_object_funcs {
> + free: Some(free_callback::<T>),
> + open: Some(super::open_callback::<T, Object<T>>),
> + close: Some(super::close_callback::<T, Object<T>>),
> + print_info: Some(bindings::drm_gem_shmem_object_print_info),
> + export: None,
> + pin: Some(bindings::drm_gem_shmem_object_pin),
> + unpin: Some(bindings::drm_gem_shmem_object_unpin),
> + get_sg_table: Some(bindings::drm_gem_shmem_object_get_sg_table),
> + vmap: Some(bindings::drm_gem_shmem_object_vmap),
> + vunmap: Some(bindings::drm_gem_shmem_object_vunmap),
> + mmap: Some(bindings::drm_gem_shmem_object_mmap),
> + vm_ops: &SHMEM_VM_OPS,
> + };
> +
> + // SAFETY: Must only be used with DRM functions that are thread-safe
> + unsafe fn mut_shmem(&self) -> *mut bindings::drm_gem_shmem_object {
> + &self.obj as *const _ as *mut _
> + }
> +
> + /// Create a new shmem-backed DRM object of the given size.
> + pub fn new(dev: &device::Device<T::Driver>, size: usize) -> Result<gem::UniqueObjectRef<Self>> {
> + // SAFETY: This function can be called as long as the ALLOC_OPS are set properly
> + // for this driver, and the gem_create_object is called.
> + let p = unsafe { bindings::drm_gem_shmem_create(dev.raw() as *mut _, size) };
> + let p = crate::container_of!(p, Object<T>, obj) as *mut _;
> +
> + // SAFETY: The gem_create_object callback ensures this is a valid Object<T>,
> + // so we can take a unique reference to it.
> + let obj_ref = gem::UniqueObjectRef { ptr: p };
> +
> + Ok(obj_ref)
> + }
> +
> + /// Returns the `Device` that owns this GEM object.
> + pub fn dev(&self) -> &device::Device<T::Driver> {
> + &self.dev
> + }
> +
> + /// Creates (if necessary) and returns a scatter-gather table of DMA pages for this object.
> + ///
> + /// This will pin the object in memory.
> + pub fn sg_table(&self) -> Result<SGTable<T>> {
> + // SAFETY: drm_gem_shmem_get_pages_sgt is thread-safe.
> + let sgt = from_kernel_err_ptr(unsafe {
> + bindings::drm_gem_shmem_get_pages_sgt(self.mut_shmem())
> + })?;
> +
> + Ok(SGTable {
> + sgt,
> + _owner: self.reference(),
> + })
> + }
> +
> + /// Creates and returns a virtual kernel memory mapping for this object.
> + pub fn vmap(&self) -> Result<VMap<T>> {
> + let mut map: MaybeUninit<bindings::iosys_map> = MaybeUninit::uninit();
> +
> + // SAFETY: drm_gem_shmem_vmap is thread-safe
> + to_result(unsafe { bindings::drm_gem_shmem_vmap(self.mut_shmem(), map.as_mut_ptr()) })?;
> +
> + // SAFETY: if drm_gem_shmem_vmap did not fail, map is initialized now
> + let map = unsafe { map.assume_init() };
> +
> + Ok(VMap {
> + map,
> + owner: self.reference(),
> + })
> + }
> +
> + /// Set the write-combine flag for this object.
> + ///
> + /// Should be called before any mappings are made.
> + pub fn set_wc(&mut self, map_wc: bool) {
> + unsafe { (*self.mut_shmem()).map_wc = map_wc };
> + }
> +}
> +
> +impl<T: DriverObject> Deref for Object<T> {
> + type Target = T;
> +
> + fn deref(&self) -> &Self::Target {
> + &self.inner
> + }
> +}
> +
> +impl<T: DriverObject> DerefMut for Object<T> {
> + fn deref_mut(&mut self) -> &mut Self::Target {
> + &mut self.inner
> + }
> +}
> +
> +impl<T: DriverObject> crate::private::Sealed for Object<T> {}
> +
> +impl<T: DriverObject> gem::IntoGEMObject for Object<T> {
> + type Driver = T::Driver;
> +
> + fn gem_obj(&self) -> *mut bindings::drm_gem_object {
> + &self.obj.base as *const _ as *mut _
> + }
> +
> + fn from_gem_obj(obj: *mut bindings::drm_gem_object) -> *mut Object<T> {
> + crate::container_of!(obj, Object<T>, obj) as *mut Object<T>
> + }
> +}
> +
> +impl<T: DriverObject> drv::AllocImpl for Object<T> {
> + const ALLOC_OPS: drv::AllocOps = drv::AllocOps {
> + gem_create_object: Some(gem_create_object::<T>),
> + prime_handle_to_fd: Some(bindings::drm_gem_prime_handle_to_fd),
> + prime_fd_to_handle: Some(bindings::drm_gem_prime_fd_to_handle),
> + gem_prime_import: None,
> + gem_prime_import_sg_table: Some(bindings::drm_gem_shmem_prime_import_sg_table),
> + gem_prime_mmap: Some(bindings::drm_gem_prime_mmap),
> + dumb_create: Some(bindings::drm_gem_shmem_dumb_create),
> + dumb_map_offset: None,
> + dumb_destroy: None,
> + };
> +}
> +
> +/// A virtual mapping for a shmem-backed GEM object in kernel address space.
> +pub struct VMap<T: DriverObject> {
> + map: bindings::iosys_map,
> + owner: gem::ObjectRef<Object<T>>,
> +}
> +
> +impl<T: DriverObject> VMap<T> {
> + /// Returns a const raw pointer to the start of the mapping.
> + pub fn as_ptr(&self) -> *const core::ffi::c_void {
> + // SAFETY: The shmem helpers always return non-iomem maps
> + unsafe { self.map.__bindgen_anon_1.vaddr }
> + }
> +
> + /// Returns a mutable raw pointer to the start of the mapping.
> + pub fn as_mut_ptr(&mut self) -> *mut core::ffi::c_void {
> + // SAFETY: The shmem helpers always return non-iomem maps
> + unsafe { self.map.__bindgen_anon_1.vaddr }
> + }
> +
> + /// Returns a byte slice view of the mapping.
> + pub fn as_slice(&self) -> &[u8] {
> + // SAFETY: The vmap maps valid memory up to the owner size
> + unsafe { slice::from_raw_parts(self.as_ptr() as *const u8, self.owner.size()) }
> + }
> +
> + /// Returns mutable a byte slice view of the mapping.
> + pub fn as_mut_slice(&mut self) -> &mut [u8] {
> + // SAFETY: The vmap maps valid memory up to the owner size
> + unsafe { slice::from_raw_parts_mut(self.as_mut_ptr() as *mut u8, self.owner.size()) }
> + }
> +
> + /// Borrows a reference to the object that owns this virtual mapping.
> + pub fn owner(&self) -> &gem::ObjectRef<Object<T>> {
> + &self.owner
> + }
> +}
> +
> +impl<T: DriverObject> Drop for VMap<T> {
> + fn drop(&mut self) {
> + // SAFETY: This function is thread-safe
> + unsafe {
> + bindings::drm_gem_shmem_vunmap(self.owner.mut_shmem(), &mut self.map);
> + }
> + }
> +}
> +
> +/// SAFETY: `iosys_map` objects are safe to send across threads.
> +unsafe impl<T: DriverObject> Send for VMap<T> {}
> +unsafe impl<T: DriverObject> Sync for VMap<T> {}
> +
> +/// A single scatter-gather entry, representing a span of pages in the device's DMA address space.
> +///
> +/// For devices not behind a standalone IOMMU, this corresponds to physical addresses.
> +#[repr(transparent)]
> +pub struct SGEntry(bindings::scatterlist);
> +
> +impl SGEntry {
> + /// Returns the starting DMA address of this span
> + pub fn dma_address(&self) -> usize {
> + (unsafe { bindings::sg_dma_address(&self.0) }) as usize
> + }
> +
> + /// Returns the length of this span in bytes
> + pub fn dma_len(&self) -> usize {
> + (unsafe { bindings::sg_dma_len(&self.0) }) as usize
> + }
> +}
> +
> +/// A scatter-gather table of DMA address spans for a GEM shmem object.
> +///
> +/// # Invariants
> +/// `sgt` must be a valid pointer to the `sg_table`, which must correspond to the owned
> +/// object in `_owner` (which ensures it remains valid).
> +pub struct SGTable<T: DriverObject> {
> + sgt: *const bindings::sg_table,
> + _owner: gem::ObjectRef<Object<T>>,
> +}
> +
> +impl<T: DriverObject> SGTable<T> {
> + /// Returns an iterator through the SGTable's entries
> + pub fn iter(&'_ self) -> SGTableIter<'_> {
> + SGTableIter {
> + left: unsafe { (*self.sgt).nents } as usize,
> + sg: unsafe { (*self.sgt).sgl },
> + _p: PhantomData,
> + }
> + }
> +}
> +
> +impl<'a, T: DriverObject> IntoIterator for &'a SGTable<T> {
> + type Item = &'a SGEntry;
> + type IntoIter = SGTableIter<'a>;
> +
> + fn into_iter(self) -> Self::IntoIter {
> + self.iter()
> + }
> +}
> +
> +/// SAFETY: `sg_table` objects are safe to send across threads.
> +unsafe impl<T: DriverObject> Send for SGTable<T> {}
> +unsafe impl<T: DriverObject> Sync for SGTable<T> {}
> +
> +/// An iterator through `SGTable` entries.
> +///
> +/// # Invariants
> +/// `sg` must be a valid pointer to the scatterlist, which must outlive our lifetime.
> +pub struct SGTableIter<'a> {
> + sg: *mut bindings::scatterlist,
> + left: usize,
> + _p: PhantomData<&'a ()>,
> +}
> +
> +impl<'a> Iterator for SGTableIter<'a> {
> + type Item = &'a SGEntry;
> +
> + fn next(&mut self) -> Option<Self::Item> {
> + if self.left == 0 {
> + None
> + } else {
> + let sg = self.sg;
> + self.sg = unsafe { bindings::sg_next(self.sg) };
> + self.left -= 1;
> + Some(unsafe { &(*(sg as *const SGEntry)) })
> + }
> + }
> +}
>
^ permalink raw reply [flat|nested] 122+ messages in thread* Re: [PATCH RFC 06/18] rust: drm: gem: shmem: Add DRM shmem helper abstraction
2023-03-08 13:38 ` Maíra Canal
@ 2023-03-09 5:25 ` Asahi Lina
2023-03-09 11:47 ` Maíra Canal
0 siblings, 1 reply; 122+ messages in thread
From: Asahi Lina @ 2023-03-09 5:25 UTC (permalink / raw)
To: Maíra Canal, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Daniel Vetter, Miguel Ojeda,
Alex Gaynor, Wedson Almeida Filho, Boqun Feng, Gary Guo,
Björn Roy Baron, Sumit Semwal, Christian König,
Luben Tuikov, Jarkko Sakkinen, Dave Hansen
Cc: linaro-mm-sig, rust-for-linux, Karol Herbst, asahi, linux-kernel,
dri-devel, Mary, Alyssa Rosenzweig, linux-sgx, Ella Stanforth,
Faith Ekstrand, linux-media
On 08/03/2023 22.38, Maíra Canal wrote:
> On 3/7/23 11:25, Asahi Lina wrote:
>> The DRM shmem helper includes common code useful for drivers which
>> allocate GEM objects as anonymous shmem. Add a Rust abstraction for
>> this. Drivers can choose the raw GEM implementation or the shmem layer,
>> depending on their needs.
>>
>> Signed-off-by: Asahi Lina <lina@asahilina.net>
>> ---
>> drivers/gpu/drm/Kconfig | 5 +
>> rust/bindings/bindings_helper.h | 2 +
>> rust/helpers.c | 67 +++++++
>> rust/kernel/drm/gem/mod.rs | 3 +
>> rust/kernel/drm/gem/shmem.rs | 381 ++++++++++++++++++++++++++++++++++++++++
>> 5 files changed, 458 insertions(+)
>>
>
> [...]
>
>> +unsafe extern "C" fn gem_create_object<T: DriverObject>(
>> + raw_dev: *mut bindings::drm_device,
>> + size: usize,
>> +) -> *mut bindings::drm_gem_object {
>> + // SAFETY: GEM ensures the device lives as long as its objects live,
>> + // so we can conjure up a reference from thin air and never drop it.
>> + let dev = ManuallyDrop::new(unsafe { device::Device::from_raw(raw_dev) });
>> +
>> + let inner = match T::new(&*dev, size) {
>> + Ok(v) => v,
>> + Err(e) => return e.to_ptr(),
>> + };
>> +
>> + let p = unsafe {
>> + bindings::krealloc(
>> + core::ptr::null(),
>> + Object::<T>::SIZE,
>> + bindings::GFP_KERNEL | bindings::__GFP_ZERO,
>> + ) as *mut Object<T>
>> + };
>> +
>> + if p.is_null() {
>> + return ENOMEM.to_ptr();
>> + }
>> +
>> + // SAFETY: p is valid as long as the alloc succeeded
>> + unsafe {
>> + addr_of_mut!((*p).dev).write(dev);
>> + addr_of_mut!((*p).inner).write(inner);
>> + }
>> +
>> + // SAFETY: drm_gem_shmem_object is safe to zero-init, and
>> + // the rest of Object has been initialized
>> + let new: &mut Object<T> = unsafe { &mut *(p as *mut _) };
>> +
>> + new.obj.base.funcs = &Object::<T>::VTABLE;
>> + &mut new.obj.base
>> +}
>
> It would be nice to allow to set wc inside the gem_create_object callback,
> as some drivers do it so, like v3d, vc4, panfrost, lima...
This is actually a bit tricky to do safely, because we can't just have a
callback that takes the drm_gem_shmem_object instance inside
gem_create_object because it is not fully initialized yet from the point
of view of the gem shmem API. Maybe we could have some sort of temporary
proxy object that only lets you do safe things like set map_wc? Or maybe
the new() callback could return something like a ShmemTemplate<T> type
that contains both the inner data and some miscellaneous fields like the
initial map_wc state?
I think we can also just wait until the first user before we do this
though... the goal of the abstractions is to support the APIs we
actually use. I know you need this for vgem, so please feel free to
implement it as a separate patch! I think it's best if you get credit
for the abstraction changes you need, so we can all work together on the
design so it works for everyone's use cases instead of just having me
make all the decisions ^^ (and it's fine if we have to refactor the APIs!)
~~ Lina
^ permalink raw reply [flat|nested] 122+ messages in thread* Re: [PATCH RFC 06/18] rust: drm: gem: shmem: Add DRM shmem helper abstraction
2023-03-09 5:25 ` Asahi Lina
@ 2023-03-09 11:47 ` Maíra Canal
2023-03-09 14:16 ` Asahi Lina
0 siblings, 1 reply; 122+ messages in thread
From: Maíra Canal @ 2023-03-09 11:47 UTC (permalink / raw)
To: Asahi Lina, Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
David Airlie, Daniel Vetter, Miguel Ojeda, Alex Gaynor,
Wedson Almeida Filho, Boqun Feng, Gary Guo, Björn Roy Baron,
Sumit Semwal, Christian König, Luben Tuikov,
Jarkko Sakkinen, Dave Hansen
Cc: linaro-mm-sig, rust-for-linux, Karol Herbst, asahi, linux-kernel,
dri-devel, Mary, Alyssa Rosenzweig, linux-sgx, Ella Stanforth,
Faith Ekstrand, linux-media
On 3/9/23 02:25, Asahi Lina wrote:
> On 08/03/2023 22.38, Maíra Canal wrote:
>> On 3/7/23 11:25, Asahi Lina wrote:
>>> The DRM shmem helper includes common code useful for drivers which
>>> allocate GEM objects as anonymous shmem. Add a Rust abstraction for
>>> this. Drivers can choose the raw GEM implementation or the shmem layer,
>>> depending on their needs.
>>>
>>> Signed-off-by: Asahi Lina <lina@asahilina.net>
>>> ---
>>> drivers/gpu/drm/Kconfig | 5 +
>>> rust/bindings/bindings_helper.h | 2 +
>>> rust/helpers.c | 67 +++++++
>>> rust/kernel/drm/gem/mod.rs | 3 +
>>> rust/kernel/drm/gem/shmem.rs | 381 ++++++++++++++++++++++++++++++++++++++++
>>> 5 files changed, 458 insertions(+)
>>>
>>
>> [...]
>>
>>> +unsafe extern "C" fn gem_create_object<T: DriverObject>(
>>> + raw_dev: *mut bindings::drm_device,
>>> + size: usize,
>>> +) -> *mut bindings::drm_gem_object {
>>> + // SAFETY: GEM ensures the device lives as long as its objects live,
>>> + // so we can conjure up a reference from thin air and never drop it.
>>> + let dev = ManuallyDrop::new(unsafe { device::Device::from_raw(raw_dev) });
>>> +
>>> + let inner = match T::new(&*dev, size) {
>>> + Ok(v) => v,
>>> + Err(e) => return e.to_ptr(),
>>> + };
>>> +
>>> + let p = unsafe {
>>> + bindings::krealloc(
>>> + core::ptr::null(),
>>> + Object::<T>::SIZE,
>>> + bindings::GFP_KERNEL | bindings::__GFP_ZERO,
>>> + ) as *mut Object<T>
>>> + };
>>> +
>>> + if p.is_null() {
>>> + return ENOMEM.to_ptr();
>>> + }
>>> +
>>> + // SAFETY: p is valid as long as the alloc succeeded
>>> + unsafe {
>>> + addr_of_mut!((*p).dev).write(dev);
>>> + addr_of_mut!((*p).inner).write(inner);
>>> + }
>>> +
>>> + // SAFETY: drm_gem_shmem_object is safe to zero-init, and
>>> + // the rest of Object has been initialized
>>> + let new: &mut Object<T> = unsafe { &mut *(p as *mut _) };
>>> +
>>> + new.obj.base.funcs = &Object::<T>::VTABLE;
>>> + &mut new.obj.base
>>> +}
>>
>> It would be nice to allow to set wc inside the gem_create_object callback,
>> as some drivers do it so, like v3d, vc4, panfrost, lima...
>
> This is actually a bit tricky to do safely, because we can't just have a
> callback that takes the drm_gem_shmem_object instance inside
> gem_create_object because it is not fully initialized yet from the point
> of view of the gem shmem API. Maybe we could have some sort of temporary
> proxy object that only lets you do safe things like set map_wc? Or maybe
> the new() callback could return something like a ShmemTemplate<T> type
> that contains both the inner data and some miscellaneous fields like the
> initial map_wc state?
I see that most drivers use this hook to set map_wc and set funcs. What
are your thoughts on something like this?
Best Regards,
- Maíra Canal
From 61f23f4a39028c9d34d3df58d7640bfcd64e9af9 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Ma=C3=ADra=20Canal?= <mcanal@igalia.com>
Date: Thu, 9 Mar 2023 08:24:09 -0300
Subject: [PATCH] rust: drm: gem: shmem: Set map_wc on gem_create_object
callback
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Some drivers use the gem_create_object callback to define the mapping of
the object write-combined (map_wc). Currently, the DRM Rust abstractions
doesn't allow such operation. So, add a method to the DriverObject trait
to allow drivers to set map_wc on the gem_create_object callback. By
default, the method returns false, which is the shmem default value.
Signed-off-by: Maíra Canal <mcanal@igalia.com>
---
rust/kernel/drm/gem/shmem.rs | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/rust/kernel/drm/gem/shmem.rs b/rust/kernel/drm/gem/shmem.rs
index 8f17eba0be99..a7f33b66f60a 100644
--- a/rust/kernel/drm/gem/shmem.rs
+++ b/rust/kernel/drm/gem/shmem.rs
@@ -24,6 +24,11 @@ use gem::BaseObject;
pub trait DriverObject: gem::BaseDriverObject<Object<Self>> {
/// Parent `Driver` for this object.
type Driver: drv::Driver;
+
+ /// Define the map object write-combined
+ fn set_wc() -> bool {
+ false
+ }
}
// FIXME: This is terrible and I don't know how to avoid it
@@ -110,6 +115,8 @@ unsafe extern "C" fn gem_create_object<T: DriverObject>(
let new: &mut Object<T> = unsafe { &mut *(p as *mut _) };
new.obj.base.funcs = &Object::<T>::VTABLE;
+ new.obj.map_wc = <T>::set_wc();
+
&mut new.obj.base
}
>
> I think we can also just wait until the first user before we do this
> though... the goal of the abstractions is to support the APIs we
> actually use. I know you need this for vgem, so please feel free to
> implement it as a separate patch! I think it's best if you get credit
> for the abstraction changes you need, so we can all work together on the
> design so it works for everyone's use cases instead of just having me
> make all the decisions ^^ (and it's fine if we have to refactor the APIs!)
>
> ~~ Lina
^ permalink raw reply related [flat|nested] 122+ messages in thread* Re: [PATCH RFC 06/18] rust: drm: gem: shmem: Add DRM shmem helper abstraction
2023-03-09 11:47 ` Maíra Canal
@ 2023-03-09 14:16 ` Asahi Lina
0 siblings, 0 replies; 122+ messages in thread
From: Asahi Lina @ 2023-03-09 14:16 UTC (permalink / raw)
To: Maíra Canal, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Daniel Vetter, Miguel Ojeda,
Alex Gaynor, Wedson Almeida Filho, Boqun Feng, Gary Guo,
Björn Roy Baron, Sumit Semwal, Christian König,
Luben Tuikov, Jarkko Sakkinen, Dave Hansen
Cc: linaro-mm-sig, rust-for-linux, Karol Herbst, asahi, linux-kernel,
dri-devel, Mary, Alyssa Rosenzweig, linux-sgx, Ella Stanforth,
Faith Ekstrand, linux-media
On 09/03/2023 20.47, Maíra Canal wrote:
> On 3/9/23 02:25, Asahi Lina wrote:
>> On 08/03/2023 22.38, Maíra Canal wrote:
>>> On 3/7/23 11:25, Asahi Lina wrote:
>>>> The DRM shmem helper includes common code useful for drivers which
>>>> allocate GEM objects as anonymous shmem. Add a Rust abstraction for
>>>> this. Drivers can choose the raw GEM implementation or the shmem layer,
>>>> depending on their needs.
>>>>
>>>> Signed-off-by: Asahi Lina <lina@asahilina.net>
>>>> ---
>>>> drivers/gpu/drm/Kconfig | 5 +
>>>> rust/bindings/bindings_helper.h | 2 +
>>>> rust/helpers.c | 67 +++++++
>>>> rust/kernel/drm/gem/mod.rs | 3 +
>>>> rust/kernel/drm/gem/shmem.rs | 381 ++++++++++++++++++++++++++++++++++++++++
>>>> 5 files changed, 458 insertions(+)
>>>>
>>>
>>> [...]
>>>
>>>> +unsafe extern "C" fn gem_create_object<T: DriverObject>(
>>>> + raw_dev: *mut bindings::drm_device,
>>>> + size: usize,
>>>> +) -> *mut bindings::drm_gem_object {
>>>> + // SAFETY: GEM ensures the device lives as long as its objects live,
>>>> + // so we can conjure up a reference from thin air and never drop it.
>>>> + let dev = ManuallyDrop::new(unsafe { device::Device::from_raw(raw_dev) });
>>>> +
>>>> + let inner = match T::new(&*dev, size) {
>>>> + Ok(v) => v,
>>>> + Err(e) => return e.to_ptr(),
>>>> + };
>>>> +
>>>> + let p = unsafe {
>>>> + bindings::krealloc(
>>>> + core::ptr::null(),
>>>> + Object::<T>::SIZE,
>>>> + bindings::GFP_KERNEL | bindings::__GFP_ZERO,
>>>> + ) as *mut Object<T>
>>>> + };
>>>> +
>>>> + if p.is_null() {
>>>> + return ENOMEM.to_ptr();
>>>> + }
>>>> +
>>>> + // SAFETY: p is valid as long as the alloc succeeded
>>>> + unsafe {
>>>> + addr_of_mut!((*p).dev).write(dev);
>>>> + addr_of_mut!((*p).inner).write(inner);
>>>> + }
>>>> +
>>>> + // SAFETY: drm_gem_shmem_object is safe to zero-init, and
>>>> + // the rest of Object has been initialized
>>>> + let new: &mut Object<T> = unsafe { &mut *(p as *mut _) };
>>>> +
>>>> + new.obj.base.funcs = &Object::<T>::VTABLE;
>>>> + &mut new.obj.base
>>>> +}
>>>
>>> It would be nice to allow to set wc inside the gem_create_object callback,
>>> as some drivers do it so, like v3d, vc4, panfrost, lima...
>>
>> This is actually a bit tricky to do safely, because we can't just have a
>> callback that takes the drm_gem_shmem_object instance inside
>> gem_create_object because it is not fully initialized yet from the point
>> of view of the gem shmem API. Maybe we could have some sort of temporary
>> proxy object that only lets you do safe things like set map_wc? Or maybe
>> the new() callback could return something like a ShmemTemplate<T> type
>> that contains both the inner data and some miscellaneous fields like the
>> initial map_wc state?
>
> I see that most drivers use this hook to set map_wc and set funcs. What
> are your thoughts on something like this?
>
> Best Regards,
> - Maíra Canal
>
> From 61f23f4a39028c9d34d3df58d7640bfcd64e9af9 Mon Sep 17 00:00:00 2001
> From: =?UTF-8?q?Ma=C3=ADra=20Canal?= <mcanal@igalia.com>
> Date: Thu, 9 Mar 2023 08:24:09 -0300
> Subject: [PATCH] rust: drm: gem: shmem: Set map_wc on gem_create_object
> callback
> MIME-Version: 1.0
> Content-Type: text/plain; charset=UTF-8
> Content-Transfer-Encoding: 8bit
>
> Some drivers use the gem_create_object callback to define the mapping of
> the object write-combined (map_wc). Currently, the DRM Rust abstractions
> doesn't allow such operation. So, add a method to the DriverObject trait
> to allow drivers to set map_wc on the gem_create_object callback. By
> default, the method returns false, which is the shmem default value.
>
> Signed-off-by: Maíra Canal <mcanal@igalia.com>
> ---
> rust/kernel/drm/gem/shmem.rs | 7 +++++++
> 1 file changed, 7 insertions(+)
>
> diff --git a/rust/kernel/drm/gem/shmem.rs b/rust/kernel/drm/gem/shmem.rs
> index 8f17eba0be99..a7f33b66f60a 100644
> --- a/rust/kernel/drm/gem/shmem.rs
> +++ b/rust/kernel/drm/gem/shmem.rs
> @@ -24,6 +24,11 @@ use gem::BaseObject;
> pub trait DriverObject: gem::BaseDriverObject<Object<Self>> {
> /// Parent `Driver` for this object.
> type Driver: drv::Driver;
> +
> + /// Define the map object write-combined
> + fn set_wc() -> bool {
> + false
> + }
> }
I think if you're going to make it a static function like that, we might
as well just make it an associated constant like `DEFAULT_WC`? After all
there is no information gem_create_object gets other than the size so we
can't really do anything more useful, and `set_wc()` can't do much other
than return a constant ^^
The only corner case I can think of is cases where the WC mode depends
on the device (for example, if some devices want to enable it or not
depending on whether the particular hardware variant is cache-coherent),
but then it should probably just be part of the return value for T::new
since that function already gets all available information (device and
size). But I think a constant works for now, we can always extend it
when a use case comes for doing more.
~~ Lina
^ permalink raw reply [flat|nested] 122+ messages in thread
* [PATCH RFC 07/18] rust: drm: mm: Add DRM MM Range Allocator abstraction
2023-03-07 14:25 [PATCH RFC 00/18] Rust DRM subsystem abstractions (& preview AGX driver) Asahi Lina
` (5 preceding siblings ...)
2023-03-07 14:25 ` [PATCH RFC 06/18] rust: drm: gem: shmem: Add DRM shmem helper abstraction Asahi Lina
@ 2023-03-07 14:25 ` Asahi Lina
2023-04-06 14:15 ` Daniel Vetter
2023-03-07 14:25 ` [PATCH RFC 08/18] rust: dma_fence: Add DMA Fence abstraction Asahi Lina
` (11 subsequent siblings)
18 siblings, 1 reply; 122+ messages in thread
From: Asahi Lina @ 2023-03-07 14:25 UTC (permalink / raw)
To: Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
David Airlie, Daniel Vetter, Miguel Ojeda, Alex Gaynor,
Wedson Almeida Filho, Boqun Feng, Gary Guo, Björn Roy Baron,
Sumit Semwal, Christian König, Luben Tuikov,
Jarkko Sakkinen, Dave Hansen
Cc: Alyssa Rosenzweig, Karol Herbst, Ella Stanforth, Faith Ekstrand,
Mary, linux-kernel, dri-devel, rust-for-linux, linux-media,
linaro-mm-sig, linux-sgx, asahi, Asahi Lina
drm_mm provides a simple range allocator, useful for managing virtual
address ranges. Add a Rust abstraction to expose this module to Rust
drivers.
Signed-off-by: Asahi Lina <lina@asahilina.net>
---
rust/kernel/drm/mm.rs | 309 +++++++++++++++++++++++++++++++++++++++++++++++++
rust/kernel/drm/mod.rs | 1 +
2 files changed, 310 insertions(+)
diff --git a/rust/kernel/drm/mm.rs b/rust/kernel/drm/mm.rs
new file mode 100644
index 000000000000..83e27a7dcc7e
--- /dev/null
+++ b/rust/kernel/drm/mm.rs
@@ -0,0 +1,309 @@
+// SPDX-License-Identifier: GPL-2.0 OR MIT
+
+//! DRM MM range allocator
+//!
+//! C header: [`include/linux/drm/drm_mm.h`](../../../../include/linux/drm/drm_mm.h)
+
+use crate::{
+ bindings,
+ error::{to_result, Result},
+ str::CStr,
+ sync::{Arc, LockClassKey, LockIniter, Mutex, UniqueArc},
+ types::Opaque,
+};
+
+use alloc::boxed::Box;
+
+use core::{
+ marker::{PhantomData, PhantomPinned},
+ ops::Deref,
+ pin::Pin,
+};
+
+/// Type alias representing a DRM MM node.
+pub type Node<A, T> = Pin<Box<NodeData<A, T>>>;
+
+/// Trait which must be implemented by the inner allocator state type provided by the user.
+pub trait AllocInner<T> {
+ /// Notification that a node was dropped from the allocator.
+ fn drop_object(&mut self, _start: u64, _size: u64, _color: usize, _object: &mut T) {}
+}
+
+impl<T> AllocInner<T> for () {}
+
+/// Wrapper type for a `struct drm_mm` plus user AllocInner object.
+///
+/// # Invariants
+/// The `drm_mm` struct is valid and initialized.
+struct MmInner<A: AllocInner<T>, T>(Opaque<bindings::drm_mm>, A, PhantomData<T>);
+
+/// Represents a single allocated node in the MM allocator
+pub struct NodeData<A: AllocInner<T>, T> {
+ node: bindings::drm_mm_node,
+ mm: Arc<Mutex<MmInner<A, T>>>,
+ valid: bool,
+ /// A drm_mm_node needs to be pinned because nodes reference each other in a linked list.
+ _pin: PhantomPinned,
+ inner: T,
+}
+
+// SAFETY: Allocator ops take the mutex, and there are no mutable actions on the node.
+unsafe impl<A: Send + AllocInner<T>, T: Send> Send for NodeData<A, T> {}
+unsafe impl<A: Send + AllocInner<T>, T: Sync> Sync for NodeData<A, T> {}
+
+/// Available MM node insertion modes
+#[repr(u32)]
+pub enum InsertMode {
+ /// Search for the smallest hole (within the search range) that fits the desired node.
+ ///
+ /// Allocates the node from the bottom of the found hole.
+ Best = bindings::drm_mm_insert_mode_DRM_MM_INSERT_BEST,
+
+ /// Search for the lowest hole (address closest to 0, within the search range) that fits the
+ /// desired node.
+ ///
+ /// Allocates the node from the bottom of the found hole.
+ Low = bindings::drm_mm_insert_mode_DRM_MM_INSERT_LOW,
+
+ /// Search for the highest hole (address closest to U64_MAX, within the search range) that fits
+ /// the desired node.
+ ///
+ /// Allocates the node from the top of the found hole. The specified alignment for the node is
+ /// applied to the base of the node (`Node.start()`).
+ High = bindings::drm_mm_insert_mode_DRM_MM_INSERT_HIGH,
+
+ /// Search for the most recently evicted hole (within the search range) that fits the desired
+ /// node. This is appropriate for use immediately after performing an eviction scan and removing
+ /// the selected nodes to form a hole.
+ ///
+ /// Allocates the node from the bottom of the found hole.
+ Evict = bindings::drm_mm_insert_mode_DRM_MM_INSERT_EVICT,
+}
+
+/// A clonable, interlocked reference to the allocator state.
+///
+/// This is useful to perform actions on the user-supplied `AllocInner<T>` type given just a Node,
+/// without immediately taking the lock.
+#[derive(Clone)]
+pub struct InnerRef<A: AllocInner<T>, T>(Arc<Mutex<MmInner<A, T>>>);
+
+impl<A: AllocInner<T>, T> InnerRef<A, T> {
+ /// Operate on the user `AllocInner<T>` implementation, taking the lock.
+ pub fn with<RetVal>(&self, cb: impl FnOnce(&mut A) -> RetVal) -> RetVal {
+ let mut l = self.0.lock();
+ cb(&mut l.1)
+ }
+}
+
+impl<A: AllocInner<T>, T> NodeData<A, T> {
+ /// Returns the color of the node (an opaque value)
+ pub fn color(&self) -> usize {
+ self.node.color as usize
+ }
+
+ /// Returns the start address of the node
+ pub fn start(&self) -> u64 {
+ self.node.start
+ }
+
+ /// Returns the size of the node in bytes
+ pub fn size(&self) -> u64 {
+ self.node.size
+ }
+
+ /// Operate on the user `AllocInner<T>` implementation associated with this node's allocator.
+ pub fn with_inner<RetVal>(&self, cb: impl FnOnce(&mut A) -> RetVal) -> RetVal {
+ let mut l = self.mm.lock();
+ cb(&mut l.1)
+ }
+
+ /// Return a clonable, detached reference to the allocator inner data.
+ pub fn alloc_ref(&self) -> InnerRef<A, T> {
+ InnerRef(self.mm.clone())
+ }
+
+ /// Return a mutable reference to the inner data.
+ pub fn inner_mut(self: Pin<&mut Self>) -> &mut T {
+ // SAFETY: This is okay because inner is not structural
+ unsafe { &mut self.get_unchecked_mut().inner }
+ }
+}
+
+impl<A: AllocInner<T>, T> Deref for NodeData<A, T> {
+ type Target = T;
+
+ fn deref(&self) -> &Self::Target {
+ &self.inner
+ }
+}
+
+impl<A: AllocInner<T>, T> Drop for NodeData<A, T> {
+ fn drop(&mut self) {
+ if self.valid {
+ let mut guard = self.mm.lock();
+
+ // Inform the user allocator that a node is being dropped.
+ guard
+ .1
+ .drop_object(self.start(), self.size(), self.color(), &mut self.inner);
+ // SAFETY: The MM lock is still taken, so we can safely remove the node.
+ unsafe { bindings::drm_mm_remove_node(&mut self.node) };
+ }
+ }
+}
+
+/// An instance of a DRM MM range allocator.
+pub struct Allocator<A: AllocInner<T>, T> {
+ mm: Arc<Mutex<MmInner<A, T>>>,
+ _p: PhantomData<T>,
+}
+
+impl<A: AllocInner<T>, T> Allocator<A, T> {
+ /// Create a new range allocator for the given start and size range of addresses.
+ ///
+ /// The user may optionally provide an inner object representing allocator state, which will
+ /// be protected by the same lock. If not required, `()` can be used.
+ pub fn new(
+ start: u64,
+ size: u64,
+ inner: A,
+ name: &'static CStr,
+ lock_key: &'static LockClassKey,
+ ) -> Result<Allocator<A, T>> {
+ // SAFETY: We call `Mutex::init_lock` below.
+ let mut mm: Pin<UniqueArc<Mutex<MmInner<A, T>>>> = UniqueArc::try_new(unsafe {
+ Mutex::new(MmInner(Opaque::uninit(), inner, PhantomData))
+ })?
+ .into();
+
+ mm.as_mut().init_lock(name, lock_key);
+
+ unsafe {
+ // SAFETY: The Opaque instance provides a valid pointer, and it is initialized after
+ // this call.
+ bindings::drm_mm_init(mm.lock().0.get(), start, size);
+ }
+
+ Ok(Allocator {
+ mm: mm.into(),
+ _p: PhantomData,
+ })
+ }
+
+ /// Insert a new node into the allocator of a given size.
+ ///
+ /// `node` is the user `T` type data to store into the node.
+ pub fn insert_node(&mut self, node: T, size: u64) -> Result<Node<A, T>> {
+ self.insert_node_generic(node, size, 0, 0, InsertMode::Best)
+ }
+
+ /// Insert a new node into the allocator of a given size, with configurable alignment,
+ /// color, and insertion mode.
+ ///
+ /// `node` is the user `T` type data to store into the node.
+ pub fn insert_node_generic(
+ &mut self,
+ node: T,
+ size: u64,
+ alignment: u64,
+ color: usize,
+ mode: InsertMode,
+ ) -> Result<Node<A, T>> {
+ self.insert_node_in_range(node, size, alignment, color, 0, u64::MAX, mode)
+ }
+
+ /// Insert a new node into the allocator of a given size, with configurable alignment,
+ /// color, insertion mode, and sub-range to allocate from.
+ ///
+ /// `node` is the user `T` type data to store into the node.
+ #[allow(clippy::too_many_arguments)]
+ pub fn insert_node_in_range(
+ &mut self,
+ node: T,
+ size: u64,
+ alignment: u64,
+ color: usize,
+ start: u64,
+ end: u64,
+ mode: InsertMode,
+ ) -> Result<Node<A, T>> {
+ let mut mm_node = Box::try_new(NodeData {
+ // SAFETY: This C struct should be zero-initialized.
+ node: unsafe { core::mem::zeroed() },
+ valid: false,
+ inner: node,
+ mm: self.mm.clone(),
+ _pin: PhantomPinned,
+ })?;
+
+ let guard = self.mm.lock();
+ // SAFETY: We hold the lock and all pointers are valid.
+ to_result(unsafe {
+ bindings::drm_mm_insert_node_in_range(
+ guard.0.get(),
+ &mut mm_node.node,
+ size,
+ alignment,
+ color as core::ffi::c_ulong,
+ start,
+ end,
+ mode as u32,
+ )
+ })?;
+
+ mm_node.valid = true;
+
+ Ok(Pin::from(mm_node))
+ }
+
+ /// Insert a node into the allocator at a fixed start address.
+ ///
+ /// `node` is the user `T` type data to store into the node.
+ pub fn reserve_node(
+ &mut self,
+ node: T,
+ start: u64,
+ size: u64,
+ color: usize,
+ ) -> Result<Node<A, T>> {
+ let mut mm_node = Box::try_new(NodeData {
+ // SAFETY: This C struct should be zero-initialized.
+ node: unsafe { core::mem::zeroed() },
+ valid: false,
+ inner: node,
+ mm: self.mm.clone(),
+ _pin: PhantomPinned,
+ })?;
+
+ mm_node.node.start = start;
+ mm_node.node.size = size;
+ mm_node.node.color = color as core::ffi::c_ulong;
+
+ let guard = self.mm.lock();
+ // SAFETY: We hold the lock and all pointers are valid.
+ to_result(unsafe { bindings::drm_mm_reserve_node(guard.0.get(), &mut mm_node.node) })?;
+
+ mm_node.valid = true;
+
+ Ok(Pin::from(mm_node))
+ }
+
+ /// Operate on the inner user type `A`, taking the allocator lock
+ pub fn with_inner<RetVal>(&self, cb: impl FnOnce(&mut A) -> RetVal) -> RetVal {
+ let mut guard = self.mm.lock();
+ cb(&mut guard.1)
+ }
+}
+
+impl<A: AllocInner<T>, T> Drop for MmInner<A, T> {
+ fn drop(&mut self) {
+ // SAFETY: If the MmInner is dropped then all nodes are gone (since they hold references),
+ // so it is safe to tear down the allocator.
+ unsafe {
+ bindings::drm_mm_takedown(self.0.get());
+ }
+ }
+}
+
+// MmInner is safely Send if the AllocInner user type is Send.
+unsafe impl<A: Send + AllocInner<T>, T> Send for MmInner<A, T> {}
diff --git a/rust/kernel/drm/mod.rs b/rust/kernel/drm/mod.rs
index c44760a1332f..73fab2dee3af 100644
--- a/rust/kernel/drm/mod.rs
+++ b/rust/kernel/drm/mod.rs
@@ -7,3 +7,4 @@ pub mod drv;
pub mod file;
pub mod gem;
pub mod ioctl;
+pub mod mm;
--
2.35.1
^ permalink raw reply related [flat|nested] 122+ messages in thread* Re: [PATCH RFC 07/18] rust: drm: mm: Add DRM MM Range Allocator abstraction
2023-03-07 14:25 ` [PATCH RFC 07/18] rust: drm: mm: Add DRM MM Range Allocator abstraction Asahi Lina
@ 2023-04-06 14:15 ` Daniel Vetter
2023-04-06 15:28 ` Miguel Ojeda
2023-04-06 15:53 ` Asahi Lina
0 siblings, 2 replies; 122+ messages in thread
From: Daniel Vetter @ 2023-04-06 14:15 UTC (permalink / raw)
To: Asahi Lina
Cc: Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
David Airlie, Daniel Vetter, Miguel Ojeda, Alex Gaynor,
Wedson Almeida Filho, Boqun Feng, Gary Guo, Björn Roy Baron,
Sumit Semwal, Christian König, Luben Tuikov,
Jarkko Sakkinen, Dave Hansen, Alyssa Rosenzweig, Karol Herbst,
Ella Stanforth, Faith Ekstrand, Mary, linux-kernel, dri-devel,
rust-for-linux, linux-media, linaro-mm-sig, linux-sgx, asahi
On Tue, Mar 07, 2023 at 11:25:32PM +0900, Asahi Lina wrote:
> drm_mm provides a simple range allocator, useful for managing virtual
> address ranges. Add a Rust abstraction to expose this module to Rust
> drivers.
>
> Signed-off-by: Asahi Lina <lina@asahilina.net>
In the cover letter you mentioned the design open about embedded the lock
into the rust wrappers.
I think for a first step that's perfectly fine.
Longer term we might want to ramp up some "proof of locking"
infrastructure in Rust, where callers can supply a lock guard and ideally
rust validates at compile time that it's for the right type, and at
runtime (like lockdep) that it's consistent and the callers don't mix up
locks (like using different locks for the same drm_mm allocator).
There's a lot of libraries in the kernel that have this "caller ensures
locking" pattern. drm/sched also has these requirements.
There's two other things I'd like to bring up on this patch though, just
because it's a good example. But they're both really general points that
apply for all the rust wrappers.
Documentation:
In drm we try to document all the interfaces that drivers use with formal
docs. Yes there's some areas that are not great for historical reasons,
but for new stuff and new wrappers we're really trying:
- This helps in telling internal (even across .c files or in rust across
modules within a crate) from stuff drivers access. Sure you have static
in C or pub in rust, but that doesn't tell you whether it's public all
the way to drivers.
- ideally docs have a short intro section that explains the main concepts
and links to the main data structures and functions. Just to give
readers a good starting point to explore.
- Linking all the things, so that readers can connect the different parts.
This is really important in C where e.g. get/put() or any such function
pairs all needed to be linked together. With rust I'm hoping that
rustdoc liberally sprinkles links already and we don't have to do this
as much.
- Short explainers for parameters. For rust this also means type
parameters, for those even simplified examples of how drivers are
supposed to use them would help a lot in reading docs & understanding
concepts.
- Ideally links from the rust to the sphinx side to linke relevant
chapters together. Often the bigger explanations are in .rst files with
DOT graphs (kms has a bunch I've added) or similar, and it doesn't make
that much sense to duplicate all that on the rust side I guess. But it
needs to be discoverable.
This might be more a discussion topic for the rust people than you
directly. Still needed for the merge-ready patches eventually.
Refcounting vs borrowing:
This is honestly much more the eyebrow raising one than the locking. Very
often on the C side these datastructures all work with borrow semantics,
and you need to explicitly upgrade to a full reference (kref_get or
kref_get_unless_zero, depending whether it's a strong or weak reference)
if you need the object outside of the mutex/lock guard section.
Again I think for now it's ok, but the sales pitch of rust is that it
enables borrow lifetime checking with no runtime cost. Plus viz the vm
cleanup example, if you have too many strong backreferences the cleanup
flow gets complicated. And it would suck if rust drivers have to add
complexity like the openrefcount for the vm example simply because we
can't model the borrow semantics well enough to be safe.
So not something that's really bad here, but if we need to resort to full
refcounting already for simple datastructures then I'm getting a bit
worried about how well rust will cope with the really nasty borrowed
reference tricks we're playing in other areas.
Again more a topic for the rust folks I think than specifically here about
drm_mm wrapping. Just to get things going I think this is fine.
Cheers, Daniel
> ---
> rust/kernel/drm/mm.rs | 309 +++++++++++++++++++++++++++++++++++++++++++++++++
> rust/kernel/drm/mod.rs | 1 +
> 2 files changed, 310 insertions(+)
>
> diff --git a/rust/kernel/drm/mm.rs b/rust/kernel/drm/mm.rs
> new file mode 100644
> index 000000000000..83e27a7dcc7e
> --- /dev/null
> +++ b/rust/kernel/drm/mm.rs
> @@ -0,0 +1,309 @@
> +// SPDX-License-Identifier: GPL-2.0 OR MIT
> +
> +//! DRM MM range allocator
> +//!
> +//! C header: [`include/linux/drm/drm_mm.h`](../../../../include/linux/drm/drm_mm.h)
> +
> +use crate::{
> + bindings,
> + error::{to_result, Result},
> + str::CStr,
> + sync::{Arc, LockClassKey, LockIniter, Mutex, UniqueArc},
> + types::Opaque,
> +};
> +
> +use alloc::boxed::Box;
> +
> +use core::{
> + marker::{PhantomData, PhantomPinned},
> + ops::Deref,
> + pin::Pin,
> +};
> +
> +/// Type alias representing a DRM MM node.
> +pub type Node<A, T> = Pin<Box<NodeData<A, T>>>;
> +
> +/// Trait which must be implemented by the inner allocator state type provided by the user.
> +pub trait AllocInner<T> {
> + /// Notification that a node was dropped from the allocator.
> + fn drop_object(&mut self, _start: u64, _size: u64, _color: usize, _object: &mut T) {}
> +}
> +
> +impl<T> AllocInner<T> for () {}
> +
> +/// Wrapper type for a `struct drm_mm` plus user AllocInner object.
> +///
> +/// # Invariants
> +/// The `drm_mm` struct is valid and initialized.
> +struct MmInner<A: AllocInner<T>, T>(Opaque<bindings::drm_mm>, A, PhantomData<T>);
> +
> +/// Represents a single allocated node in the MM allocator
> +pub struct NodeData<A: AllocInner<T>, T> {
> + node: bindings::drm_mm_node,
> + mm: Arc<Mutex<MmInner<A, T>>>,
> + valid: bool,
> + /// A drm_mm_node needs to be pinned because nodes reference each other in a linked list.
> + _pin: PhantomPinned,
> + inner: T,
> +}
> +
> +// SAFETY: Allocator ops take the mutex, and there are no mutable actions on the node.
> +unsafe impl<A: Send + AllocInner<T>, T: Send> Send for NodeData<A, T> {}
> +unsafe impl<A: Send + AllocInner<T>, T: Sync> Sync for NodeData<A, T> {}
> +
> +/// Available MM node insertion modes
> +#[repr(u32)]
> +pub enum InsertMode {
> + /// Search for the smallest hole (within the search range) that fits the desired node.
> + ///
> + /// Allocates the node from the bottom of the found hole.
> + Best = bindings::drm_mm_insert_mode_DRM_MM_INSERT_BEST,
> +
> + /// Search for the lowest hole (address closest to 0, within the search range) that fits the
> + /// desired node.
> + ///
> + /// Allocates the node from the bottom of the found hole.
> + Low = bindings::drm_mm_insert_mode_DRM_MM_INSERT_LOW,
> +
> + /// Search for the highest hole (address closest to U64_MAX, within the search range) that fits
> + /// the desired node.
> + ///
> + /// Allocates the node from the top of the found hole. The specified alignment for the node is
> + /// applied to the base of the node (`Node.start()`).
> + High = bindings::drm_mm_insert_mode_DRM_MM_INSERT_HIGH,
> +
> + /// Search for the most recently evicted hole (within the search range) that fits the desired
> + /// node. This is appropriate for use immediately after performing an eviction scan and removing
> + /// the selected nodes to form a hole.
> + ///
> + /// Allocates the node from the bottom of the found hole.
> + Evict = bindings::drm_mm_insert_mode_DRM_MM_INSERT_EVICT,
> +}
> +
> +/// A clonable, interlocked reference to the allocator state.
> +///
> +/// This is useful to perform actions on the user-supplied `AllocInner<T>` type given just a Node,
> +/// without immediately taking the lock.
> +#[derive(Clone)]
> +pub struct InnerRef<A: AllocInner<T>, T>(Arc<Mutex<MmInner<A, T>>>);
> +
> +impl<A: AllocInner<T>, T> InnerRef<A, T> {
> + /// Operate on the user `AllocInner<T>` implementation, taking the lock.
> + pub fn with<RetVal>(&self, cb: impl FnOnce(&mut A) -> RetVal) -> RetVal {
> + let mut l = self.0.lock();
> + cb(&mut l.1)
> + }
> +}
> +
> +impl<A: AllocInner<T>, T> NodeData<A, T> {
> + /// Returns the color of the node (an opaque value)
> + pub fn color(&self) -> usize {
> + self.node.color as usize
> + }
> +
> + /// Returns the start address of the node
> + pub fn start(&self) -> u64 {
> + self.node.start
> + }
> +
> + /// Returns the size of the node in bytes
> + pub fn size(&self) -> u64 {
> + self.node.size
> + }
> +
> + /// Operate on the user `AllocInner<T>` implementation associated with this node's allocator.
> + pub fn with_inner<RetVal>(&self, cb: impl FnOnce(&mut A) -> RetVal) -> RetVal {
> + let mut l = self.mm.lock();
> + cb(&mut l.1)
> + }
> +
> + /// Return a clonable, detached reference to the allocator inner data.
> + pub fn alloc_ref(&self) -> InnerRef<A, T> {
> + InnerRef(self.mm.clone())
> + }
> +
> + /// Return a mutable reference to the inner data.
> + pub fn inner_mut(self: Pin<&mut Self>) -> &mut T {
> + // SAFETY: This is okay because inner is not structural
> + unsafe { &mut self.get_unchecked_mut().inner }
> + }
> +}
> +
> +impl<A: AllocInner<T>, T> Deref for NodeData<A, T> {
> + type Target = T;
> +
> + fn deref(&self) -> &Self::Target {
> + &self.inner
> + }
> +}
> +
> +impl<A: AllocInner<T>, T> Drop for NodeData<A, T> {
> + fn drop(&mut self) {
> + if self.valid {
> + let mut guard = self.mm.lock();
> +
> + // Inform the user allocator that a node is being dropped.
> + guard
> + .1
> + .drop_object(self.start(), self.size(), self.color(), &mut self.inner);
> + // SAFETY: The MM lock is still taken, so we can safely remove the node.
> + unsafe { bindings::drm_mm_remove_node(&mut self.node) };
> + }
> + }
> +}
> +
> +/// An instance of a DRM MM range allocator.
> +pub struct Allocator<A: AllocInner<T>, T> {
> + mm: Arc<Mutex<MmInner<A, T>>>,
> + _p: PhantomData<T>,
> +}
> +
> +impl<A: AllocInner<T>, T> Allocator<A, T> {
> + /// Create a new range allocator for the given start and size range of addresses.
> + ///
> + /// The user may optionally provide an inner object representing allocator state, which will
> + /// be protected by the same lock. If not required, `()` can be used.
> + pub fn new(
> + start: u64,
> + size: u64,
> + inner: A,
> + name: &'static CStr,
> + lock_key: &'static LockClassKey,
> + ) -> Result<Allocator<A, T>> {
> + // SAFETY: We call `Mutex::init_lock` below.
> + let mut mm: Pin<UniqueArc<Mutex<MmInner<A, T>>>> = UniqueArc::try_new(unsafe {
> + Mutex::new(MmInner(Opaque::uninit(), inner, PhantomData))
> + })?
> + .into();
> +
> + mm.as_mut().init_lock(name, lock_key);
> +
> + unsafe {
> + // SAFETY: The Opaque instance provides a valid pointer, and it is initialized after
> + // this call.
> + bindings::drm_mm_init(mm.lock().0.get(), start, size);
> + }
> +
> + Ok(Allocator {
> + mm: mm.into(),
> + _p: PhantomData,
> + })
> + }
> +
> + /// Insert a new node into the allocator of a given size.
> + ///
> + /// `node` is the user `T` type data to store into the node.
> + pub fn insert_node(&mut self, node: T, size: u64) -> Result<Node<A, T>> {
> + self.insert_node_generic(node, size, 0, 0, InsertMode::Best)
> + }
> +
> + /// Insert a new node into the allocator of a given size, with configurable alignment,
> + /// color, and insertion mode.
> + ///
> + /// `node` is the user `T` type data to store into the node.
> + pub fn insert_node_generic(
> + &mut self,
> + node: T,
> + size: u64,
> + alignment: u64,
> + color: usize,
> + mode: InsertMode,
> + ) -> Result<Node<A, T>> {
> + self.insert_node_in_range(node, size, alignment, color, 0, u64::MAX, mode)
> + }
> +
> + /// Insert a new node into the allocator of a given size, with configurable alignment,
> + /// color, insertion mode, and sub-range to allocate from.
> + ///
> + /// `node` is the user `T` type data to store into the node.
> + #[allow(clippy::too_many_arguments)]
> + pub fn insert_node_in_range(
> + &mut self,
> + node: T,
> + size: u64,
> + alignment: u64,
> + color: usize,
> + start: u64,
> + end: u64,
> + mode: InsertMode,
> + ) -> Result<Node<A, T>> {
> + let mut mm_node = Box::try_new(NodeData {
> + // SAFETY: This C struct should be zero-initialized.
> + node: unsafe { core::mem::zeroed() },
> + valid: false,
> + inner: node,
> + mm: self.mm.clone(),
> + _pin: PhantomPinned,
> + })?;
> +
> + let guard = self.mm.lock();
> + // SAFETY: We hold the lock and all pointers are valid.
> + to_result(unsafe {
> + bindings::drm_mm_insert_node_in_range(
> + guard.0.get(),
> + &mut mm_node.node,
> + size,
> + alignment,
> + color as core::ffi::c_ulong,
> + start,
> + end,
> + mode as u32,
> + )
> + })?;
> +
> + mm_node.valid = true;
> +
> + Ok(Pin::from(mm_node))
> + }
> +
> + /// Insert a node into the allocator at a fixed start address.
> + ///
> + /// `node` is the user `T` type data to store into the node.
> + pub fn reserve_node(
> + &mut self,
> + node: T,
> + start: u64,
> + size: u64,
> + color: usize,
> + ) -> Result<Node<A, T>> {
> + let mut mm_node = Box::try_new(NodeData {
> + // SAFETY: This C struct should be zero-initialized.
> + node: unsafe { core::mem::zeroed() },
> + valid: false,
> + inner: node,
> + mm: self.mm.clone(),
> + _pin: PhantomPinned,
> + })?;
> +
> + mm_node.node.start = start;
> + mm_node.node.size = size;
> + mm_node.node.color = color as core::ffi::c_ulong;
> +
> + let guard = self.mm.lock();
> + // SAFETY: We hold the lock and all pointers are valid.
> + to_result(unsafe { bindings::drm_mm_reserve_node(guard.0.get(), &mut mm_node.node) })?;
> +
> + mm_node.valid = true;
> +
> + Ok(Pin::from(mm_node))
> + }
> +
> + /// Operate on the inner user type `A`, taking the allocator lock
> + pub fn with_inner<RetVal>(&self, cb: impl FnOnce(&mut A) -> RetVal) -> RetVal {
> + let mut guard = self.mm.lock();
> + cb(&mut guard.1)
> + }
> +}
> +
> +impl<A: AllocInner<T>, T> Drop for MmInner<A, T> {
> + fn drop(&mut self) {
> + // SAFETY: If the MmInner is dropped then all nodes are gone (since they hold references),
> + // so it is safe to tear down the allocator.
> + unsafe {
> + bindings::drm_mm_takedown(self.0.get());
> + }
> + }
> +}
> +
> +// MmInner is safely Send if the AllocInner user type is Send.
> +unsafe impl<A: Send + AllocInner<T>, T> Send for MmInner<A, T> {}
> diff --git a/rust/kernel/drm/mod.rs b/rust/kernel/drm/mod.rs
> index c44760a1332f..73fab2dee3af 100644
> --- a/rust/kernel/drm/mod.rs
> +++ b/rust/kernel/drm/mod.rs
> @@ -7,3 +7,4 @@ pub mod drv;
> pub mod file;
> pub mod gem;
> pub mod ioctl;
> +pub mod mm;
>
> --
> 2.35.1
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
^ permalink raw reply [flat|nested] 122+ messages in thread* Re: [PATCH RFC 07/18] rust: drm: mm: Add DRM MM Range Allocator abstraction
2023-04-06 14:15 ` Daniel Vetter
@ 2023-04-06 15:28 ` Miguel Ojeda
2023-04-06 15:45 ` Daniel Vetter
2023-04-06 15:53 ` Asahi Lina
1 sibling, 1 reply; 122+ messages in thread
From: Miguel Ojeda @ 2023-04-06 15:28 UTC (permalink / raw)
To: Asahi Lina, Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
David Airlie, Miguel Ojeda, Alex Gaynor, Wedson Almeida Filho,
Boqun Feng, Gary Guo, Björn Roy Baron, Sumit Semwal,
Christian König, Luben Tuikov, Jarkko Sakkinen, Dave Hansen,
Alyssa Rosenzweig, Karol Herbst, Ella Stanforth, Faith Ekstrand,
Mary, linux-kernel, dri-devel, rust-for-linux, linux-media,
linaro-mm-sig, linux-sgx, asahi
Cc: Daniel Vetter
On Thu, Apr 6, 2023 at 4:15 PM Daniel Vetter <daniel@ffwll.ch> wrote:
>
> Documentation:
>
> In drm we try to document all the interfaces that drivers use with formal
> docs. Yes there's some areas that are not great for historical reasons,
> but for new stuff and new wrappers we're really trying:
>
> - This helps in telling internal (even across .c files or in rust across
> modules within a crate) from stuff drivers access. Sure you have static
> in C or pub in rust, but that doesn't tell you whether it's public all
> the way to drivers.
I think you may be talking about the value high-level docs here, but
just in case, visibility in Rust is flexible enough to expose (or not)
APIs to those that you need. In other words, it does tell you (and
enforces!) whether it is public all the way to drivers.
There is also the possibility of even more fancy visibility, but so
far we just needed `pub(crate)`.
`rustdoc` also shows/hides things as needed, thus the generated docs
for the crate should only show what is usable by others.
Then there is the `kernel` crate split, too.
> - ideally docs have a short intro section that explains the main concepts
> and links to the main data structures and functions. Just to give
> readers a good starting point to explore.
Agreed, this is typically done in Rust in the top-level doc comments
(module or crate). For the Rust side of the kernel, we are definitely
trying to emphasize the quality of the docs, including compile- and
runtime-tested examples.
Regarding linking, `rustdoc` already generates a listing with the
contents of each crate/module even if there is no other docs. So as
long as the short descriptions of the items are good, it may be fairly
readable already, e.g. see
https://rust-for-linux.github.io/docs/rust/kernel/sync/index.html for
an example in our old `rust` branch. But, of course, you can add extra
docs at that level too when there are many things or is unclear what
should be used.
Also note that, sometimes, the docs we write are in the type, rather
than the module, e.g. see the nice examples Wedson wrote for `RBTree`:
https://rust-for-linux.github.io/docs/rust/kernel/rbtree/struct.RBTree.html.
> - Linking all the things, so that readers can connect the different parts.
> This is really important in C where e.g. get/put() or any such function
> pairs all needed to be linked together. With rust I'm hoping that
> rustdoc liberally sprinkles links already and we don't have to do this
> as much.
If you mean within doc comments, it does! :) It is called "intra-doc
links". Basically, you just write something in-between square
brackets, and it is able to create the link to the right thing (in
most cases, otherwise you can help it more), e.g.
/// Returns a new [`Foo`].
And, of course, for the rest of things that aren't inside comments, it
automatically provides links etc.
There has been work on `rustdoc` on getting "Jump to Definition" and
similar features to work on the source view, too.
> - Short explainers for parameters. For rust this also means type
> parameters, for those even simplified examples of how drivers are
> supposed to use them would help a lot in reading docs & understanding
> concepts.
For parameters, we are not forcing to write explanations for every
parameter (as in providing a list), but rather writing what is
actually useful to know (referring to the parameters as needed). So it
depends on a case-by-case.
In any case, in general is clearer what parameters are compared to C,
due to the stronger typing. Of course, if one uses integers
everywhere, it is as confusing as C. But if one has a type, it is
easier to tell, plus one may jump with a click into the explanation of
that type etc.
Regarding examples, 100% agreed. And not only that, the examples are
enforced to be kept up to date by compiling and running them via KUnit
(not yet submitted for mainline, but we have been enforcing it for our
old `rust` branch for a long time).
> - Ideally links from the rust to the sphinx side to linke relevant
> chapters together. Often the bigger explanations are in .rst files with
> DOT graphs (kms has a bunch I've added) or similar, and it doesn't make
> that much sense to duplicate all that on the rust side I guess. But it
> needs to be discoverable.
Definitely. One next step is having easy-to-write links to the rST
docs. For this, a couple years ago I talked with the `rustdoc`
maintainers about having a "External references map file" feature, so
that we can link rST documents from the Rust docs, including generated
C docs too. For instance, ideally we would be able to use the square
brackets around a C type and have it work:
/// Exposes the kernel’s [`struct wait_queue_head`] as a condition variable.
Regarding the bigger explanations: we are trying to keep most of the
docs close to the Rust code where it makes sense, as
module-level/crate-level docs, rather than as rST docs. This has
several benefits, like keeping them closer to the code, the linking
features, having them organized equally as the code, no need to know
whether there is a doc somewhere or not (e.g. if it is, it is near the
code), examples are compiled, etc.
Of course, sometimes longer-form docs and other documents may not make
sense as part of any code in particular, or may be shared across C and
Rust, etc., and there it may more sense to use `Documentation/` files
instead.
But, in general, the idea is that, compared to C, most of the docs go
into the code. To give an idea of the difference: so far, in our old
`rust` branch, we only needed a few documents in `Documentation/`
(e.g. the Quick Start guide etc.), and everything else went into the
code itself.
Cheers,
Miguel
^ permalink raw reply [flat|nested] 122+ messages in thread* Re: [PATCH RFC 07/18] rust: drm: mm: Add DRM MM Range Allocator abstraction
2023-04-06 15:28 ` Miguel Ojeda
@ 2023-04-06 15:45 ` Daniel Vetter
2023-04-06 17:19 ` Miguel Ojeda
0 siblings, 1 reply; 122+ messages in thread
From: Daniel Vetter @ 2023-04-06 15:45 UTC (permalink / raw)
To: Miguel Ojeda
Cc: Asahi Lina, Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
David Airlie, Miguel Ojeda, Alex Gaynor, Wedson Almeida Filho,
Boqun Feng, Gary Guo, Björn Roy Baron, Sumit Semwal,
Christian König, Luben Tuikov, Jarkko Sakkinen, Dave Hansen,
Alyssa Rosenzweig, Karol Herbst, Ella Stanforth, Faith Ekstrand,
Mary, linux-kernel, dri-devel, rust-for-linux, linux-media,
linaro-mm-sig, linux-sgx, asahi, Daniel Vetter
On Thu, Apr 06, 2023 at 05:28:59PM +0200, Miguel Ojeda wrote:
> On Thu, Apr 6, 2023 at 4:15 PM Daniel Vetter <daniel@ffwll.ch> wrote:
> >
> > Documentation:
> >
> > In drm we try to document all the interfaces that drivers use with formal
> > docs. Yes there's some areas that are not great for historical reasons,
> > but for new stuff and new wrappers we're really trying:
> >
> > - This helps in telling internal (even across .c files or in rust across
> > modules within a crate) from stuff drivers access. Sure you have static
> > in C or pub in rust, but that doesn't tell you whether it's public all
> > the way to drivers.
>
> I think you may be talking about the value high-level docs here, but
> just in case, visibility in Rust is flexible enough to expose (or not)
> APIs to those that you need. In other words, it does tell you (and
> enforces!) whether it is public all the way to drivers.
>
> There is also the possibility of even more fancy visibility, but so
> far we just needed `pub(crate)`.
>
> `rustdoc` also shows/hides things as needed, thus the generated docs
> for the crate should only show what is usable by others.
>
> Then there is the `kernel` crate split, too.
>
> > - ideally docs have a short intro section that explains the main concepts
> > and links to the main data structures and functions. Just to give
> > readers a good starting point to explore.
>
> Agreed, this is typically done in Rust in the top-level doc comments
> (module or crate). For the Rust side of the kernel, we are definitely
> trying to emphasize the quality of the docs, including compile- and
> runtime-tested examples.
>
> Regarding linking, `rustdoc` already generates a listing with the
> contents of each crate/module even if there is no other docs. So as
> long as the short descriptions of the items are good, it may be fairly
> readable already, e.g. see
> https://rust-for-linux.github.io/docs/rust/kernel/sync/index.html for
> an example in our old `rust` branch. But, of course, you can add extra
> docs at that level too when there are many things or is unclear what
> should be used.
>
> Also note that, sometimes, the docs we write are in the type, rather
> than the module, e.g. see the nice examples Wedson wrote for `RBTree`:
> https://rust-for-linux.github.io/docs/rust/kernel/rbtree/struct.RBTree.html.
Yeah this all looks great and very hyperlinked.
I think the only nit I have is that for types with two or more type
variables (like the rbtree) what each of them should represent in the top
intro. I can guess it's <Key, Value> and not the other way round, but
confirmation takes quite a bit of scrolling to check with the function
types.
Otherwise I think perfect api docs.
> > - Linking all the things, so that readers can connect the different parts.
> > This is really important in C where e.g. get/put() or any such function
> > pairs all needed to be linked together. With rust I'm hoping that
> > rustdoc liberally sprinkles links already and we don't have to do this
> > as much.
>
> If you mean within doc comments, it does! :) It is called "intra-doc
> links". Basically, you just write something in-between square
> brackets, and it is able to create the link to the right thing (in
> most cases, otherwise you can help it more), e.g.
>
> /// Returns a new [`Foo`].
>
> And, of course, for the rest of things that aren't inside comments, it
> automatically provides links etc.
>
> There has been work on `rustdoc` on getting "Jump to Definition" and
> similar features to work on the source view, too.
>
> > - Short explainers for parameters. For rust this also means type
> > parameters, for those even simplified examples of how drivers are
> > supposed to use them would help a lot in reading docs & understanding
> > concepts.
>
> For parameters, we are not forcing to write explanations for every
> parameter (as in providing a list), but rather writing what is
> actually useful to know (referring to the parameters as needed). So it
> depends on a case-by-case.
>
> In any case, in general is clearer what parameters are compared to C,
> due to the stronger typing. Of course, if one uses integers
> everywhere, it is as confusing as C. But if one has a type, it is
> easier to tell, plus one may jump with a click into the explanation of
> that type etc.
>
> Regarding examples, 100% agreed. And not only that, the examples are
> enforced to be kept up to date by compiling and running them via KUnit
> (not yet submitted for mainline, but we have been enforcing it for our
> old `rust` branch for a long time).
>
> > - Ideally links from the rust to the sphinx side to linke relevant
> > chapters together. Often the bigger explanations are in .rst files with
> > DOT graphs (kms has a bunch I've added) or similar, and it doesn't make
> > that much sense to duplicate all that on the rust side I guess. But it
> > needs to be discoverable.
>
> Definitely. One next step is having easy-to-write links to the rST
> docs. For this, a couple years ago I talked with the `rustdoc`
> maintainers about having a "External references map file" feature, so
> that we can link rST documents from the Rust docs, including generated
> C docs too. For instance, ideally we would be able to use the square
> brackets around a C type and have it work:
>
> /// Exposes the kernel’s [`struct wait_queue_head`] as a condition variable.
>
> Regarding the bigger explanations: we are trying to keep most of the
> docs close to the Rust code where it makes sense, as
> module-level/crate-level docs, rather than as rST docs. This has
> several benefits, like keeping them closer to the code, the linking
> features, having them organized equally as the code, no need to know
> whether there is a doc somewhere or not (e.g. if it is, it is near the
> code), examples are compiled, etc.
Just a quick comment on this, that's the same we do on the C side. Most
overview chapters are actually DOC: sections pulled in from the code.
What I meant here is that for big overview stuff (like for modesetting how
the display pipe structures tie together as an example:
https://dri.freedesktop.org/docs/drm/gpu/drm-kms.html#overview)
it doesn't make sense to duplicate that in rustdoc once more.
> Of course, sometimes longer-form docs and other documents may not make
> sense as part of any code in particular, or may be shared across C and
> Rust, etc., and there it may more sense to use `Documentation/` files
> instead.
>
> But, in general, the idea is that, compared to C, most of the docs go
> into the code. To give an idea of the difference: so far, in our old
> `rust` branch, we only needed a few documents in `Documentation/`
> (e.g. the Quick Start guide etc.), and everything else went into the
> code itself.
Maybe drm is the exception, but if you look at our .rst files we also have
most of our docs in the code:
https://cgit.freedesktop.org/drm/drm/tree/Documentation/gpu/drm-kms-helpers.rst
The rst files just provide the scaffolding because C dosn't have
crates/modules hierarchy that would do this for you automatically.
Cheers, Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
^ permalink raw reply [flat|nested] 122+ messages in thread
* Re: [PATCH RFC 07/18] rust: drm: mm: Add DRM MM Range Allocator abstraction
2023-04-06 15:45 ` Daniel Vetter
@ 2023-04-06 17:19 ` Miguel Ojeda
0 siblings, 0 replies; 122+ messages in thread
From: Miguel Ojeda @ 2023-04-06 17:19 UTC (permalink / raw)
To: Miguel Ojeda, Asahi Lina, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Miguel Ojeda, Alex Gaynor,
Wedson Almeida Filho, Boqun Feng, Gary Guo, Björn Roy Baron,
Sumit Semwal, Christian König, Luben Tuikov,
Jarkko Sakkinen, Dave Hansen, Alyssa Rosenzweig, Karol Herbst,
Ella Stanforth, Faith Ekstrand, Mary, linux-kernel, dri-devel,
rust-for-linux, linux-media, linaro-mm-sig, linux-sgx, asahi
Cc: Daniel Vetter
On Thu, Apr 6, 2023 at 5:45 PM Daniel Vetter <daniel@ffwll.ch> wrote:
>
> Yeah this all looks great and very hyperlinked.
>
> I think the only nit I have is that for types with two or more type
> variables (like the rbtree) what each of them should represent in the top
> intro. I can guess it's <Key, Value> and not the other way round, but
> confirmation takes quite a bit of scrolling to check with the function
> types.
Yeah, that is fair. Personally I prefer more descriptive names when
there are several or they have a special/asymmetric role.
> Otherwise I think perfect api docs.
Glad you like it!
> Just a quick comment on this, that's the same we do on the C side. Most
> overview chapters are actually DOC: sections pulled in from the code.
>
> What I meant here is that for big overview stuff (like for modesetting how
> the display pipe structures tie together as an example:
> https://dri.freedesktop.org/docs/drm/gpu/drm-kms.html#overview)
> it doesn't make sense to duplicate that in rustdoc once more.
Yeah, definitely, if it is already somewhere else for C, we shouldn't
duplicate it (that is what I meant by the "shared across C and Rust"
exception).
> Maybe drm is the exception, but if you look at our .rst files we also have
> most of our docs in the code:
>
> https://cgit.freedesktop.org/drm/drm/tree/Documentation/gpu/drm-kms-helpers.rst
>
> The rst files just provide the scaffolding because C dosn't have
> crates/modules hierarchy that would do this for you automatically.
Sorry, I was talking in general in the kernel. That
`drm-kms-helpers.rst` looks great.
From a quick grep, I think you are indeed one of the big users of
`DOC: `, which indeed map closely to what you would do in Rust without
the scaffolding need.
So I think you will like writing docs in Rust :)
Cheers,
Miguel
^ permalink raw reply [flat|nested] 122+ messages in thread
* Re: [PATCH RFC 07/18] rust: drm: mm: Add DRM MM Range Allocator abstraction
2023-04-06 14:15 ` Daniel Vetter
2023-04-06 15:28 ` Miguel Ojeda
@ 2023-04-06 15:53 ` Asahi Lina
2023-04-06 16:13 ` [Linaro-mm-sig] " Daniel Vetter
1 sibling, 1 reply; 122+ messages in thread
From: Asahi Lina @ 2023-04-06 15:53 UTC (permalink / raw)
To: Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
David Airlie, Miguel Ojeda, Alex Gaynor, Wedson Almeida Filho,
Boqun Feng, Gary Guo, Björn Roy Baron, Sumit Semwal,
Christian König, Luben Tuikov, Jarkko Sakkinen, Dave Hansen,
Alyssa Rosenzweig, Karol Herbst, Ella Stanforth, Faith Ekstrand,
Mary, linux-kernel, dri-devel, rust-for-linux, linux-media,
linaro-mm-sig, linux-sgx, asahi
On 06/04/2023 23.15, Daniel Vetter wrote:
> On Tue, Mar 07, 2023 at 11:25:32PM +0900, Asahi Lina wrote:
>> drm_mm provides a simple range allocator, useful for managing virtual
>> address ranges. Add a Rust abstraction to expose this module to Rust
>> drivers.
>>
>> Signed-off-by: Asahi Lina <lina@asahilina.net>
>
> In the cover letter you mentioned the design open about embedded the lock
> into the rust wrappers.
>
> I think for a first step that's perfectly fine.
>
> Longer term we might want to ramp up some "proof of locking"
> infrastructure in Rust, where callers can supply a lock guard and ideally
> rust validates at compile time that it's for the right type, and at
> runtime (like lockdep) that it's consistent and the callers don't mix up
> locks (like using different locks for the same drm_mm allocator).
That proof-of-lock tuff works in Rust too as far as I know.
But the general thread safety story in Rust is much simpler, you just
use methods that take &mut self when locking is the caller's
responsibility. That effectively implies that there can only be one
reference that can call those methods at any given time, thanks to the
borrow checker. Shared references only give you &self, a locked Mutex
upgrades that to &mut self, and that's how you get proof of locking at
compile time, through and through, not just for the type but for the
specific object.
> There's a lot of libraries in the kernel that have this "caller ensures
> locking" pattern. drm/sched also has these requirements.
Yup, that all usually maps nicely to &mut self in Rust... except for the
issue below.
> There's two other things I'd like to bring up on this patch though, just
> because it's a good example. But they're both really general points that
> apply for all the rust wrappers.
>
> Documentation:
>
> In drm we try to document all the interfaces that drivers use with formal
> docs. Yes there's some areas that are not great for historical reasons,
> but for new stuff and new wrappers we're really trying:
>
> - This helps in telling internal (even across .c files or in rust across
> modules within a crate) from stuff drivers access. Sure you have static
> in C or pub in rust, but that doesn't tell you whether it's public all
> the way to drivers.
>
> - ideally docs have a short intro section that explains the main concepts
> and links to the main data structures and functions. Just to give
> readers a good starting point to explore.
>
> - Linking all the things, so that readers can connect the different parts.
> This is really important in C where e.g. get/put() or any such function
> pairs all needed to be linked together. With rust I'm hoping that
> rustdoc liberally sprinkles links already and we don't have to do this
> as much.
>
> - Short explainers for parameters. For rust this also means type
> parameters, for those even simplified examples of how drivers are
> supposed to use them would help a lot in reading docs & understanding
> concepts.
>
> - Ideally links from the rust to the sphinx side to linke relevant
> chapters together. Often the bigger explanations are in .rst files with
> DOT graphs (kms has a bunch I've added) or similar, and it doesn't make
> that much sense to duplicate all that on the rust side I guess. But it
> needs to be discoverable.
>
> This might be more a discussion topic for the rust people than you
> directly. Still needed for the merge-ready patches eventually.
I don't know much about the doc gen stuff on the Rust side so yeah, this
is something I need to look into to make it pretty and complete...
> Refcounting vs borrowing:
>
> This is honestly much more the eyebrow raising one than the locking. Very
> often on the C side these datastructures all work with borrow semantics,
> and you need to explicitly upgrade to a full reference (kref_get or
> kref_get_unless_zero, depending whether it's a strong or weak reference)
> if you need the object outside of the mutex/lock guard section.
>
> Again I think for now it's ok, but the sales pitch of rust is that it
> enables borrow lifetime checking with no runtime cost. Plus viz the vm
> cleanup example, if you have too many strong backreferences the cleanup
> flow gets complicated. And it would suck if rust drivers have to add
> complexity like the openrefcount for the vm example simply because we
> can't model the borrow semantics well enough to be safe.
>
> So not something that's really bad here, but if we need to resort to full
> refcounting already for simple datastructures then I'm getting a bit
> worried about how well rust will cope with the really nasty borrowed
> reference tricks we're playing in other areas.
>
> Again more a topic for the rust folks I think than specifically here about
> drm_mm wrapping. Just to get things going I think this is fine.
Yeeeeah... this is a *specific* problem. Drop.
The Allocator<T> itself is perfectly safe to implement without any
locking, refcounting, or anything. You just make the methods take &mut
self (as they already do), the caller can use it with a single reference
or wrap it in an Arc<Mutex<T>> and share it, or whatever.
The problem is the Node<A, T>. When you Drop that, it has to go back to
the Allocator. But now you're a different object, so no thread safety
guarantees. And you need to keep the Allocator alive. So now to make a
safe abstraction, you need refcounting and a mutex.
Lifetimes just don't work here, sadly. Not for a useful abstraction.
I'd love to hear from the other Rust folks whether they have any better
ideas...
One thing that *can* be done is making the Drop illegal (Rust can't do
this "natively" but Linux already has hacks for that, we can make it
fail to link if the Drop is ever called). Then you'd have to actively
return the Node to the Allocator with a free function. Since Drop is
forbidden, and Node is pinned, you'd always have to either return Node
objects to the Allocator or leak them. You could drop the Allocator
before its nodes, but as far as I know drm_mm can safely handle that
(though it will complain), and then due to the previous guarantees the
*only* thing you could do with orphan nodes is leak their memory, which
is safe.
It would work... but it breaks the whole Rust automagic Drop stuff.
Thinking about this a bit, I think I want the current mutex/arc
semantics for something like a memory allocator (which is one of my
primary use cases for drm_mm), since I definitely don't want to be
manually returning objects to their allocator all over the place, nor
have overarching lifetime requirements that the allocator outlive its
objects for safety (that sounds like a can of worms I don't want to
open, I'd much rather use a refcount even if I "think" I can prove the
lifetime bounds ad-hoc). But for something like a drm_mm that is
tracking VA ranges within a VM with all Nodes held internally, maybe I
could manage it all internally and have all node destruction be handled
via an explicit call into the Allocator.
Maybe the mm abstraction should offer both options? The extra locking
can be implemented in terms of the base unlocked version I think
(perhaps with some Deref abuse for ergonomics)... I definitely want to
hear more opinions about this from other Rust folks, since there are
probably other options I haven't considered...
Aside: This, and all the other DRM abstractions, were written before the
pin_init stuff from y86 that is in review right now was ready. That may
open up more interesting/ergonomic/efficient APIs for some cases,
especially where Pin and embedding C types into user objects in some way
are involved. So maybe there's room for improvement here. Just a sidenote.
>
> Cheers, Daniel
>
>
>> ---
>> rust/kernel/drm/mm.rs | 309 +++++++++++++++++++++++++++++++++++++++++++++++++
>> rust/kernel/drm/mod.rs | 1 +
>> 2 files changed, 310 insertions(+)
>>
>> diff --git a/rust/kernel/drm/mm.rs b/rust/kernel/drm/mm.rs
>> new file mode 100644
>> index 000000000000..83e27a7dcc7e
>> --- /dev/null
>> +++ b/rust/kernel/drm/mm.rs
>> @@ -0,0 +1,309 @@
>> +// SPDX-License-Identifier: GPL-2.0 OR MIT
>> +
>> +//! DRM MM range allocator
>> +//!
>> +//! C header: [`include/linux/drm/drm_mm.h`](../../../../include/linux/drm/drm_mm.h)
>> +
>> +use crate::{
>> + bindings,
>> + error::{to_result, Result},
>> + str::CStr,
>> + sync::{Arc, LockClassKey, LockIniter, Mutex, UniqueArc},
>> + types::Opaque,
>> +};
>> +
>> +use alloc::boxed::Box;
>> +
>> +use core::{
>> + marker::{PhantomData, PhantomPinned},
>> + ops::Deref,
>> + pin::Pin,
>> +};
>> +
>> +/// Type alias representing a DRM MM node.
>> +pub type Node<A, T> = Pin<Box<NodeData<A, T>>>;
>> +
>> +/// Trait which must be implemented by the inner allocator state type provided by the user.
>> +pub trait AllocInner<T> {
>> + /// Notification that a node was dropped from the allocator.
>> + fn drop_object(&mut self, _start: u64, _size: u64, _color: usize, _object: &mut T) {}
>> +}
>> +
>> +impl<T> AllocInner<T> for () {}
>> +
>> +/// Wrapper type for a `struct drm_mm` plus user AllocInner object.
>> +///
>> +/// # Invariants
>> +/// The `drm_mm` struct is valid and initialized.
>> +struct MmInner<A: AllocInner<T>, T>(Opaque<bindings::drm_mm>, A, PhantomData<T>);
>> +
>> +/// Represents a single allocated node in the MM allocator
>> +pub struct NodeData<A: AllocInner<T>, T> {
>> + node: bindings::drm_mm_node,
>> + mm: Arc<Mutex<MmInner<A, T>>>,
>> + valid: bool,
>> + /// A drm_mm_node needs to be pinned because nodes reference each other in a linked list.
>> + _pin: PhantomPinned,
>> + inner: T,
>> +}
>> +
>> +// SAFETY: Allocator ops take the mutex, and there are no mutable actions on the node.
>> +unsafe impl<A: Send + AllocInner<T>, T: Send> Send for NodeData<A, T> {}
>> +unsafe impl<A: Send + AllocInner<T>, T: Sync> Sync for NodeData<A, T> {}
>> +
>> +/// Available MM node insertion modes
>> +#[repr(u32)]
>> +pub enum InsertMode {
>> + /// Search for the smallest hole (within the search range) that fits the desired node.
>> + ///
>> + /// Allocates the node from the bottom of the found hole.
>> + Best = bindings::drm_mm_insert_mode_DRM_MM_INSERT_BEST,
>> +
>> + /// Search for the lowest hole (address closest to 0, within the search range) that fits the
>> + /// desired node.
>> + ///
>> + /// Allocates the node from the bottom of the found hole.
>> + Low = bindings::drm_mm_insert_mode_DRM_MM_INSERT_LOW,
>> +
>> + /// Search for the highest hole (address closest to U64_MAX, within the search range) that fits
>> + /// the desired node.
>> + ///
>> + /// Allocates the node from the top of the found hole. The specified alignment for the node is
>> + /// applied to the base of the node (`Node.start()`).
>> + High = bindings::drm_mm_insert_mode_DRM_MM_INSERT_HIGH,
>> +
>> + /// Search for the most recently evicted hole (within the search range) that fits the desired
>> + /// node. This is appropriate for use immediately after performing an eviction scan and removing
>> + /// the selected nodes to form a hole.
>> + ///
>> + /// Allocates the node from the bottom of the found hole.
>> + Evict = bindings::drm_mm_insert_mode_DRM_MM_INSERT_EVICT,
>> +}
>> +
>> +/// A clonable, interlocked reference to the allocator state.
>> +///
>> +/// This is useful to perform actions on the user-supplied `AllocInner<T>` type given just a Node,
>> +/// without immediately taking the lock.
>> +#[derive(Clone)]
>> +pub struct InnerRef<A: AllocInner<T>, T>(Arc<Mutex<MmInner<A, T>>>);
>> +
>> +impl<A: AllocInner<T>, T> InnerRef<A, T> {
>> + /// Operate on the user `AllocInner<T>` implementation, taking the lock.
>> + pub fn with<RetVal>(&self, cb: impl FnOnce(&mut A) -> RetVal) -> RetVal {
>> + let mut l = self.0.lock();
>> + cb(&mut l.1)
>> + }
>> +}
>> +
>> +impl<A: AllocInner<T>, T> NodeData<A, T> {
>> + /// Returns the color of the node (an opaque value)
>> + pub fn color(&self) -> usize {
>> + self.node.color as usize
>> + }
>> +
>> + /// Returns the start address of the node
>> + pub fn start(&self) -> u64 {
>> + self.node.start
>> + }
>> +
>> + /// Returns the size of the node in bytes
>> + pub fn size(&self) -> u64 {
>> + self.node.size
>> + }
>> +
>> + /// Operate on the user `AllocInner<T>` implementation associated with this node's allocator.
>> + pub fn with_inner<RetVal>(&self, cb: impl FnOnce(&mut A) -> RetVal) -> RetVal {
>> + let mut l = self.mm.lock();
>> + cb(&mut l.1)
>> + }
>> +
>> + /// Return a clonable, detached reference to the allocator inner data.
>> + pub fn alloc_ref(&self) -> InnerRef<A, T> {
>> + InnerRef(self.mm.clone())
>> + }
>> +
>> + /// Return a mutable reference to the inner data.
>> + pub fn inner_mut(self: Pin<&mut Self>) -> &mut T {
>> + // SAFETY: This is okay because inner is not structural
>> + unsafe { &mut self.get_unchecked_mut().inner }
>> + }
>> +}
>> +
>> +impl<A: AllocInner<T>, T> Deref for NodeData<A, T> {
>> + type Target = T;
>> +
>> + fn deref(&self) -> &Self::Target {
>> + &self.inner
>> + }
>> +}
>> +
>> +impl<A: AllocInner<T>, T> Drop for NodeData<A, T> {
>> + fn drop(&mut self) {
>> + if self.valid {
>> + let mut guard = self.mm.lock();
>> +
>> + // Inform the user allocator that a node is being dropped.
>> + guard
>> + .1
>> + .drop_object(self.start(), self.size(), self.color(), &mut self.inner);
>> + // SAFETY: The MM lock is still taken, so we can safely remove the node.
>> + unsafe { bindings::drm_mm_remove_node(&mut self.node) };
>> + }
>> + }
>> +}
>> +
>> +/// An instance of a DRM MM range allocator.
>> +pub struct Allocator<A: AllocInner<T>, T> {
>> + mm: Arc<Mutex<MmInner<A, T>>>,
>> + _p: PhantomData<T>,
>> +}
>> +
>> +impl<A: AllocInner<T>, T> Allocator<A, T> {
>> + /// Create a new range allocator for the given start and size range of addresses.
>> + ///
>> + /// The user may optionally provide an inner object representing allocator state, which will
>> + /// be protected by the same lock. If not required, `()` can be used.
>> + pub fn new(
>> + start: u64,
>> + size: u64,
>> + inner: A,
>> + name: &'static CStr,
>> + lock_key: &'static LockClassKey,
>> + ) -> Result<Allocator<A, T>> {
>> + // SAFETY: We call `Mutex::init_lock` below.
>> + let mut mm: Pin<UniqueArc<Mutex<MmInner<A, T>>>> = UniqueArc::try_new(unsafe {
>> + Mutex::new(MmInner(Opaque::uninit(), inner, PhantomData))
>> + })?
>> + .into();
>> +
>> + mm.as_mut().init_lock(name, lock_key);
>> +
>> + unsafe {
>> + // SAFETY: The Opaque instance provides a valid pointer, and it is initialized after
>> + // this call.
>> + bindings::drm_mm_init(mm.lock().0.get(), start, size);
>> + }
>> +
>> + Ok(Allocator {
>> + mm: mm.into(),
>> + _p: PhantomData,
>> + })
>> + }
>> +
>> + /// Insert a new node into the allocator of a given size.
>> + ///
>> + /// `node` is the user `T` type data to store into the node.
>> + pub fn insert_node(&mut self, node: T, size: u64) -> Result<Node<A, T>> {
>> + self.insert_node_generic(node, size, 0, 0, InsertMode::Best)
>> + }
>> +
>> + /// Insert a new node into the allocator of a given size, with configurable alignment,
>> + /// color, and insertion mode.
>> + ///
>> + /// `node` is the user `T` type data to store into the node.
>> + pub fn insert_node_generic(
>> + &mut self,
>> + node: T,
>> + size: u64,
>> + alignment: u64,
>> + color: usize,
>> + mode: InsertMode,
>> + ) -> Result<Node<A, T>> {
>> + self.insert_node_in_range(node, size, alignment, color, 0, u64::MAX, mode)
>> + }
>> +
>> + /// Insert a new node into the allocator of a given size, with configurable alignment,
>> + /// color, insertion mode, and sub-range to allocate from.
>> + ///
>> + /// `node` is the user `T` type data to store into the node.
>> + #[allow(clippy::too_many_arguments)]
>> + pub fn insert_node_in_range(
>> + &mut self,
>> + node: T,
>> + size: u64,
>> + alignment: u64,
>> + color: usize,
>> + start: u64,
>> + end: u64,
>> + mode: InsertMode,
>> + ) -> Result<Node<A, T>> {
>> + let mut mm_node = Box::try_new(NodeData {
>> + // SAFETY: This C struct should be zero-initialized.
>> + node: unsafe { core::mem::zeroed() },
>> + valid: false,
>> + inner: node,
>> + mm: self.mm.clone(),
>> + _pin: PhantomPinned,
>> + })?;
>> +
>> + let guard = self.mm.lock();
>> + // SAFETY: We hold the lock and all pointers are valid.
>> + to_result(unsafe {
>> + bindings::drm_mm_insert_node_in_range(
>> + guard.0.get(),
>> + &mut mm_node.node,
>> + size,
>> + alignment,
>> + color as core::ffi::c_ulong,
>> + start,
>> + end,
>> + mode as u32,
>> + )
>> + })?;
>> +
>> + mm_node.valid = true;
>> +
>> + Ok(Pin::from(mm_node))
>> + }
>> +
>> + /// Insert a node into the allocator at a fixed start address.
>> + ///
>> + /// `node` is the user `T` type data to store into the node.
>> + pub fn reserve_node(
>> + &mut self,
>> + node: T,
>> + start: u64,
>> + size: u64,
>> + color: usize,
>> + ) -> Result<Node<A, T>> {
>> + let mut mm_node = Box::try_new(NodeData {
>> + // SAFETY: This C struct should be zero-initialized.
>> + node: unsafe { core::mem::zeroed() },
>> + valid: false,
>> + inner: node,
>> + mm: self.mm.clone(),
>> + _pin: PhantomPinned,
>> + })?;
>> +
>> + mm_node.node.start = start;
>> + mm_node.node.size = size;
>> + mm_node.node.color = color as core::ffi::c_ulong;
>> +
>> + let guard = self.mm.lock();
>> + // SAFETY: We hold the lock and all pointers are valid.
>> + to_result(unsafe { bindings::drm_mm_reserve_node(guard.0.get(), &mut mm_node.node) })?;
>> +
>> + mm_node.valid = true;
>> +
>> + Ok(Pin::from(mm_node))
>> + }
>> +
>> + /// Operate on the inner user type `A`, taking the allocator lock
>> + pub fn with_inner<RetVal>(&self, cb: impl FnOnce(&mut A) -> RetVal) -> RetVal {
>> + let mut guard = self.mm.lock();
>> + cb(&mut guard.1)
>> + }
>> +}
>> +
>> +impl<A: AllocInner<T>, T> Drop for MmInner<A, T> {
>> + fn drop(&mut self) {
>> + // SAFETY: If the MmInner is dropped then all nodes are gone (since they hold references),
>> + // so it is safe to tear down the allocator.
>> + unsafe {
>> + bindings::drm_mm_takedown(self.0.get());
>> + }
>> + }
>> +}
>> +
>> +// MmInner is safely Send if the AllocInner user type is Send.
>> +unsafe impl<A: Send + AllocInner<T>, T> Send for MmInner<A, T> {}
>> diff --git a/rust/kernel/drm/mod.rs b/rust/kernel/drm/mod.rs
>> index c44760a1332f..73fab2dee3af 100644
>> --- a/rust/kernel/drm/mod.rs
>> +++ b/rust/kernel/drm/mod.rs
>> @@ -7,3 +7,4 @@ pub mod drv;
>> pub mod file;
>> pub mod gem;
>> pub mod ioctl;
>> +pub mod mm;
>>
>> --
>> 2.35.1
>>
>
~~ Lina
^ permalink raw reply [flat|nested] 122+ messages in thread* Re: [Linaro-mm-sig] Re: [PATCH RFC 07/18] rust: drm: mm: Add DRM MM Range Allocator abstraction
2023-04-06 15:53 ` Asahi Lina
@ 2023-04-06 16:13 ` Daniel Vetter
2023-04-06 16:39 ` Asahi Lina
0 siblings, 1 reply; 122+ messages in thread
From: Daniel Vetter @ 2023-04-06 16:13 UTC (permalink / raw)
To: Asahi Lina
Cc: Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
David Airlie, Miguel Ojeda, Alex Gaynor, Wedson Almeida Filho,
Boqun Feng, Gary Guo, Björn Roy Baron, Sumit Semwal,
Christian König, Luben Tuikov, Jarkko Sakkinen, Dave Hansen,
Alyssa Rosenzweig, Karol Herbst, Ella Stanforth, Faith Ekstrand,
Mary, linux-kernel, dri-devel, rust-for-linux, linux-media,
linaro-mm-sig, linux-sgx, asahi
On Fri, Apr 07, 2023 at 12:53:47AM +0900, Asahi Lina wrote:
> On 06/04/2023 23.15, Daniel Vetter wrote:
> > On Tue, Mar 07, 2023 at 11:25:32PM +0900, Asahi Lina wrote:
> > > drm_mm provides a simple range allocator, useful for managing virtual
> > > address ranges. Add a Rust abstraction to expose this module to Rust
> > > drivers.
> > >
> > > Signed-off-by: Asahi Lina <lina@asahilina.net>
> >
> > In the cover letter you mentioned the design open about embedded the lock
> > into the rust wrappers.
> >
> > I think for a first step that's perfectly fine.
> >
> > Longer term we might want to ramp up some "proof of locking"
> > infrastructure in Rust, where callers can supply a lock guard and ideally
> > rust validates at compile time that it's for the right type, and at
> > runtime (like lockdep) that it's consistent and the callers don't mix up
> > locks (like using different locks for the same drm_mm allocator).
>
> That proof-of-lock tuff works in Rust too as far as I know.
>
> But the general thread safety story in Rust is much simpler, you just use
> methods that take &mut self when locking is the caller's responsibility.
> That effectively implies that there can only be one reference that can call
> those methods at any given time, thanks to the borrow checker. Shared
> references only give you &self, a locked Mutex upgrades that to &mut self,
> and that's how you get proof of locking at compile time, through and
> through, not just for the type but for the specific object.
Hm that still has the problem of making sure that you supply the right
lock (for generic abstractions like drm_mm or drm/sched where the lock is
supplied by the driver.
Once we have the lock then yeah borrow checker makes sure you can't screw
up, worst case needs a PhantomData (I guess) as toke of proof to pass
around the borrowed lifetime (If I got that right from your use of
PhantomData in the sched wrappers).
> > There's a lot of libraries in the kernel that have this "caller ensures
> > locking" pattern. drm/sched also has these requirements.
>
> Yup, that all usually maps nicely to &mut self in Rust... except for the
> issue below.
>
> > There's two other things I'd like to bring up on this patch though, just
> > because it's a good example. But they're both really general points that
> > apply for all the rust wrappers.
> >
> > Documentation:
> >
> > In drm we try to document all the interfaces that drivers use with formal
> > docs. Yes there's some areas that are not great for historical reasons,
> > but for new stuff and new wrappers we're really trying:
> >
> > - This helps in telling internal (even across .c files or in rust across
> > modules within a crate) from stuff drivers access. Sure you have static
> > in C or pub in rust, but that doesn't tell you whether it's public all
> > the way to drivers.
> >
> > - ideally docs have a short intro section that explains the main concepts
> > and links to the main data structures and functions. Just to give
> > readers a good starting point to explore.
> >
> > - Linking all the things, so that readers can connect the different parts.
> > This is really important in C where e.g. get/put() or any such function
> > pairs all needed to be linked together. With rust I'm hoping that
> > rustdoc liberally sprinkles links already and we don't have to do this
> > as much.
> >
> > - Short explainers for parameters. For rust this also means type
> > parameters, for those even simplified examples of how drivers are
> > supposed to use them would help a lot in reading docs & understanding
> > concepts.
> >
> > - Ideally links from the rust to the sphinx side to linke relevant
> > chapters together. Often the bigger explanations are in .rst files with
> > DOT graphs (kms has a bunch I've added) or similar, and it doesn't make
> > that much sense to duplicate all that on the rust side I guess. But it
> > needs to be discoverable.
> >
> > This might be more a discussion topic for the rust people than you
> > directly. Still needed for the merge-ready patches eventually.
>
> I don't know much about the doc gen stuff on the Rust side so yeah, this is
> something I need to look into to make it pretty and complete...
From what Miguel has shown I think it's all there already, and the only
missing pieces are the cross-linking at a chapter level from rustdoc to
rst and sphinx to rstdoc too ideally. But I think for most rust wrappers
that will be one link each direction only (e.g. C drm_mm linking to
kernel::drm::MM and other way round and done). So absolutely no problem if
that one item is sorted out post merge once rustdoc/kernel-sphinx are
ready.
> > Refcounting vs borrowing:
> >
> > This is honestly much more the eyebrow raising one than the locking. Very
> > often on the C side these datastructures all work with borrow semantics,
> > and you need to explicitly upgrade to a full reference (kref_get or
> > kref_get_unless_zero, depending whether it's a strong or weak reference)
> > if you need the object outside of the mutex/lock guard section.
> >
> > Again I think for now it's ok, but the sales pitch of rust is that it
> > enables borrow lifetime checking with no runtime cost. Plus viz the vm
> > cleanup example, if you have too many strong backreferences the cleanup
> > flow gets complicated. And it would suck if rust drivers have to add
> > complexity like the openrefcount for the vm example simply because we
> > can't model the borrow semantics well enough to be safe.
> >
> > So not something that's really bad here, but if we need to resort to full
> > refcounting already for simple datastructures then I'm getting a bit
> > worried about how well rust will cope with the really nasty borrowed
> > reference tricks we're playing in other areas.
> >
> > Again more a topic for the rust folks I think than specifically here about
> > drm_mm wrapping. Just to get things going I think this is fine.
>
> Yeeeeah... this is a *specific* problem. Drop.
>
> The Allocator<T> itself is perfectly safe to implement without any locking,
> refcounting, or anything. You just make the methods take &mut self (as they
> already do), the caller can use it with a single reference or wrap it in an
> Arc<Mutex<T>> and share it, or whatever.
>
> The problem is the Node<A, T>. When you Drop that, it has to go back to the
> Allocator. But now you're a different object, so no thread safety
> guarantees. And you need to keep the Allocator alive. So now to make a safe
> abstraction, you need refcounting and a mutex.
>
> Lifetimes just don't work here, sadly. Not for a useful abstraction.
>
> I'd love to hear from the other Rust folks whether they have any better
> ideas...
Hm yeah I think I get the gist of the issue. At time of Drop there's no
allocator reference you can borrow and so you're screwed.
In C we tend to solve that by passing both to the unlink/drop stuff (and
rust could then ensure that we have legit borrows for both), but I guess
that just totally wreaks entire wrapper and makes it really rough to use.
> One thing that *can* be done is making the Drop illegal (Rust can't do this
> "natively" but Linux already has hacks for that, we can make it fail to link
> if the Drop is ever called). Then you'd have to actively return the Node to
> the Allocator with a free function. Since Drop is forbidden, and Node is
> pinned, you'd always have to either return Node objects to the Allocator or
> leak them. You could drop the Allocator before its nodes, but as far as I
> know drm_mm can safely handle that (though it will complain), and then due
> to the previous guarantees the *only* thing you could do with orphan nodes
> is leak their memory, which is safe.
>
> It would work... but it breaks the whole Rust automagic Drop stuff.
Yeah I think I see the challenge ...
> Thinking about this a bit, I think I want the current mutex/arc semantics
> for something like a memory allocator (which is one of my primary use cases
> for drm_mm), since I definitely don't want to be manually returning objects
> to their allocator all over the place, nor have overarching lifetime
> requirements that the allocator outlive its objects for safety (that sounds
> like a can of worms I don't want to open, I'd much rather use a refcount
> even if I "think" I can prove the lifetime bounds ad-hoc). But for something
> like a drm_mm that is tracking VA ranges within a VM with all Nodes held
> internally, maybe I could manage it all internally and have all node
> destruction be handled via an explicit call into the Allocator.
Yeah I think for gpuva we need to do better, but assuming the gpuva
library is in C then rust would just need to encode the safety properties
that (hopefully) the C library guarantees ...
And for any driver that just wants to use some range manager the standard
wrapping leans heavily on the side of "easy to use".
> Maybe the mm abstraction should offer both options? The extra locking can be
> implemented in terms of the base unlocked version I think (perhaps with some
> Deref abuse for ergonomics)... I definitely want to hear more opinions about
> this from other Rust folks, since there are probably other options I haven't
> considered...
I don't think we need the more raw/tricky one, at least not until we have
some serious libraries like gpuva implemented in rust. Or drivers
reimplementing the gpuva stuff in their driver :-)
> Aside: This, and all the other DRM abstractions, were written before the
> pin_init stuff from y86 that is in review right now was ready. That may open
> up more interesting/ergonomic/efficient APIs for some cases, especially
> where Pin and embedding C types into user objects in some way are involved.
> So maybe there's room for improvement here. Just a sidenote.
Ah good to know, and yeah that make open some interesting options.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
^ permalink raw reply [flat|nested] 122+ messages in thread
* Re: [Linaro-mm-sig] Re: [PATCH RFC 07/18] rust: drm: mm: Add DRM MM Range Allocator abstraction
2023-04-06 16:13 ` [Linaro-mm-sig] " Daniel Vetter
@ 2023-04-06 16:39 ` Asahi Lina
0 siblings, 0 replies; 122+ messages in thread
From: Asahi Lina @ 2023-04-06 16:39 UTC (permalink / raw)
To: Daniel Vetter
Cc: Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
David Airlie, Miguel Ojeda, Alex Gaynor, Wedson Almeida Filho,
Boqun Feng, Gary Guo, Björn Roy Baron, Sumit Semwal,
Christian König, Luben Tuikov, Jarkko Sakkinen, Dave Hansen,
Alyssa Rosenzweig, Karol Herbst, Ella Stanforth, Faith Ekstrand,
Mary, linux-kernel, dri-devel, rust-for-linux, linux-media,
linaro-mm-sig, linux-sgx, asahi
On 07/04/2023 01.13, Daniel Vetter wrote:
> On Fri, Apr 07, 2023 at 12:53:47AM +0900, Asahi Lina wrote:
>> On 06/04/2023 23.15, Daniel Vetter wrote:
>>> On Tue, Mar 07, 2023 at 11:25:32PM +0900, Asahi Lina wrote:
>>>> drm_mm provides a simple range allocator, useful for managing virtual
>>>> address ranges. Add a Rust abstraction to expose this module to Rust
>>>> drivers.
>>>>
>>>> Signed-off-by: Asahi Lina <lina@asahilina.net>
>>>
>>> In the cover letter you mentioned the design open about embedded the lock
>>> into the rust wrappers.
>>>
>>> I think for a first step that's perfectly fine.
>>>
>>> Longer term we might want to ramp up some "proof of locking"
>>> infrastructure in Rust, where callers can supply a lock guard and ideally
>>> rust validates at compile time that it's for the right type, and at
>>> runtime (like lockdep) that it's consistent and the callers don't mix up
>>> locks (like using different locks for the same drm_mm allocator).
>>
>> That proof-of-lock tuff works in Rust too as far as I know.
>>
>> But the general thread safety story in Rust is much simpler, you just use
>> methods that take &mut self when locking is the caller's responsibility.
>> That effectively implies that there can only be one reference that can call
>> those methods at any given time, thanks to the borrow checker. Shared
>> references only give you &self, a locked Mutex upgrades that to &mut self,
>> and that's how you get proof of locking at compile time, through and
>> through, not just for the type but for the specific object.
>
> Hm that still has the problem of making sure that you supply the right
> lock (for generic abstractions like drm_mm or drm/sched where the lock is
> supplied by the driver.
No no, I mean you don't have to supply the lock at all. The idea is that
if you have a mutable reference to the object *at all* then Rust says
that's effectively interlocked, whether you achieve that with an actual
lock or just by not sharing the object to begin with.
This is the standard pattern in Rust. Thread-safe methods take &self,
and you can call those from multiple threads at once. Thread-unsafe
methods take &mut self, and you can only call them from one thread at
once. Mutex is one mechanism that allows you to upgrade a shared &self
to a &mut self (while holding the lock). The actual object doesn't know
anything about mutexes or locking, it just relies on the more
fundamental property that Rust says that if you have a &mut obj,
absolutely nobody else does, at any given time, by definition.
(And then everything also needs to impl Send + Sync for this to work
across threads, but that's usually what you want)
Basically if there were to exist a Rust abstraction/object/anything that
allows two threads to get ahold of a &mut to the same object at the same
time without using unsafe, that abstraction/etc would be broken and
unsound (and necessarily have to involve bad unsafe code within, because
you can't do that with just safe code, the borrow checker stops you),
and the state of affairs of two threads having such a reference is
outright undefined behavior in the language model.
> Once we have the lock then yeah borrow checker makes sure you can't screw
> up, worst case needs a PhantomData (I guess) as toke of proof to pass
> around the borrowed lifetime (If I got that right from your use of
> PhantomData in the sched wrappers).
Ah, PhantomData is just a hack because Rust wants you to use all type
parameters inside structs even when you don't actually need them for
anything because they only have meaning to the abstraction itself.
Without it it won't compile. Something something deep type system black
magic rules (I'm pretty sure this requirement isn't gratuitous but I
don't know what the whole story is here).
The lock does give you a Guard you could pass somewhere as proof, which
itself contains a lifetime that ties it to the Mutex, but more
importantly that Guard implements DerefMut to give you a &mut to
whatever is inside the Mutex, and *that* mutable reference is the proof
that you are the sole execution context with the right to access that
one particular object. At that point the Guard doesn't matter, and
lifetimes tie everything together so you can't stash that &mut somewhere
else or anything like that to break the rules (modulo unsafe code, of
course!).
>
>>> There's a lot of libraries in the kernel that have this "caller ensures
>>> locking" pattern. drm/sched also has these requirements.
>>
>> Yup, that all usually maps nicely to &mut self in Rust... except for the
>> issue below.
>>
>>> There's two other things I'd like to bring up on this patch though, just
>>> because it's a good example. But they're both really general points that
>>> apply for all the rust wrappers.
>>>
>>> Documentation:
>>>
>>> In drm we try to document all the interfaces that drivers use with formal
>>> docs. Yes there's some areas that are not great for historical reasons,
>>> but for new stuff and new wrappers we're really trying:
>>>
>>> - This helps in telling internal (even across .c files or in rust across
>>> modules within a crate) from stuff drivers access. Sure you have static
>>> in C or pub in rust, but that doesn't tell you whether it's public all
>>> the way to drivers.
>>>
>>> - ideally docs have a short intro section that explains the main concepts
>>> and links to the main data structures and functions. Just to give
>>> readers a good starting point to explore.
>>>
>>> - Linking all the things, so that readers can connect the different parts.
>>> This is really important in C where e.g. get/put() or any such function
>>> pairs all needed to be linked together. With rust I'm hoping that
>>> rustdoc liberally sprinkles links already and we don't have to do this
>>> as much.
>>>
>>> - Short explainers for parameters. For rust this also means type
>>> parameters, for those even simplified examples of how drivers are
>>> supposed to use them would help a lot in reading docs & understanding
>>> concepts.
>>>
>>> - Ideally links from the rust to the sphinx side to linke relevant
>>> chapters together. Often the bigger explanations are in .rst files with
>>> DOT graphs (kms has a bunch I've added) or similar, and it doesn't make
>>> that much sense to duplicate all that on the rust side I guess. But it
>>> needs to be discoverable.
>>>
>>> This might be more a discussion topic for the rust people than you
>>> directly. Still needed for the merge-ready patches eventually.
>>
>> I don't know much about the doc gen stuff on the Rust side so yeah, this is
>> something I need to look into to make it pretty and complete...
>
> From what Miguel has shown I think it's all there already, and the only
> missing pieces are the cross-linking at a chapter level from rustdoc to
> rst and sphinx to rstdoc too ideally. But I think for most rust wrappers
> that will be one link each direction only (e.g. C drm_mm linking to
> kernel::drm::MM and other way round and done). So absolutely no problem if
> that one item is sorted out post merge once rustdoc/kernel-sphinx are
> ready.
>
>>> Refcounting vs borrowing:
>>>
>>> This is honestly much more the eyebrow raising one than the locking. Very
>>> often on the C side these datastructures all work with borrow semantics,
>>> and you need to explicitly upgrade to a full reference (kref_get or
>>> kref_get_unless_zero, depending whether it's a strong or weak reference)
>>> if you need the object outside of the mutex/lock guard section.
>>>
>>> Again I think for now it's ok, but the sales pitch of rust is that it
>>> enables borrow lifetime checking with no runtime cost. Plus viz the vm
>>> cleanup example, if you have too many strong backreferences the cleanup
>>> flow gets complicated. And it would suck if rust drivers have to add
>>> complexity like the openrefcount for the vm example simply because we
>>> can't model the borrow semantics well enough to be safe.
>>>
>>> So not something that's really bad here, but if we need to resort to full
>>> refcounting already for simple datastructures then I'm getting a bit
>>> worried about how well rust will cope with the really nasty borrowed
>>> reference tricks we're playing in other areas.
>>>
>>> Again more a topic for the rust folks I think than specifically here about
>>> drm_mm wrapping. Just to get things going I think this is fine.
>>
>> Yeeeeah... this is a *specific* problem. Drop.
>>
>> The Allocator<T> itself is perfectly safe to implement without any locking,
>> refcounting, or anything. You just make the methods take &mut self (as they
>> already do), the caller can use it with a single reference or wrap it in an
>> Arc<Mutex<T>> and share it, or whatever.
>>
>> The problem is the Node<A, T>. When you Drop that, it has to go back to the
>> Allocator. But now you're a different object, so no thread safety
>> guarantees. And you need to keep the Allocator alive. So now to make a safe
>> abstraction, you need refcounting and a mutex.
>>
>> Lifetimes just don't work here, sadly. Not for a useful abstraction.
>>
>> I'd love to hear from the other Rust folks whether they have any better
>> ideas...
>
> Hm yeah I think I get the gist of the issue. At time of Drop there's no
> allocator reference you can borrow and so you're screwed.
>
> In C we tend to solve that by passing both to the unlink/drop stuff (and
> rust could then ensure that we have legit borrows for both), but I guess
> that just totally wreaks entire wrapper and makes it really rough to use.
Yup, that's the issue ^^;;
>
>> One thing that *can* be done is making the Drop illegal (Rust can't do this
>> "natively" but Linux already has hacks for that, we can make it fail to link
>> if the Drop is ever called). Then you'd have to actively return the Node to
>> the Allocator with a free function. Since Drop is forbidden, and Node is
>> pinned, you'd always have to either return Node objects to the Allocator or
>> leak them. You could drop the Allocator before its nodes, but as far as I
>> know drm_mm can safely handle that (though it will complain), and then due
>> to the previous guarantees the *only* thing you could do with orphan nodes
>> is leak their memory, which is safe.
>>
>> It would work... but it breaks the whole Rust automagic Drop stuff.
>
> Yeah I think I see the challenge ...
>
>> Thinking about this a bit, I think I want the current mutex/arc semantics
>> for something like a memory allocator (which is one of my primary use cases
>> for drm_mm), since I definitely don't want to be manually returning objects
>> to their allocator all over the place, nor have overarching lifetime
>> requirements that the allocator outlive its objects for safety (that sounds
>> like a can of worms I don't want to open, I'd much rather use a refcount
>> even if I "think" I can prove the lifetime bounds ad-hoc). But for something
>> like a drm_mm that is tracking VA ranges within a VM with all Nodes held
>> internally, maybe I could manage it all internally and have all node
>> destruction be handled via an explicit call into the Allocator.
>
> Yeah I think for gpuva we need to do better, but assuming the gpuva
> library is in C then rust would just need to encode the safety properties
> that (hopefully) the C library guarantees ...
Yeah, if this is going to be common C code using drm_mm then it can
provide whatever safety properties it wants and use drm_mm in ways not
possible with the Rust abstraction, of course.
> And for any driver that just wants to use some range manager the standard
> wrapping leans heavily on the side of "easy to use".
>
>> Maybe the mm abstraction should offer both options? The extra locking can be
>> implemented in terms of the base unlocked version I think (perhaps with some
>> Deref abuse for ergonomics)... I definitely want to hear more opinions about
>> this from other Rust folks, since there are probably other options I haven't
>> considered...
>
> I don't think we need the more raw/tricky one, at least not until we have
> some serious libraries like gpuva implemented in rust. Or drivers
> reimplementing the gpuva stuff in their driver :-)
It only just hit me that gpuva is an actual thing that's in RFC. Sounds
like I should give it a shot when I do the vm_bind stuff instead of
reinventing that wheel (which was my original plan)... sorry if I've
been a bit slow here.
>> Aside: This, and all the other DRM abstractions, were written before the
>> pin_init stuff from y86 that is in review right now was ready. That may open
>> up more interesting/ergonomic/efficient APIs for some cases, especially
>> where Pin and embedding C types into user objects in some way are involved.
>> So maybe there's room for improvement here. Just a sidenote.
>
> Ah good to know, and yeah that make open some interesting options.
> -Daniel
~~ Lina
^ permalink raw reply [flat|nested] 122+ messages in thread
* [PATCH RFC 08/18] rust: dma_fence: Add DMA Fence abstraction
2023-03-07 14:25 [PATCH RFC 00/18] Rust DRM subsystem abstractions (& preview AGX driver) Asahi Lina
` (6 preceding siblings ...)
2023-03-07 14:25 ` [PATCH RFC 07/18] rust: drm: mm: Add DRM MM Range Allocator abstraction Asahi Lina
@ 2023-03-07 14:25 ` Asahi Lina
2023-04-05 11:10 ` Daniel Vetter
2023-03-07 14:25 ` [PATCH RFC 09/18] rust: drm: syncobj: Add DRM Sync Object abstraction Asahi Lina
` (10 subsequent siblings)
18 siblings, 1 reply; 122+ messages in thread
From: Asahi Lina @ 2023-03-07 14:25 UTC (permalink / raw)
To: Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
David Airlie, Daniel Vetter, Miguel Ojeda, Alex Gaynor,
Wedson Almeida Filho, Boqun Feng, Gary Guo, Björn Roy Baron,
Sumit Semwal, Christian König, Luben Tuikov,
Jarkko Sakkinen, Dave Hansen
Cc: Alyssa Rosenzweig, Karol Herbst, Ella Stanforth, Faith Ekstrand,
Mary, linux-kernel, dri-devel, rust-for-linux, linux-media,
linaro-mm-sig, linux-sgx, asahi, Asahi Lina
DMA fences are the internal synchronization primitive used for DMA
operations like GPU rendering, video en/decoding, etc. Add an
abstraction to allow Rust drivers to interact with this subsystem.
Note: This uses a raw spinlock living next to the fence, since we do
not interact with it other than for initialization.
TODO: Expose this to the user at some point with a safe abstraction.
Signed-off-by: Asahi Lina <lina@asahilina.net>
---
rust/bindings/bindings_helper.h | 2 +
rust/helpers.c | 53 ++++
rust/kernel/dma_fence.rs | 532 ++++++++++++++++++++++++++++++++++++++++
rust/kernel/lib.rs | 2 +
4 files changed, 589 insertions(+)
diff --git a/rust/bindings/bindings_helper.h b/rust/bindings/bindings_helper.h
index 9f152d373df8..705af292a5b4 100644
--- a/rust/bindings/bindings_helper.h
+++ b/rust/bindings/bindings_helper.h
@@ -14,6 +14,8 @@
#include <drm/drm_ioctl.h>
#include <linux/delay.h>
#include <linux/device.h>
+#include <linux/dma-fence.h>
+#include <linux/dma-fence-chain.h>
#include <linux/dma-mapping.h>
#include <linux/fs.h>
#include <linux/ioctl.h>
diff --git a/rust/helpers.c b/rust/helpers.c
index 388ff1100ea5..8e906a7a7d8a 100644
--- a/rust/helpers.c
+++ b/rust/helpers.c
@@ -23,6 +23,8 @@
#include <linux/bug.h>
#include <linux/build_bug.h>
#include <linux/device.h>
+#include <linux/dma-fence.h>
+#include <linux/dma-fence-chain.h>
#include <linux/dma-mapping.h>
#include <linux/err.h>
#include <linux/errname.h>
@@ -30,6 +32,7 @@
#include <linux/of.h>
#include <linux/of_device.h>
#include <linux/platform_device.h>
+#include <linux/spinlock.h>
#include <linux/rcupdate.h>
#include <linux/refcount.h>
#include <linux/xarray.h>
@@ -388,6 +391,56 @@ int rust_helper_sg_dma_len(const struct scatterlist *sg)
}
EXPORT_SYMBOL_GPL(rust_helper_sg_dma_len);
+void rust_helper___spin_lock_init(spinlock_t *lock, const char *name,
+ struct lock_class_key *key)
+{
+#ifdef CONFIG_DEBUG_SPINLOCK
+# ifndef CONFIG_PREEMPT_RT
+ __raw_spin_lock_init(spinlock_check(lock), name, key, LD_WAIT_CONFIG);
+# else
+ rt_mutex_base_init(&lock->lock);
+ __rt_spin_lock_init(lock, name, key, false);
+# endif
+#else
+ spin_lock_init(lock);
+#endif
+}
+EXPORT_SYMBOL_GPL(rust_helper___spin_lock_init);
+
+#ifdef CONFIG_DMA_SHARED_BUFFER
+
+void rust_helper_dma_fence_get(struct dma_fence *fence)
+{
+ dma_fence_get(fence);
+}
+EXPORT_SYMBOL_GPL(rust_helper_dma_fence_get);
+
+void rust_helper_dma_fence_put(struct dma_fence *fence)
+{
+ dma_fence_put(fence);
+}
+EXPORT_SYMBOL_GPL(rust_helper_dma_fence_put);
+
+struct dma_fence_chain *rust_helper_dma_fence_chain_alloc(void)
+{
+ return dma_fence_chain_alloc();
+}
+EXPORT_SYMBOL_GPL(rust_helper_dma_fence_chain_alloc);
+
+void rust_helper_dma_fence_chain_free(struct dma_fence_chain *chain)
+{
+ dma_fence_chain_free(chain);
+}
+EXPORT_SYMBOL_GPL(rust_helper_dma_fence_chain_free);
+
+void rust_helper_dma_fence_set_error(struct dma_fence *fence, int error)
+{
+ dma_fence_set_error(fence, error);
+}
+EXPORT_SYMBOL_GPL(rust_helper_dma_fence_set_error);
+
+#endif
+
#ifdef CONFIG_DRM
void rust_helper_drm_gem_object_get(struct drm_gem_object *obj)
diff --git a/rust/kernel/dma_fence.rs b/rust/kernel/dma_fence.rs
new file mode 100644
index 000000000000..ca93380d9da2
--- /dev/null
+++ b/rust/kernel/dma_fence.rs
@@ -0,0 +1,532 @@
+// SPDX-License-Identifier: GPL-2.0
+
+//! DMA fence abstraction.
+//!
+//! C header: [`include/linux/dma_fence.h`](../../include/linux/dma_fence.h)
+
+use crate::{
+ bindings,
+ error::{to_result, Result},
+ prelude::*,
+ sync::LockClassKey,
+ types::Opaque,
+};
+use core::fmt::Write;
+use core::ops::{Deref, DerefMut};
+use core::ptr::addr_of_mut;
+use core::sync::atomic::{AtomicU64, Ordering};
+
+/// Any kind of DMA Fence Object
+///
+/// # Invariants
+/// raw() returns a valid pointer to a dma_fence and we own a reference to it.
+pub trait RawDmaFence: crate::private::Sealed {
+ /// Returns the raw `struct dma_fence` pointer.
+ fn raw(&self) -> *mut bindings::dma_fence;
+
+ /// Returns the raw `struct dma_fence` pointer and consumes the object.
+ ///
+ /// The caller is responsible for dropping the reference.
+ fn into_raw(self) -> *mut bindings::dma_fence
+ where
+ Self: Sized,
+ {
+ let ptr = self.raw();
+ core::mem::forget(self);
+ ptr
+ }
+
+ /// Advances this fence to the chain node which will signal this sequence number.
+ /// If no sequence number is provided, this returns `self` again.
+ fn chain_find_seqno(self, seqno: u64) -> Result<Fence>
+ where
+ Self: Sized,
+ {
+ let mut ptr = self.into_raw();
+
+ // SAFETY: This will safely fail if this DmaFence is not a chain.
+ // `ptr` is valid per the type invariant.
+ let ret = unsafe { bindings::dma_fence_chain_find_seqno(&mut ptr, seqno) };
+
+ if ret != 0 {
+ // SAFETY: This is either an owned reference or NULL, dma_fence_put can handle both.
+ unsafe { bindings::dma_fence_put(ptr) };
+ Err(Error::from_kernel_errno(ret))
+ } else if ptr.is_null() {
+ Err(EINVAL) // When can this happen?
+ } else {
+ // SAFETY: ptr is valid and non-NULL as checked above.
+ Ok(unsafe { Fence::from_raw(ptr) })
+ }
+ }
+
+ /// Signal completion of this fence
+ fn signal(&self) -> Result {
+ to_result(unsafe { bindings::dma_fence_signal(self.raw()) })
+ }
+
+ /// Set the error flag on this fence
+ fn set_error(&self, err: Error) {
+ unsafe { bindings::dma_fence_set_error(self.raw(), err.to_kernel_errno()) };
+ }
+}
+
+/// A generic DMA Fence Object
+///
+/// # Invariants
+/// ptr is a valid pointer to a dma_fence and we own a reference to it.
+pub struct Fence {
+ ptr: *mut bindings::dma_fence,
+}
+
+impl Fence {
+ /// Create a new Fence object from a raw pointer to a dma_fence.
+ ///
+ /// # Safety
+ /// The caller must own a reference to the dma_fence, which is transferred to the new object.
+ pub(crate) unsafe fn from_raw(ptr: *mut bindings::dma_fence) -> Fence {
+ Fence { ptr }
+ }
+
+ /// Create a new Fence object from a raw pointer to a dma_fence.
+ ///
+ /// # Safety
+ /// Takes a borrowed reference to the dma_fence, and increments the reference count.
+ pub(crate) unsafe fn get_raw(ptr: *mut bindings::dma_fence) -> Fence {
+ // SAFETY: Pointer is valid per the safety contract
+ unsafe { bindings::dma_fence_get(ptr) };
+ Fence { ptr }
+ }
+
+ /// Create a new Fence object from a RawDmaFence.
+ pub fn from_fence(fence: &dyn RawDmaFence) -> Fence {
+ // SAFETY: Pointer is valid per the RawDmaFence contract
+ unsafe { Self::get_raw(fence.raw()) }
+ }
+}
+
+impl crate::private::Sealed for Fence {}
+
+impl RawDmaFence for Fence {
+ fn raw(&self) -> *mut bindings::dma_fence {
+ self.ptr
+ }
+}
+
+impl Drop for Fence {
+ fn drop(&mut self) {
+ // SAFETY: We own a reference to this syncobj.
+ unsafe { bindings::dma_fence_put(self.ptr) };
+ }
+}
+
+impl Clone for Fence {
+ fn clone(&self) -> Self {
+ // SAFETY: `ptr` is valid per the type invariant and we own a reference to it.
+ unsafe {
+ bindings::dma_fence_get(self.ptr);
+ Self::from_raw(self.ptr)
+ }
+ }
+}
+
+unsafe impl Sync for Fence {}
+unsafe impl Send for Fence {}
+
+/// Trait which must be implemented by driver-specific fence objects.
+#[vtable]
+pub trait FenceOps: Sized + Send + Sync {
+ /// True if this dma_fence implementation uses 64bit seqno, false otherwise.
+ const USE_64BIT_SEQNO: bool;
+
+ /// Returns the driver name. This is a callback to allow drivers to compute the name at
+ /// runtime, without having it to store permanently for each fence, or build a cache of
+ /// some sort.
+ fn get_driver_name<'a>(self: &'a FenceObject<Self>) -> &'a CStr;
+
+ /// Return the name of the context this fence belongs to. This is a callback to allow drivers
+ /// to compute the name at runtime, without having it to store permanently for each fence, or
+ /// build a cache of some sort.
+ fn get_timeline_name<'a>(self: &'a FenceObject<Self>) -> &'a CStr;
+
+ /// Enable software signaling of fence.
+ fn enable_signaling(self: &FenceObject<Self>) -> bool {
+ false
+ }
+
+ /// Peek whether the fence is signaled, as a fastpath optimization for e.g. dma_fence_wait() or
+ /// dma_fence_add_callback().
+ fn signaled(self: &FenceObject<Self>) -> bool {
+ false
+ }
+
+ /// Callback to fill in free-form debug info specific to this fence, like the sequence number.
+ fn fence_value_str(self: &FenceObject<Self>, _output: &mut dyn Write) {}
+
+ /// Fills in the current value of the timeline as a string, like the sequence number. Note that
+ /// the specific fence passed to this function should not matter, drivers should only use it to
+ /// look up the corresponding timeline structures.
+ fn timeline_value_str(self: &FenceObject<Self>, _output: &mut dyn Write) {}
+}
+
+unsafe extern "C" fn get_driver_name_cb<T: FenceOps>(
+ fence: *mut bindings::dma_fence,
+) -> *const core::ffi::c_char {
+ // SAFETY: All of our fences are FenceObject<T>.
+ let p = crate::container_of!(fence, FenceObject<T>, fence) as *mut FenceObject<T>;
+
+ // SAFETY: The caller is responsible for passing a valid dma_fence subtype
+ T::get_driver_name(unsafe { &mut *p }).as_char_ptr()
+}
+
+unsafe extern "C" fn get_timeline_name_cb<T: FenceOps>(
+ fence: *mut bindings::dma_fence,
+) -> *const core::ffi::c_char {
+ // SAFETY: All of our fences are FenceObject<T>.
+ let p = crate::container_of!(fence, FenceObject<T>, fence) as *mut FenceObject<T>;
+
+ // SAFETY: The caller is responsible for passing a valid dma_fence subtype
+ T::get_timeline_name(unsafe { &mut *p }).as_char_ptr()
+}
+
+unsafe extern "C" fn enable_signaling_cb<T: FenceOps>(fence: *mut bindings::dma_fence) -> bool {
+ // SAFETY: All of our fences are FenceObject<T>.
+ let p = crate::container_of!(fence, FenceObject<T>, fence) as *mut FenceObject<T>;
+
+ // SAFETY: The caller is responsible for passing a valid dma_fence subtype
+ T::enable_signaling(unsafe { &mut *p })
+}
+
+unsafe extern "C" fn signaled_cb<T: FenceOps>(fence: *mut bindings::dma_fence) -> bool {
+ // SAFETY: All of our fences are FenceObject<T>.
+ let p = crate::container_of!(fence, FenceObject<T>, fence) as *mut FenceObject<T>;
+
+ // SAFETY: The caller is responsible for passing a valid dma_fence subtype
+ T::signaled(unsafe { &mut *p })
+}
+
+unsafe extern "C" fn release_cb<T: FenceOps>(fence: *mut bindings::dma_fence) {
+ // SAFETY: All of our fences are FenceObject<T>.
+ let p = crate::container_of!(fence, FenceObject<T>, fence) as *mut FenceObject<T>;
+
+ // SAFETY: p is never used after this
+ unsafe {
+ core::ptr::drop_in_place(&mut (*p).inner);
+ }
+
+ // SAFETY: All of our fences are allocated using kmalloc, so this is safe.
+ unsafe { bindings::dma_fence_free(fence) };
+}
+
+unsafe extern "C" fn fence_value_str_cb<T: FenceOps>(
+ fence: *mut bindings::dma_fence,
+ string: *mut core::ffi::c_char,
+ size: core::ffi::c_int,
+) {
+ let size: usize = size.try_into().unwrap_or(0);
+
+ if size == 0 {
+ return;
+ }
+
+ // SAFETY: All of our fences are FenceObject<T>.
+ let p = crate::container_of!(fence, FenceObject<T>, fence) as *mut FenceObject<T>;
+
+ // SAFETY: The caller is responsible for the validity of string/size
+ let mut f = unsafe { crate::str::Formatter::from_buffer(string as *mut _, size) };
+
+ // SAFETY: The caller is responsible for passing a valid dma_fence subtype
+ T::fence_value_str(unsafe { &mut *p }, &mut f);
+ let _ = f.write_str("\0");
+
+ // SAFETY: `size` is at least 1 per the check above
+ unsafe { *string.add(size - 1) = 0 };
+}
+
+unsafe extern "C" fn timeline_value_str_cb<T: FenceOps>(
+ fence: *mut bindings::dma_fence,
+ string: *mut core::ffi::c_char,
+ size: core::ffi::c_int,
+) {
+ let size: usize = size.try_into().unwrap_or(0);
+
+ if size == 0 {
+ return;
+ }
+
+ // SAFETY: All of our fences are FenceObject<T>.
+ let p = crate::container_of!(fence, FenceObject<T>, fence) as *mut FenceObject<T>;
+
+ // SAFETY: The caller is responsible for the validity of string/size
+ let mut f = unsafe { crate::str::Formatter::from_buffer(string as *mut _, size) };
+
+ // SAFETY: The caller is responsible for passing a valid dma_fence subtype
+ T::timeline_value_str(unsafe { &mut *p }, &mut f);
+ let _ = f.write_str("\0");
+
+ // SAFETY: `size` is at least 1 per the check above
+ unsafe { *string.add(size - 1) = 0 };
+}
+
+// Allow FenceObject<Self> to be used as a self argument, for ergonomics
+impl<T: FenceOps> core::ops::Receiver for FenceObject<T> {}
+
+/// A driver-specific DMA Fence Object
+///
+/// # Invariants
+/// ptr is a valid pointer to a dma_fence and we own a reference to it.
+#[repr(C)]
+pub struct FenceObject<T: FenceOps> {
+ fence: bindings::dma_fence,
+ lock: Opaque<bindings::spinlock>,
+ inner: T,
+}
+
+impl<T: FenceOps> FenceObject<T> {
+ const SIZE: usize = core::mem::size_of::<Self>();
+
+ const VTABLE: bindings::dma_fence_ops = bindings::dma_fence_ops {
+ use_64bit_seqno: T::USE_64BIT_SEQNO,
+ get_driver_name: Some(get_driver_name_cb::<T>),
+ get_timeline_name: Some(get_timeline_name_cb::<T>),
+ enable_signaling: if T::HAS_ENABLE_SIGNALING {
+ Some(enable_signaling_cb::<T>)
+ } else {
+ None
+ },
+ signaled: if T::HAS_SIGNALED {
+ Some(signaled_cb::<T>)
+ } else {
+ None
+ },
+ wait: None, // Deprecated
+ release: Some(release_cb::<T>),
+ fence_value_str: if T::HAS_FENCE_VALUE_STR {
+ Some(fence_value_str_cb::<T>)
+ } else {
+ None
+ },
+ timeline_value_str: if T::HAS_TIMELINE_VALUE_STR {
+ Some(timeline_value_str_cb::<T>)
+ } else {
+ None
+ },
+ };
+}
+
+impl<T: FenceOps> Deref for FenceObject<T> {
+ type Target = T;
+
+ fn deref(&self) -> &T {
+ &self.inner
+ }
+}
+
+impl<T: FenceOps> DerefMut for FenceObject<T> {
+ fn deref_mut(&mut self) -> &mut T {
+ &mut self.inner
+ }
+}
+
+impl<T: FenceOps> crate::private::Sealed for FenceObject<T> {}
+impl<T: FenceOps> RawDmaFence for FenceObject<T> {
+ fn raw(&self) -> *mut bindings::dma_fence {
+ &self.fence as *const _ as *mut _
+ }
+}
+
+/// A unique reference to a driver-specific fence object
+pub struct UniqueFence<T: FenceOps>(*mut FenceObject<T>);
+
+impl<T: FenceOps> Deref for UniqueFence<T> {
+ type Target = FenceObject<T>;
+
+ fn deref(&self) -> &FenceObject<T> {
+ unsafe { &*self.0 }
+ }
+}
+
+impl<T: FenceOps> DerefMut for UniqueFence<T> {
+ fn deref_mut(&mut self) -> &mut FenceObject<T> {
+ unsafe { &mut *self.0 }
+ }
+}
+
+impl<T: FenceOps> crate::private::Sealed for UniqueFence<T> {}
+impl<T: FenceOps> RawDmaFence for UniqueFence<T> {
+ fn raw(&self) -> *mut bindings::dma_fence {
+ unsafe { addr_of_mut!((*self.0).fence) }
+ }
+}
+
+impl<T: FenceOps> From<UniqueFence<T>> for UserFence<T> {
+ fn from(value: UniqueFence<T>) -> Self {
+ let ptr = value.0;
+ core::mem::forget(value);
+
+ UserFence(ptr)
+ }
+}
+
+impl<T: FenceOps> Drop for UniqueFence<T> {
+ fn drop(&mut self) {
+ // SAFETY: We own a reference to this fence.
+ unsafe { bindings::dma_fence_put(self.raw()) };
+ }
+}
+
+unsafe impl<T: FenceOps> Sync for UniqueFence<T> {}
+unsafe impl<T: FenceOps> Send for UniqueFence<T> {}
+
+/// A shared reference to a driver-specific fence object
+pub struct UserFence<T: FenceOps>(*mut FenceObject<T>);
+
+impl<T: FenceOps> Deref for UserFence<T> {
+ type Target = FenceObject<T>;
+
+ fn deref(&self) -> &FenceObject<T> {
+ unsafe { &*self.0 }
+ }
+}
+
+impl<T: FenceOps> Clone for UserFence<T> {
+ fn clone(&self) -> Self {
+ // SAFETY: `ptr` is valid per the type invariant and we own a reference to it.
+ unsafe {
+ bindings::dma_fence_get(self.raw());
+ Self(self.0)
+ }
+ }
+}
+
+impl<T: FenceOps> crate::private::Sealed for UserFence<T> {}
+impl<T: FenceOps> RawDmaFence for UserFence<T> {
+ fn raw(&self) -> *mut bindings::dma_fence {
+ unsafe { addr_of_mut!((*self.0).fence) }
+ }
+}
+
+impl<T: FenceOps> Drop for UserFence<T> {
+ fn drop(&mut self) {
+ // SAFETY: We own a reference to this fence.
+ unsafe { bindings::dma_fence_put(self.raw()) };
+ }
+}
+
+unsafe impl<T: FenceOps> Sync for UserFence<T> {}
+unsafe impl<T: FenceOps> Send for UserFence<T> {}
+
+/// An array of fence contexts, out of which fences can be created.
+pub struct FenceContexts {
+ start: u64,
+ count: u32,
+ seqnos: Vec<AtomicU64>,
+ lock_name: &'static CStr,
+ lock_key: &'static LockClassKey,
+}
+
+impl FenceContexts {
+ /// Create a new set of fence contexts.
+ pub fn new(
+ count: u32,
+ name: &'static CStr,
+ key: &'static LockClassKey,
+ ) -> Result<FenceContexts> {
+ let mut seqnos: Vec<AtomicU64> = Vec::new();
+
+ seqnos.try_reserve(count as usize)?;
+
+ for _ in 0..count {
+ seqnos.try_push(Default::default())?;
+ }
+
+ let start = unsafe { bindings::dma_fence_context_alloc(count as core::ffi::c_uint) };
+
+ Ok(FenceContexts {
+ start,
+ count,
+ seqnos,
+ lock_name: name,
+ lock_key: key,
+ })
+ }
+
+ /// Create a new fence in a given context index.
+ pub fn new_fence<T: FenceOps>(&self, context: u32, inner: T) -> Result<UniqueFence<T>> {
+ if context > self.count {
+ return Err(EINVAL);
+ }
+
+ let p = unsafe {
+ bindings::krealloc(
+ core::ptr::null_mut(),
+ FenceObject::<T>::SIZE,
+ bindings::GFP_KERNEL | bindings::__GFP_ZERO,
+ ) as *mut FenceObject<T>
+ };
+
+ if p.is_null() {
+ return Err(ENOMEM);
+ }
+
+ let seqno = self.seqnos[context as usize].fetch_add(1, Ordering::Relaxed);
+
+ // SAFETY: The pointer is valid, so pointers to members are too.
+ // After this, all fields are initialized.
+ unsafe {
+ addr_of_mut!((*p).inner).write(inner);
+ bindings::__spin_lock_init(
+ addr_of_mut!((*p).lock) as *mut _,
+ self.lock_name.as_char_ptr(),
+ self.lock_key.get(),
+ );
+ bindings::dma_fence_init(
+ addr_of_mut!((*p).fence),
+ &FenceObject::<T>::VTABLE,
+ addr_of_mut!((*p).lock) as *mut _,
+ self.start + context as u64,
+ seqno,
+ );
+ };
+
+ Ok(UniqueFence(p))
+ }
+}
+
+/// A DMA Fence Chain Object
+///
+/// # Invariants
+/// ptr is a valid pointer to a dma_fence_chain which we own.
+pub struct FenceChain {
+ ptr: *mut bindings::dma_fence_chain,
+}
+
+impl FenceChain {
+ /// Create a new DmaFenceChain object.
+ pub fn new() -> Result<Self> {
+ // SAFETY: This function is safe to call and takes no arguments.
+ let ptr = unsafe { bindings::dma_fence_chain_alloc() };
+
+ if ptr.is_null() {
+ Err(ENOMEM)
+ } else {
+ Ok(FenceChain { ptr })
+ }
+ }
+
+ /// Convert the DmaFenceChain into the underlying raw pointer.
+ ///
+ /// This assumes the caller will take ownership of the object.
+ pub(crate) fn into_raw(self) -> *mut bindings::dma_fence_chain {
+ let ptr = self.ptr;
+ core::mem::forget(self);
+ ptr
+ }
+}
+
+impl Drop for FenceChain {
+ fn drop(&mut self) {
+ // SAFETY: We own this dma_fence_chain.
+ unsafe { bindings::dma_fence_chain_free(self.ptr) };
+ }
+}
diff --git a/rust/kernel/lib.rs b/rust/kernel/lib.rs
index cb23d24c6718..31866069e0bc 100644
--- a/rust/kernel/lib.rs
+++ b/rust/kernel/lib.rs
@@ -36,6 +36,8 @@ mod allocator;
mod build_assert;
pub mod delay;
pub mod device;
+#[cfg(CONFIG_DMA_SHARED_BUFFER)]
+pub mod dma_fence;
pub mod driver;
#[cfg(CONFIG_RUST_DRM)]
pub mod drm;
--
2.35.1
^ permalink raw reply related [flat|nested] 122+ messages in thread* Re: [PATCH RFC 08/18] rust: dma_fence: Add DMA Fence abstraction
2023-03-07 14:25 ` [PATCH RFC 08/18] rust: dma_fence: Add DMA Fence abstraction Asahi Lina
@ 2023-04-05 11:10 ` Daniel Vetter
0 siblings, 0 replies; 122+ messages in thread
From: Daniel Vetter @ 2023-04-05 11:10 UTC (permalink / raw)
To: Asahi Lina
Cc: Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
David Airlie, Daniel Vetter, Miguel Ojeda, Alex Gaynor,
Wedson Almeida Filho, Boqun Feng, Gary Guo, Björn Roy Baron,
Sumit Semwal, Christian König, Luben Tuikov,
Jarkko Sakkinen, Dave Hansen, Alyssa Rosenzweig, Karol Herbst,
Ella Stanforth, Faith Ekstrand, Mary, linux-kernel, dri-devel,
rust-for-linux, linux-media, linaro-mm-sig, linux-sgx, asahi
On Tue, Mar 07, 2023 at 11:25:33PM +0900, Asahi Lina wrote:
> DMA fences are the internal synchronization primitive used for DMA
> operations like GPU rendering, video en/decoding, etc. Add an
> abstraction to allow Rust drivers to interact with this subsystem.
>
> Note: This uses a raw spinlock living next to the fence, since we do
> not interact with it other than for initialization.
> TODO: Expose this to the user at some point with a safe abstraction.
>
> Signed-off-by: Asahi Lina <lina@asahilina.net>
> ---
> rust/bindings/bindings_helper.h | 2 +
> rust/helpers.c | 53 ++++
> rust/kernel/dma_fence.rs | 532 ++++++++++++++++++++++++++++++++++++++++
This should probably be in the dma-buf namespace like on the C side?
There's a pile of tightly coupled concepts that I expect we'll all need
sooner or later (dma-fence/buf/resv at least).
Also I guess same questions about separate files and MAINTAINER entries as
for the drm stuff.
-Daniel
> rust/kernel/lib.rs | 2 +
> 4 files changed, 589 insertions(+)
>
> diff --git a/rust/bindings/bindings_helper.h b/rust/bindings/bindings_helper.h
> index 9f152d373df8..705af292a5b4 100644
> --- a/rust/bindings/bindings_helper.h
> +++ b/rust/bindings/bindings_helper.h
> @@ -14,6 +14,8 @@
> #include <drm/drm_ioctl.h>
> #include <linux/delay.h>
> #include <linux/device.h>
> +#include <linux/dma-fence.h>
> +#include <linux/dma-fence-chain.h>
> #include <linux/dma-mapping.h>
> #include <linux/fs.h>
> #include <linux/ioctl.h>
> diff --git a/rust/helpers.c b/rust/helpers.c
> index 388ff1100ea5..8e906a7a7d8a 100644
> --- a/rust/helpers.c
> +++ b/rust/helpers.c
> @@ -23,6 +23,8 @@
> #include <linux/bug.h>
> #include <linux/build_bug.h>
> #include <linux/device.h>
> +#include <linux/dma-fence.h>
> +#include <linux/dma-fence-chain.h>
> #include <linux/dma-mapping.h>
> #include <linux/err.h>
> #include <linux/errname.h>
> @@ -30,6 +32,7 @@
> #include <linux/of.h>
> #include <linux/of_device.h>
> #include <linux/platform_device.h>
> +#include <linux/spinlock.h>
> #include <linux/rcupdate.h>
> #include <linux/refcount.h>
> #include <linux/xarray.h>
> @@ -388,6 +391,56 @@ int rust_helper_sg_dma_len(const struct scatterlist *sg)
> }
> EXPORT_SYMBOL_GPL(rust_helper_sg_dma_len);
>
> +void rust_helper___spin_lock_init(spinlock_t *lock, const char *name,
> + struct lock_class_key *key)
> +{
> +#ifdef CONFIG_DEBUG_SPINLOCK
> +# ifndef CONFIG_PREEMPT_RT
> + __raw_spin_lock_init(spinlock_check(lock), name, key, LD_WAIT_CONFIG);
> +# else
> + rt_mutex_base_init(&lock->lock);
> + __rt_spin_lock_init(lock, name, key, false);
> +# endif
> +#else
> + spin_lock_init(lock);
> +#endif
> +}
> +EXPORT_SYMBOL_GPL(rust_helper___spin_lock_init);
> +
> +#ifdef CONFIG_DMA_SHARED_BUFFER
> +
> +void rust_helper_dma_fence_get(struct dma_fence *fence)
> +{
> + dma_fence_get(fence);
> +}
> +EXPORT_SYMBOL_GPL(rust_helper_dma_fence_get);
> +
> +void rust_helper_dma_fence_put(struct dma_fence *fence)
> +{
> + dma_fence_put(fence);
> +}
> +EXPORT_SYMBOL_GPL(rust_helper_dma_fence_put);
> +
> +struct dma_fence_chain *rust_helper_dma_fence_chain_alloc(void)
> +{
> + return dma_fence_chain_alloc();
> +}
> +EXPORT_SYMBOL_GPL(rust_helper_dma_fence_chain_alloc);
> +
> +void rust_helper_dma_fence_chain_free(struct dma_fence_chain *chain)
> +{
> + dma_fence_chain_free(chain);
> +}
> +EXPORT_SYMBOL_GPL(rust_helper_dma_fence_chain_free);
> +
> +void rust_helper_dma_fence_set_error(struct dma_fence *fence, int error)
> +{
> + dma_fence_set_error(fence, error);
> +}
> +EXPORT_SYMBOL_GPL(rust_helper_dma_fence_set_error);
> +
> +#endif
> +
> #ifdef CONFIG_DRM
>
> void rust_helper_drm_gem_object_get(struct drm_gem_object *obj)
> diff --git a/rust/kernel/dma_fence.rs b/rust/kernel/dma_fence.rs
> new file mode 100644
> index 000000000000..ca93380d9da2
> --- /dev/null
> +++ b/rust/kernel/dma_fence.rs
> @@ -0,0 +1,532 @@
> +// SPDX-License-Identifier: GPL-2.0
> +
> +//! DMA fence abstraction.
> +//!
> +//! C header: [`include/linux/dma_fence.h`](../../include/linux/dma_fence.h)
> +
> +use crate::{
> + bindings,
> + error::{to_result, Result},
> + prelude::*,
> + sync::LockClassKey,
> + types::Opaque,
> +};
> +use core::fmt::Write;
> +use core::ops::{Deref, DerefMut};
> +use core::ptr::addr_of_mut;
> +use core::sync::atomic::{AtomicU64, Ordering};
> +
> +/// Any kind of DMA Fence Object
> +///
> +/// # Invariants
> +/// raw() returns a valid pointer to a dma_fence and we own a reference to it.
> +pub trait RawDmaFence: crate::private::Sealed {
> + /// Returns the raw `struct dma_fence` pointer.
> + fn raw(&self) -> *mut bindings::dma_fence;
> +
> + /// Returns the raw `struct dma_fence` pointer and consumes the object.
> + ///
> + /// The caller is responsible for dropping the reference.
> + fn into_raw(self) -> *mut bindings::dma_fence
> + where
> + Self: Sized,
> + {
> + let ptr = self.raw();
> + core::mem::forget(self);
> + ptr
> + }
> +
> + /// Advances this fence to the chain node which will signal this sequence number.
> + /// If no sequence number is provided, this returns `self` again.
> + fn chain_find_seqno(self, seqno: u64) -> Result<Fence>
> + where
> + Self: Sized,
> + {
> + let mut ptr = self.into_raw();
> +
> + // SAFETY: This will safely fail if this DmaFence is not a chain.
> + // `ptr` is valid per the type invariant.
> + let ret = unsafe { bindings::dma_fence_chain_find_seqno(&mut ptr, seqno) };
> +
> + if ret != 0 {
> + // SAFETY: This is either an owned reference or NULL, dma_fence_put can handle both.
> + unsafe { bindings::dma_fence_put(ptr) };
> + Err(Error::from_kernel_errno(ret))
> + } else if ptr.is_null() {
> + Err(EINVAL) // When can this happen?
> + } else {
> + // SAFETY: ptr is valid and non-NULL as checked above.
> + Ok(unsafe { Fence::from_raw(ptr) })
> + }
> + }
> +
> + /// Signal completion of this fence
> + fn signal(&self) -> Result {
> + to_result(unsafe { bindings::dma_fence_signal(self.raw()) })
> + }
> +
> + /// Set the error flag on this fence
> + fn set_error(&self, err: Error) {
> + unsafe { bindings::dma_fence_set_error(self.raw(), err.to_kernel_errno()) };
> + }
> +}
> +
> +/// A generic DMA Fence Object
> +///
> +/// # Invariants
> +/// ptr is a valid pointer to a dma_fence and we own a reference to it.
> +pub struct Fence {
> + ptr: *mut bindings::dma_fence,
> +}
> +
> +impl Fence {
> + /// Create a new Fence object from a raw pointer to a dma_fence.
> + ///
> + /// # Safety
> + /// The caller must own a reference to the dma_fence, which is transferred to the new object.
> + pub(crate) unsafe fn from_raw(ptr: *mut bindings::dma_fence) -> Fence {
> + Fence { ptr }
> + }
> +
> + /// Create a new Fence object from a raw pointer to a dma_fence.
> + ///
> + /// # Safety
> + /// Takes a borrowed reference to the dma_fence, and increments the reference count.
> + pub(crate) unsafe fn get_raw(ptr: *mut bindings::dma_fence) -> Fence {
> + // SAFETY: Pointer is valid per the safety contract
> + unsafe { bindings::dma_fence_get(ptr) };
> + Fence { ptr }
> + }
> +
> + /// Create a new Fence object from a RawDmaFence.
> + pub fn from_fence(fence: &dyn RawDmaFence) -> Fence {
> + // SAFETY: Pointer is valid per the RawDmaFence contract
> + unsafe { Self::get_raw(fence.raw()) }
> + }
> +}
> +
> +impl crate::private::Sealed for Fence {}
> +
> +impl RawDmaFence for Fence {
> + fn raw(&self) -> *mut bindings::dma_fence {
> + self.ptr
> + }
> +}
> +
> +impl Drop for Fence {
> + fn drop(&mut self) {
> + // SAFETY: We own a reference to this syncobj.
> + unsafe { bindings::dma_fence_put(self.ptr) };
> + }
> +}
> +
> +impl Clone for Fence {
> + fn clone(&self) -> Self {
> + // SAFETY: `ptr` is valid per the type invariant and we own a reference to it.
> + unsafe {
> + bindings::dma_fence_get(self.ptr);
> + Self::from_raw(self.ptr)
> + }
> + }
> +}
> +
> +unsafe impl Sync for Fence {}
> +unsafe impl Send for Fence {}
> +
> +/// Trait which must be implemented by driver-specific fence objects.
> +#[vtable]
> +pub trait FenceOps: Sized + Send + Sync {
> + /// True if this dma_fence implementation uses 64bit seqno, false otherwise.
> + const USE_64BIT_SEQNO: bool;
> +
> + /// Returns the driver name. This is a callback to allow drivers to compute the name at
> + /// runtime, without having it to store permanently for each fence, or build a cache of
> + /// some sort.
> + fn get_driver_name<'a>(self: &'a FenceObject<Self>) -> &'a CStr;
> +
> + /// Return the name of the context this fence belongs to. This is a callback to allow drivers
> + /// to compute the name at runtime, without having it to store permanently for each fence, or
> + /// build a cache of some sort.
> + fn get_timeline_name<'a>(self: &'a FenceObject<Self>) -> &'a CStr;
> +
> + /// Enable software signaling of fence.
> + fn enable_signaling(self: &FenceObject<Self>) -> bool {
> + false
> + }
> +
> + /// Peek whether the fence is signaled, as a fastpath optimization for e.g. dma_fence_wait() or
> + /// dma_fence_add_callback().
> + fn signaled(self: &FenceObject<Self>) -> bool {
> + false
> + }
> +
> + /// Callback to fill in free-form debug info specific to this fence, like the sequence number.
> + fn fence_value_str(self: &FenceObject<Self>, _output: &mut dyn Write) {}
> +
> + /// Fills in the current value of the timeline as a string, like the sequence number. Note that
> + /// the specific fence passed to this function should not matter, drivers should only use it to
> + /// look up the corresponding timeline structures.
> + fn timeline_value_str(self: &FenceObject<Self>, _output: &mut dyn Write) {}
> +}
> +
> +unsafe extern "C" fn get_driver_name_cb<T: FenceOps>(
> + fence: *mut bindings::dma_fence,
> +) -> *const core::ffi::c_char {
> + // SAFETY: All of our fences are FenceObject<T>.
> + let p = crate::container_of!(fence, FenceObject<T>, fence) as *mut FenceObject<T>;
> +
> + // SAFETY: The caller is responsible for passing a valid dma_fence subtype
> + T::get_driver_name(unsafe { &mut *p }).as_char_ptr()
> +}
> +
> +unsafe extern "C" fn get_timeline_name_cb<T: FenceOps>(
> + fence: *mut bindings::dma_fence,
> +) -> *const core::ffi::c_char {
> + // SAFETY: All of our fences are FenceObject<T>.
> + let p = crate::container_of!(fence, FenceObject<T>, fence) as *mut FenceObject<T>;
> +
> + // SAFETY: The caller is responsible for passing a valid dma_fence subtype
> + T::get_timeline_name(unsafe { &mut *p }).as_char_ptr()
> +}
> +
> +unsafe extern "C" fn enable_signaling_cb<T: FenceOps>(fence: *mut bindings::dma_fence) -> bool {
> + // SAFETY: All of our fences are FenceObject<T>.
> + let p = crate::container_of!(fence, FenceObject<T>, fence) as *mut FenceObject<T>;
> +
> + // SAFETY: The caller is responsible for passing a valid dma_fence subtype
> + T::enable_signaling(unsafe { &mut *p })
> +}
> +
> +unsafe extern "C" fn signaled_cb<T: FenceOps>(fence: *mut bindings::dma_fence) -> bool {
> + // SAFETY: All of our fences are FenceObject<T>.
> + let p = crate::container_of!(fence, FenceObject<T>, fence) as *mut FenceObject<T>;
> +
> + // SAFETY: The caller is responsible for passing a valid dma_fence subtype
> + T::signaled(unsafe { &mut *p })
> +}
> +
> +unsafe extern "C" fn release_cb<T: FenceOps>(fence: *mut bindings::dma_fence) {
> + // SAFETY: All of our fences are FenceObject<T>.
> + let p = crate::container_of!(fence, FenceObject<T>, fence) as *mut FenceObject<T>;
> +
> + // SAFETY: p is never used after this
> + unsafe {
> + core::ptr::drop_in_place(&mut (*p).inner);
> + }
> +
> + // SAFETY: All of our fences are allocated using kmalloc, so this is safe.
> + unsafe { bindings::dma_fence_free(fence) };
> +}
> +
> +unsafe extern "C" fn fence_value_str_cb<T: FenceOps>(
> + fence: *mut bindings::dma_fence,
> + string: *mut core::ffi::c_char,
> + size: core::ffi::c_int,
> +) {
> + let size: usize = size.try_into().unwrap_or(0);
> +
> + if size == 0 {
> + return;
> + }
> +
> + // SAFETY: All of our fences are FenceObject<T>.
> + let p = crate::container_of!(fence, FenceObject<T>, fence) as *mut FenceObject<T>;
> +
> + // SAFETY: The caller is responsible for the validity of string/size
> + let mut f = unsafe { crate::str::Formatter::from_buffer(string as *mut _, size) };
> +
> + // SAFETY: The caller is responsible for passing a valid dma_fence subtype
> + T::fence_value_str(unsafe { &mut *p }, &mut f);
> + let _ = f.write_str("\0");
> +
> + // SAFETY: `size` is at least 1 per the check above
> + unsafe { *string.add(size - 1) = 0 };
> +}
> +
> +unsafe extern "C" fn timeline_value_str_cb<T: FenceOps>(
> + fence: *mut bindings::dma_fence,
> + string: *mut core::ffi::c_char,
> + size: core::ffi::c_int,
> +) {
> + let size: usize = size.try_into().unwrap_or(0);
> +
> + if size == 0 {
> + return;
> + }
> +
> + // SAFETY: All of our fences are FenceObject<T>.
> + let p = crate::container_of!(fence, FenceObject<T>, fence) as *mut FenceObject<T>;
> +
> + // SAFETY: The caller is responsible for the validity of string/size
> + let mut f = unsafe { crate::str::Formatter::from_buffer(string as *mut _, size) };
> +
> + // SAFETY: The caller is responsible for passing a valid dma_fence subtype
> + T::timeline_value_str(unsafe { &mut *p }, &mut f);
> + let _ = f.write_str("\0");
> +
> + // SAFETY: `size` is at least 1 per the check above
> + unsafe { *string.add(size - 1) = 0 };
> +}
> +
> +// Allow FenceObject<Self> to be used as a self argument, for ergonomics
> +impl<T: FenceOps> core::ops::Receiver for FenceObject<T> {}
> +
> +/// A driver-specific DMA Fence Object
> +///
> +/// # Invariants
> +/// ptr is a valid pointer to a dma_fence and we own a reference to it.
> +#[repr(C)]
> +pub struct FenceObject<T: FenceOps> {
> + fence: bindings::dma_fence,
> + lock: Opaque<bindings::spinlock>,
> + inner: T,
> +}
> +
> +impl<T: FenceOps> FenceObject<T> {
> + const SIZE: usize = core::mem::size_of::<Self>();
> +
> + const VTABLE: bindings::dma_fence_ops = bindings::dma_fence_ops {
> + use_64bit_seqno: T::USE_64BIT_SEQNO,
> + get_driver_name: Some(get_driver_name_cb::<T>),
> + get_timeline_name: Some(get_timeline_name_cb::<T>),
> + enable_signaling: if T::HAS_ENABLE_SIGNALING {
> + Some(enable_signaling_cb::<T>)
> + } else {
> + None
> + },
> + signaled: if T::HAS_SIGNALED {
> + Some(signaled_cb::<T>)
> + } else {
> + None
> + },
> + wait: None, // Deprecated
> + release: Some(release_cb::<T>),
> + fence_value_str: if T::HAS_FENCE_VALUE_STR {
> + Some(fence_value_str_cb::<T>)
> + } else {
> + None
> + },
> + timeline_value_str: if T::HAS_TIMELINE_VALUE_STR {
> + Some(timeline_value_str_cb::<T>)
> + } else {
> + None
> + },
> + };
> +}
> +
> +impl<T: FenceOps> Deref for FenceObject<T> {
> + type Target = T;
> +
> + fn deref(&self) -> &T {
> + &self.inner
> + }
> +}
> +
> +impl<T: FenceOps> DerefMut for FenceObject<T> {
> + fn deref_mut(&mut self) -> &mut T {
> + &mut self.inner
> + }
> +}
> +
> +impl<T: FenceOps> crate::private::Sealed for FenceObject<T> {}
> +impl<T: FenceOps> RawDmaFence for FenceObject<T> {
> + fn raw(&self) -> *mut bindings::dma_fence {
> + &self.fence as *const _ as *mut _
> + }
> +}
> +
> +/// A unique reference to a driver-specific fence object
> +pub struct UniqueFence<T: FenceOps>(*mut FenceObject<T>);
> +
> +impl<T: FenceOps> Deref for UniqueFence<T> {
> + type Target = FenceObject<T>;
> +
> + fn deref(&self) -> &FenceObject<T> {
> + unsafe { &*self.0 }
> + }
> +}
> +
> +impl<T: FenceOps> DerefMut for UniqueFence<T> {
> + fn deref_mut(&mut self) -> &mut FenceObject<T> {
> + unsafe { &mut *self.0 }
> + }
> +}
> +
> +impl<T: FenceOps> crate::private::Sealed for UniqueFence<T> {}
> +impl<T: FenceOps> RawDmaFence for UniqueFence<T> {
> + fn raw(&self) -> *mut bindings::dma_fence {
> + unsafe { addr_of_mut!((*self.0).fence) }
> + }
> +}
> +
> +impl<T: FenceOps> From<UniqueFence<T>> for UserFence<T> {
> + fn from(value: UniqueFence<T>) -> Self {
> + let ptr = value.0;
> + core::mem::forget(value);
> +
> + UserFence(ptr)
> + }
> +}
> +
> +impl<T: FenceOps> Drop for UniqueFence<T> {
> + fn drop(&mut self) {
> + // SAFETY: We own a reference to this fence.
> + unsafe { bindings::dma_fence_put(self.raw()) };
> + }
> +}
> +
> +unsafe impl<T: FenceOps> Sync for UniqueFence<T> {}
> +unsafe impl<T: FenceOps> Send for UniqueFence<T> {}
> +
> +/// A shared reference to a driver-specific fence object
> +pub struct UserFence<T: FenceOps>(*mut FenceObject<T>);
> +
> +impl<T: FenceOps> Deref for UserFence<T> {
> + type Target = FenceObject<T>;
> +
> + fn deref(&self) -> &FenceObject<T> {
> + unsafe { &*self.0 }
> + }
> +}
> +
> +impl<T: FenceOps> Clone for UserFence<T> {
> + fn clone(&self) -> Self {
> + // SAFETY: `ptr` is valid per the type invariant and we own a reference to it.
> + unsafe {
> + bindings::dma_fence_get(self.raw());
> + Self(self.0)
> + }
> + }
> +}
> +
> +impl<T: FenceOps> crate::private::Sealed for UserFence<T> {}
> +impl<T: FenceOps> RawDmaFence for UserFence<T> {
> + fn raw(&self) -> *mut bindings::dma_fence {
> + unsafe { addr_of_mut!((*self.0).fence) }
> + }
> +}
> +
> +impl<T: FenceOps> Drop for UserFence<T> {
> + fn drop(&mut self) {
> + // SAFETY: We own a reference to this fence.
> + unsafe { bindings::dma_fence_put(self.raw()) };
> + }
> +}
> +
> +unsafe impl<T: FenceOps> Sync for UserFence<T> {}
> +unsafe impl<T: FenceOps> Send for UserFence<T> {}
> +
> +/// An array of fence contexts, out of which fences can be created.
> +pub struct FenceContexts {
> + start: u64,
> + count: u32,
> + seqnos: Vec<AtomicU64>,
> + lock_name: &'static CStr,
> + lock_key: &'static LockClassKey,
> +}
> +
> +impl FenceContexts {
> + /// Create a new set of fence contexts.
> + pub fn new(
> + count: u32,
> + name: &'static CStr,
> + key: &'static LockClassKey,
> + ) -> Result<FenceContexts> {
> + let mut seqnos: Vec<AtomicU64> = Vec::new();
> +
> + seqnos.try_reserve(count as usize)?;
> +
> + for _ in 0..count {
> + seqnos.try_push(Default::default())?;
> + }
> +
> + let start = unsafe { bindings::dma_fence_context_alloc(count as core::ffi::c_uint) };
> +
> + Ok(FenceContexts {
> + start,
> + count,
> + seqnos,
> + lock_name: name,
> + lock_key: key,
> + })
> + }
> +
> + /// Create a new fence in a given context index.
> + pub fn new_fence<T: FenceOps>(&self, context: u32, inner: T) -> Result<UniqueFence<T>> {
> + if context > self.count {
> + return Err(EINVAL);
> + }
> +
> + let p = unsafe {
> + bindings::krealloc(
> + core::ptr::null_mut(),
> + FenceObject::<T>::SIZE,
> + bindings::GFP_KERNEL | bindings::__GFP_ZERO,
> + ) as *mut FenceObject<T>
> + };
> +
> + if p.is_null() {
> + return Err(ENOMEM);
> + }
> +
> + let seqno = self.seqnos[context as usize].fetch_add(1, Ordering::Relaxed);
> +
> + // SAFETY: The pointer is valid, so pointers to members are too.
> + // After this, all fields are initialized.
> + unsafe {
> + addr_of_mut!((*p).inner).write(inner);
> + bindings::__spin_lock_init(
> + addr_of_mut!((*p).lock) as *mut _,
> + self.lock_name.as_char_ptr(),
> + self.lock_key.get(),
> + );
> + bindings::dma_fence_init(
> + addr_of_mut!((*p).fence),
> + &FenceObject::<T>::VTABLE,
> + addr_of_mut!((*p).lock) as *mut _,
> + self.start + context as u64,
> + seqno,
> + );
> + };
> +
> + Ok(UniqueFence(p))
> + }
> +}
> +
> +/// A DMA Fence Chain Object
> +///
> +/// # Invariants
> +/// ptr is a valid pointer to a dma_fence_chain which we own.
> +pub struct FenceChain {
> + ptr: *mut bindings::dma_fence_chain,
> +}
> +
> +impl FenceChain {
> + /// Create a new DmaFenceChain object.
> + pub fn new() -> Result<Self> {
> + // SAFETY: This function is safe to call and takes no arguments.
> + let ptr = unsafe { bindings::dma_fence_chain_alloc() };
> +
> + if ptr.is_null() {
> + Err(ENOMEM)
> + } else {
> + Ok(FenceChain { ptr })
> + }
> + }
> +
> + /// Convert the DmaFenceChain into the underlying raw pointer.
> + ///
> + /// This assumes the caller will take ownership of the object.
> + pub(crate) fn into_raw(self) -> *mut bindings::dma_fence_chain {
> + let ptr = self.ptr;
> + core::mem::forget(self);
> + ptr
> + }
> +}
> +
> +impl Drop for FenceChain {
> + fn drop(&mut self) {
> + // SAFETY: We own this dma_fence_chain.
> + unsafe { bindings::dma_fence_chain_free(self.ptr) };
> + }
> +}
> diff --git a/rust/kernel/lib.rs b/rust/kernel/lib.rs
> index cb23d24c6718..31866069e0bc 100644
> --- a/rust/kernel/lib.rs
> +++ b/rust/kernel/lib.rs
> @@ -36,6 +36,8 @@ mod allocator;
> mod build_assert;
> pub mod delay;
> pub mod device;
> +#[cfg(CONFIG_DMA_SHARED_BUFFER)]
> +pub mod dma_fence;
> pub mod driver;
> #[cfg(CONFIG_RUST_DRM)]
> pub mod drm;
>
> --
> 2.35.1
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
^ permalink raw reply [flat|nested] 122+ messages in thread
* [PATCH RFC 09/18] rust: drm: syncobj: Add DRM Sync Object abstraction
2023-03-07 14:25 [PATCH RFC 00/18] Rust DRM subsystem abstractions (& preview AGX driver) Asahi Lina
` (7 preceding siblings ...)
2023-03-07 14:25 ` [PATCH RFC 08/18] rust: dma_fence: Add DMA Fence abstraction Asahi Lina
@ 2023-03-07 14:25 ` Asahi Lina
2023-04-05 12:33 ` Daniel Vetter
2023-03-07 14:25 ` [PATCH RFC 10/18] drm/scheduler: Add can_run_job callback Asahi Lina
` (9 subsequent siblings)
18 siblings, 1 reply; 122+ messages in thread
From: Asahi Lina @ 2023-03-07 14:25 UTC (permalink / raw)
To: Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
David Airlie, Daniel Vetter, Miguel Ojeda, Alex Gaynor,
Wedson Almeida Filho, Boqun Feng, Gary Guo, Björn Roy Baron,
Sumit Semwal, Christian König, Luben Tuikov,
Jarkko Sakkinen, Dave Hansen
Cc: Alyssa Rosenzweig, Karol Herbst, Ella Stanforth, Faith Ekstrand,
Mary, linux-kernel, dri-devel, rust-for-linux, linux-media,
linaro-mm-sig, linux-sgx, asahi, Asahi Lina
DRM Sync Objects are a container for a DMA fence, and can be waited on
signaled, exported, and imported from userspace. Add a Rust abstraction
so Rust DRM drivers can support this functionality.
Signed-off-by: Asahi Lina <lina@asahilina.net>
---
rust/bindings/bindings_helper.h | 1 +
rust/helpers.c | 19 ++++++++++
rust/kernel/drm/mod.rs | 1 +
rust/kernel/drm/syncobj.rs | 77 +++++++++++++++++++++++++++++++++++++++++
4 files changed, 98 insertions(+)
diff --git a/rust/bindings/bindings_helper.h b/rust/bindings/bindings_helper.h
index 705af292a5b4..b6696011f3a4 100644
--- a/rust/bindings/bindings_helper.h
+++ b/rust/bindings/bindings_helper.h
@@ -12,6 +12,7 @@
#include <drm/drm_gem.h>
#include <drm/drm_gem_shmem_helper.h>
#include <drm/drm_ioctl.h>
+#include <drm/drm_syncobj.h>
#include <linux/delay.h>
#include <linux/device.h>
#include <linux/dma-fence.h>
diff --git a/rust/helpers.c b/rust/helpers.c
index 8e906a7a7d8a..11965b1e2f4e 100644
--- a/rust/helpers.c
+++ b/rust/helpers.c
@@ -20,6 +20,7 @@
#include <drm/drm_gem.h>
#include <drm/drm_gem_shmem_helper.h>
+#include <drm/drm_syncobj.h>
#include <linux/bug.h>
#include <linux/build_bug.h>
#include <linux/device.h>
@@ -461,6 +462,24 @@ __u64 rust_helper_drm_vma_node_offset_addr(struct drm_vma_offset_node *node)
}
EXPORT_SYMBOL_GPL(rust_helper_drm_vma_node_offset_addr);
+void rust_helper_drm_syncobj_get(struct drm_syncobj *obj)
+{
+ drm_syncobj_get(obj);
+}
+EXPORT_SYMBOL_GPL(rust_helper_drm_syncobj_get);
+
+void rust_helper_drm_syncobj_put(struct drm_syncobj *obj)
+{
+ drm_syncobj_put(obj);
+}
+EXPORT_SYMBOL_GPL(rust_helper_drm_syncobj_put);
+
+struct dma_fence *rust_helper_drm_syncobj_fence_get(struct drm_syncobj *syncobj)
+{
+ return drm_syncobj_fence_get(syncobj);
+}
+EXPORT_SYMBOL_GPL(rust_helper_drm_syncobj_fence_get);
+
#ifdef CONFIG_DRM_GEM_SHMEM_HELPER
void rust_helper_drm_gem_shmem_object_free(struct drm_gem_object *obj)
diff --git a/rust/kernel/drm/mod.rs b/rust/kernel/drm/mod.rs
index 73fab2dee3af..dae98826edfd 100644
--- a/rust/kernel/drm/mod.rs
+++ b/rust/kernel/drm/mod.rs
@@ -8,3 +8,4 @@ pub mod file;
pub mod gem;
pub mod ioctl;
pub mod mm;
+pub mod syncobj;
diff --git a/rust/kernel/drm/syncobj.rs b/rust/kernel/drm/syncobj.rs
new file mode 100644
index 000000000000..10eed05eb27a
--- /dev/null
+++ b/rust/kernel/drm/syncobj.rs
@@ -0,0 +1,77 @@
+// SPDX-License-Identifier: GPL-2.0 OR MIT
+
+//! DRM Sync Objects
+//!
+//! C header: [`include/linux/drm/drm_syncobj.h`](../../../../include/linux/drm/drm_syncobj.h)
+
+use crate::{bindings, dma_fence::*, drm, error::Result, prelude::*};
+
+/// A DRM Sync Object
+///
+/// # Invariants
+/// ptr is a valid pointer to a drm_syncobj and we own a reference to it.
+pub struct SyncObj {
+ ptr: *mut bindings::drm_syncobj,
+}
+
+impl SyncObj {
+ /// Looks up a sync object by its handle for a given `File`.
+ pub fn lookup_handle(file: &impl drm::file::GenericFile, handle: u32) -> Result<SyncObj> {
+ // SAFETY: The arguments are all valid per the type invariants.
+ let ptr = unsafe { bindings::drm_syncobj_find(file.raw() as *mut _, handle) };
+
+ if ptr.is_null() {
+ Err(ENOENT)
+ } else {
+ Ok(SyncObj { ptr })
+ }
+ }
+
+ /// Returns the DMA fence associated with this sync object, if any.
+ pub fn fence_get(&self) -> Option<Fence> {
+ let fence = unsafe { bindings::drm_syncobj_fence_get(self.ptr) };
+ if fence.is_null() {
+ None
+ } else {
+ // SAFETY: The pointer is non-NULL and drm_syncobj_fence_get acquired an
+ // additional reference.
+ Some(unsafe { Fence::from_raw(fence) })
+ }
+ }
+
+ /// Replaces the DMA fence with a new one, or removes it if fence is None.
+ pub fn replace_fence(&self, fence: Option<&Fence>) {
+ unsafe {
+ bindings::drm_syncobj_replace_fence(
+ self.ptr,
+ fence.map_or(core::ptr::null_mut(), |a| a.raw()),
+ )
+ };
+ }
+
+ /// Adds a new timeline point to the syncobj.
+ pub fn add_point(&self, chain: FenceChain, fence: &Fence, point: u64) {
+ // SAFETY: All arguments should be valid per the respective type invariants.
+ // This takes over the FenceChain ownership.
+ unsafe { bindings::drm_syncobj_add_point(self.ptr, chain.into_raw(), fence.raw(), point) };
+ }
+}
+
+impl Drop for SyncObj {
+ fn drop(&mut self) {
+ // SAFETY: We own a reference to this syncobj.
+ unsafe { bindings::drm_syncobj_put(self.ptr) };
+ }
+}
+
+impl Clone for SyncObj {
+ fn clone(&self) -> Self {
+ // SAFETY: `ptr` is valid per the type invariant and we own a reference to it.
+ unsafe { bindings::drm_syncobj_get(self.ptr) };
+ SyncObj { ptr: self.ptr }
+ }
+}
+
+// SAFETY: drm_syncobj operations are internally locked.
+unsafe impl Sync for SyncObj {}
+unsafe impl Send for SyncObj {}
--
2.35.1
^ permalink raw reply related [flat|nested] 122+ messages in thread* Re: [PATCH RFC 09/18] rust: drm: syncobj: Add DRM Sync Object abstraction
2023-03-07 14:25 ` [PATCH RFC 09/18] rust: drm: syncobj: Add DRM Sync Object abstraction Asahi Lina
@ 2023-04-05 12:33 ` Daniel Vetter
2023-04-06 16:04 ` Asahi Lina
0 siblings, 1 reply; 122+ messages in thread
From: Daniel Vetter @ 2023-04-05 12:33 UTC (permalink / raw)
To: Asahi Lina
Cc: Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
David Airlie, Daniel Vetter, Miguel Ojeda, Alex Gaynor,
Wedson Almeida Filho, Boqun Feng, Gary Guo, Björn Roy Baron,
Sumit Semwal, Christian König, Luben Tuikov,
Jarkko Sakkinen, Dave Hansen, Alyssa Rosenzweig, Karol Herbst,
Ella Stanforth, Faith Ekstrand, Mary, linux-kernel, dri-devel,
rust-for-linux, linux-media, linaro-mm-sig, linux-sgx, asahi
On Tue, Mar 07, 2023 at 11:25:34PM +0900, Asahi Lina wrote:
> DRM Sync Objects are a container for a DMA fence, and can be waited on
> signaled, exported, and imported from userspace. Add a Rust abstraction
> so Rust DRM drivers can support this functionality.
>
> Signed-off-by: Asahi Lina <lina@asahilina.net>
> ---
> rust/bindings/bindings_helper.h | 1 +
> rust/helpers.c | 19 ++++++++++
> rust/kernel/drm/mod.rs | 1 +
> rust/kernel/drm/syncobj.rs | 77 +++++++++++++++++++++++++++++++++++++++++
> 4 files changed, 98 insertions(+)
>
> diff --git a/rust/bindings/bindings_helper.h b/rust/bindings/bindings_helper.h
> index 705af292a5b4..b6696011f3a4 100644
> --- a/rust/bindings/bindings_helper.h
> +++ b/rust/bindings/bindings_helper.h
> @@ -12,6 +12,7 @@
> #include <drm/drm_gem.h>
> #include <drm/drm_gem_shmem_helper.h>
> #include <drm/drm_ioctl.h>
> +#include <drm/drm_syncobj.h>
> #include <linux/delay.h>
> #include <linux/device.h>
> #include <linux/dma-fence.h>
> diff --git a/rust/helpers.c b/rust/helpers.c
> index 8e906a7a7d8a..11965b1e2f4e 100644
> --- a/rust/helpers.c
> +++ b/rust/helpers.c
> @@ -20,6 +20,7 @@
>
> #include <drm/drm_gem.h>
> #include <drm/drm_gem_shmem_helper.h>
> +#include <drm/drm_syncobj.h>
> #include <linux/bug.h>
> #include <linux/build_bug.h>
> #include <linux/device.h>
> @@ -461,6 +462,24 @@ __u64 rust_helper_drm_vma_node_offset_addr(struct drm_vma_offset_node *node)
> }
> EXPORT_SYMBOL_GPL(rust_helper_drm_vma_node_offset_addr);
>
> +void rust_helper_drm_syncobj_get(struct drm_syncobj *obj)
> +{
> + drm_syncobj_get(obj);
> +}
> +EXPORT_SYMBOL_GPL(rust_helper_drm_syncobj_get);
> +
> +void rust_helper_drm_syncobj_put(struct drm_syncobj *obj)
> +{
> + drm_syncobj_put(obj);
> +}
> +EXPORT_SYMBOL_GPL(rust_helper_drm_syncobj_put);
> +
> +struct dma_fence *rust_helper_drm_syncobj_fence_get(struct drm_syncobj *syncobj)
> +{
> + return drm_syncobj_fence_get(syncobj);
> +}
> +EXPORT_SYMBOL_GPL(rust_helper_drm_syncobj_fence_get);
> +
> #ifdef CONFIG_DRM_GEM_SHMEM_HELPER
>
> void rust_helper_drm_gem_shmem_object_free(struct drm_gem_object *obj)
> diff --git a/rust/kernel/drm/mod.rs b/rust/kernel/drm/mod.rs
> index 73fab2dee3af..dae98826edfd 100644
> --- a/rust/kernel/drm/mod.rs
> +++ b/rust/kernel/drm/mod.rs
> @@ -8,3 +8,4 @@ pub mod file;
> pub mod gem;
> pub mod ioctl;
> pub mod mm;
> +pub mod syncobj;
> diff --git a/rust/kernel/drm/syncobj.rs b/rust/kernel/drm/syncobj.rs
> new file mode 100644
> index 000000000000..10eed05eb27a
> --- /dev/null
> +++ b/rust/kernel/drm/syncobj.rs
> @@ -0,0 +1,77 @@
> +// SPDX-License-Identifier: GPL-2.0 OR MIT
> +
> +//! DRM Sync Objects
> +//!
> +//! C header: [`include/linux/drm/drm_syncobj.h`](../../../../include/linux/drm/drm_syncobj.h)
> +
> +use crate::{bindings, dma_fence::*, drm, error::Result, prelude::*};
> +
> +/// A DRM Sync Object
> +///
> +/// # Invariants
> +/// ptr is a valid pointer to a drm_syncobj and we own a reference to it.
> +pub struct SyncObj {
> + ptr: *mut bindings::drm_syncobj,
> +}
> +
> +impl SyncObj {
> + /// Looks up a sync object by its handle for a given `File`.
> + pub fn lookup_handle(file: &impl drm::file::GenericFile, handle: u32) -> Result<SyncObj> {
> + // SAFETY: The arguments are all valid per the type invariants.
> + let ptr = unsafe { bindings::drm_syncobj_find(file.raw() as *mut _, handle) };
Just an aside, but the semantics of this are nasty: You're not allowed to
hold any locks while calling this. We have runtime checks for that (if you
enable lockdep), but I don't see any way to encode that on the rust side
and check it at compile time :-/
> +
> + if ptr.is_null() {
> + Err(ENOENT)
> + } else {
> + Ok(SyncObj { ptr })
> + }
> + }
> +
> + /// Returns the DMA fence associated with this sync object, if any.
> + pub fn fence_get(&self) -> Option<Fence> {
> + let fence = unsafe { bindings::drm_syncobj_fence_get(self.ptr) };
> + if fence.is_null() {
> + None
> + } else {
> + // SAFETY: The pointer is non-NULL and drm_syncobj_fence_get acquired an
> + // additional reference.
> + Some(unsafe { Fence::from_raw(fence) })
> + }
> + }
> +
> + /// Replaces the DMA fence with a new one, or removes it if fence is None.
> + pub fn replace_fence(&self, fence: Option<&Fence>) {
> + unsafe {
> + bindings::drm_syncobj_replace_fence(
> + self.ptr,
> + fence.map_or(core::ptr::null_mut(), |a| a.raw()),
> + )
> + };
> + }
> +
> + /// Adds a new timeline point to the syncobj.
> + pub fn add_point(&self, chain: FenceChain, fence: &Fence, point: u64) {
> + // SAFETY: All arguments should be valid per the respective type invariants.
> + // This takes over the FenceChain ownership.
> + unsafe { bindings::drm_syncobj_add_point(self.ptr, chain.into_raw(), fence.raw(), point) };
> + }
> +}
> +
> +impl Drop for SyncObj {
> + fn drop(&mut self) {
> + // SAFETY: We own a reference to this syncobj.
> + unsafe { bindings::drm_syncobj_put(self.ptr) };
> + }
> +}
> +
> +impl Clone for SyncObj {
> + fn clone(&self) -> Self {
> + // SAFETY: `ptr` is valid per the type invariant and we own a reference to it.
> + unsafe { bindings::drm_syncobj_get(self.ptr) };
So yeah syncobj are refcounted because they're shareable uapi objects (you
can pass them around as fd), but that really should be entirely the
subsystems business, not for drivers.
This is kinda like drm_file, which is also refcounted (by virtue of
hanging of struct file), but the refcounting is entirely handled by the
vfs and all drivers get is a borrowed reference, which nicely bounds the
lifetime to the callback (which is usually an ioctl handler). I think we
want the same semantics for syncobj, because if a driver is hanging onto a
syncobj for longer than the ioctl. If my rust understanding is right we'd
get that by dropping Clone here and relying on lookup_handle only being
able to return stuff that's bound by the drm_file?
People are talking about drivers holding onto syncobj for longer, but I'm
still not sold on the idea that this is any good and doesn't just bend the
dma_fence and syncobj rules a bit too much over the breaking point. For
kernel drivers it really should be just a different way to lookup and
return dma_fence from the ioctl, pretty much matching what you could also
do with sync_file (but since syncobj provides generic compat ioctl to
convert to/from sync_file drivders only need to handle syncobj).
-Daniel
> + SyncObj { ptr: self.ptr }
> + }
> +}
> +
> +// SAFETY: drm_syncobj operations are internally locked.
> +unsafe impl Sync for SyncObj {}
> +unsafe impl Send for SyncObj {}
>
> --
> 2.35.1
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
^ permalink raw reply [flat|nested] 122+ messages in thread* Re: [PATCH RFC 09/18] rust: drm: syncobj: Add DRM Sync Object abstraction
2023-04-05 12:33 ` Daniel Vetter
@ 2023-04-06 16:04 ` Asahi Lina
0 siblings, 0 replies; 122+ messages in thread
From: Asahi Lina @ 2023-04-06 16:04 UTC (permalink / raw)
To: Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
David Airlie, Miguel Ojeda, Alex Gaynor, Wedson Almeida Filho,
Boqun Feng, Gary Guo, Björn Roy Baron, Sumit Semwal,
Christian König, Luben Tuikov, Jarkko Sakkinen, Dave Hansen,
Alyssa Rosenzweig, Karol Herbst, Ella Stanforth, Faith Ekstrand,
Mary, linux-kernel, dri-devel, rust-for-linux, linux-media,
linaro-mm-sig, linux-sgx, asahi
On 05/04/2023 21.33, Daniel Vetter wrote:
> On Tue, Mar 07, 2023 at 11:25:34PM +0900, Asahi Lina wrote:
>> DRM Sync Objects are a container for a DMA fence, and can be waited on
>> signaled, exported, and imported from userspace. Add a Rust abstraction
>> so Rust DRM drivers can support this functionality.
>>
>> Signed-off-by: Asahi Lina <lina@asahilina.net>
>> ---
>> rust/bindings/bindings_helper.h | 1 +
>> rust/helpers.c | 19 ++++++++++
>> rust/kernel/drm/mod.rs | 1 +
>> rust/kernel/drm/syncobj.rs | 77 +++++++++++++++++++++++++++++++++++++++++
>> 4 files changed, 98 insertions(+)
>>
>> diff --git a/rust/bindings/bindings_helper.h b/rust/bindings/bindings_helper.h
>> index 705af292a5b4..b6696011f3a4 100644
>> --- a/rust/bindings/bindings_helper.h
>> +++ b/rust/bindings/bindings_helper.h
>> @@ -12,6 +12,7 @@
>> #include <drm/drm_gem.h>
>> #include <drm/drm_gem_shmem_helper.h>
>> #include <drm/drm_ioctl.h>
>> +#include <drm/drm_syncobj.h>
>> #include <linux/delay.h>
>> #include <linux/device.h>
>> #include <linux/dma-fence.h>
>> diff --git a/rust/helpers.c b/rust/helpers.c
>> index 8e906a7a7d8a..11965b1e2f4e 100644
>> --- a/rust/helpers.c
>> +++ b/rust/helpers.c
>> @@ -20,6 +20,7 @@
>>
>> #include <drm/drm_gem.h>
>> #include <drm/drm_gem_shmem_helper.h>
>> +#include <drm/drm_syncobj.h>
>> #include <linux/bug.h>
>> #include <linux/build_bug.h>
>> #include <linux/device.h>
>> @@ -461,6 +462,24 @@ __u64 rust_helper_drm_vma_node_offset_addr(struct drm_vma_offset_node *node)
>> }
>> EXPORT_SYMBOL_GPL(rust_helper_drm_vma_node_offset_addr);
>>
>> +void rust_helper_drm_syncobj_get(struct drm_syncobj *obj)
>> +{
>> + drm_syncobj_get(obj);
>> +}
>> +EXPORT_SYMBOL_GPL(rust_helper_drm_syncobj_get);
>> +
>> +void rust_helper_drm_syncobj_put(struct drm_syncobj *obj)
>> +{
>> + drm_syncobj_put(obj);
>> +}
>> +EXPORT_SYMBOL_GPL(rust_helper_drm_syncobj_put);
>> +
>> +struct dma_fence *rust_helper_drm_syncobj_fence_get(struct drm_syncobj *syncobj)
>> +{
>> + return drm_syncobj_fence_get(syncobj);
>> +}
>> +EXPORT_SYMBOL_GPL(rust_helper_drm_syncobj_fence_get);
>> +
>> #ifdef CONFIG_DRM_GEM_SHMEM_HELPER
>>
>> void rust_helper_drm_gem_shmem_object_free(struct drm_gem_object *obj)
>> diff --git a/rust/kernel/drm/mod.rs b/rust/kernel/drm/mod.rs
>> index 73fab2dee3af..dae98826edfd 100644
>> --- a/rust/kernel/drm/mod.rs
>> +++ b/rust/kernel/drm/mod.rs
>> @@ -8,3 +8,4 @@ pub mod file;
>> pub mod gem;
>> pub mod ioctl;
>> pub mod mm;
>> +pub mod syncobj;
>> diff --git a/rust/kernel/drm/syncobj.rs b/rust/kernel/drm/syncobj.rs
>> new file mode 100644
>> index 000000000000..10eed05eb27a
>> --- /dev/null
>> +++ b/rust/kernel/drm/syncobj.rs
>> @@ -0,0 +1,77 @@
>> +// SPDX-License-Identifier: GPL-2.0 OR MIT
>> +
>> +//! DRM Sync Objects
>> +//!
>> +//! C header: [`include/linux/drm/drm_syncobj.h`](../../../../include/linux/drm/drm_syncobj.h)
>> +
>> +use crate::{bindings, dma_fence::*, drm, error::Result, prelude::*};
>> +
>> +/// A DRM Sync Object
>> +///
>> +/// # Invariants
>> +/// ptr is a valid pointer to a drm_syncobj and we own a reference to it.
>> +pub struct SyncObj {
>> + ptr: *mut bindings::drm_syncobj,
>> +}
>> +
>> +impl SyncObj {
>> + /// Looks up a sync object by its handle for a given `File`.
>> + pub fn lookup_handle(file: &impl drm::file::GenericFile, handle: u32) -> Result<SyncObj> {
>> + // SAFETY: The arguments are all valid per the type invariants.
>> + let ptr = unsafe { bindings::drm_syncobj_find(file.raw() as *mut _, handle) };
>
> Just an aside, but the semantics of this are nasty: You're not allowed to
> hold any locks while calling this. We have runtime checks for that (if you
> enable lockdep), but I don't see any way to encode that on the rust side
> and check it at compile time :-/
Oof, yeah, that's not possible today. Maybe in the future though, it's
similar to the execution context stuff...
>
>> +
>> + if ptr.is_null() {
>> + Err(ENOENT)
>> + } else {
>> + Ok(SyncObj { ptr })
>> + }
>> + }
>> +
>> + /// Returns the DMA fence associated with this sync object, if any.
>> + pub fn fence_get(&self) -> Option<Fence> {
>> + let fence = unsafe { bindings::drm_syncobj_fence_get(self.ptr) };
>> + if fence.is_null() {
>> + None
>> + } else {
>> + // SAFETY: The pointer is non-NULL and drm_syncobj_fence_get acquired an
>> + // additional reference.
>> + Some(unsafe { Fence::from_raw(fence) })
>> + }
>> + }
>> +
>> + /// Replaces the DMA fence with a new one, or removes it if fence is None.
>> + pub fn replace_fence(&self, fence: Option<&Fence>) {
>> + unsafe {
>> + bindings::drm_syncobj_replace_fence(
>> + self.ptr,
>> + fence.map_or(core::ptr::null_mut(), |a| a.raw()),
>> + )
>> + };
>> + }
>> +
>> + /// Adds a new timeline point to the syncobj.
>> + pub fn add_point(&self, chain: FenceChain, fence: &Fence, point: u64) {
>> + // SAFETY: All arguments should be valid per the respective type invariants.
>> + // This takes over the FenceChain ownership.
>> + unsafe { bindings::drm_syncobj_add_point(self.ptr, chain.into_raw(), fence.raw(), point) };
>> + }
>> +}
>> +
>> +impl Drop for SyncObj {
>> + fn drop(&mut self) {
>> + // SAFETY: We own a reference to this syncobj.
>> + unsafe { bindings::drm_syncobj_put(self.ptr) };
>> + }
>> +}
>> +
>> +impl Clone for SyncObj {
>> + fn clone(&self) -> Self {
>> + // SAFETY: `ptr` is valid per the type invariant and we own a reference to it.
>> + unsafe { bindings::drm_syncobj_get(self.ptr) };
>
> So yeah syncobj are refcounted because they're shareable uapi objects (you
> can pass them around as fd), but that really should be entirely the
> subsystems business, not for drivers.
>
> This is kinda like drm_file, which is also refcounted (by virtue of
> hanging of struct file), but the refcounting is entirely handled by the
> vfs and all drivers get is a borrowed reference, which nicely bounds the
> lifetime to the callback (which is usually an ioctl handler). I think we
> want the same semantics for syncobj, because if a driver is hanging onto a
> syncobj for longer than the ioctl. If my rust understanding is right we'd
> get that by dropping Clone here and relying on lookup_handle only being
> able to return stuff that's bound by the drm_file?
Yeah, that should work! Lifetimes are perfect for this kind of stuff. I
need to test it out and see what the right way to do it is (lifetime
parameter or actual reference straight into the drm_syncobj) and see how
it fits into the driver but I don't see why it wouldn't work, since I
don't hold onto sync objects for longer than the ioctl. Might just need
some minor refactoring since the current driver ioctl code wasn't
written with lifetimes in mind ^^
> People are talking about drivers holding onto syncobj for longer, but I'm
> still not sold on the idea that this is any good and doesn't just bend the
> dma_fence and syncobj rules a bit too much over the breaking point. For
> kernel drivers it really should be just a different way to lookup and
> return dma_fence from the ioctl, pretty much matching what you could also
> do with sync_file (but since syncobj provides generic compat ioctl to
> convert to/from sync_file drivders only need to handle syncobj).
Yeah, if you think restricting the API for this on the Rust side makes
sense it works for me! I'm all for not abstracting features that aren't
considered particularly useful/safe/a good idea.
> -Daniel
>
>
>> + SyncObj { ptr: self.ptr }
>> + }
>> +}
>> +
>> +// SAFETY: drm_syncobj operations are internally locked.
>> +unsafe impl Sync for SyncObj {}
>> +unsafe impl Send for SyncObj {}
>>
>> --
>> 2.35.1
>>
>
~~ Lina
^ permalink raw reply [flat|nested] 122+ messages in thread
* [PATCH RFC 10/18] drm/scheduler: Add can_run_job callback
2023-03-07 14:25 [PATCH RFC 00/18] Rust DRM subsystem abstractions (& preview AGX driver) Asahi Lina
` (8 preceding siblings ...)
2023-03-07 14:25 ` [PATCH RFC 09/18] rust: drm: syncobj: Add DRM Sync Object abstraction Asahi Lina
@ 2023-03-07 14:25 ` Asahi Lina
2023-03-08 8:46 ` Christian König
2023-04-05 13:40 ` Daniel Vetter
2023-03-07 14:25 ` [PATCH RFC 11/18] drm/scheduler: Clean up jobs when the scheduler is torn down Asahi Lina
` (8 subsequent siblings)
18 siblings, 2 replies; 122+ messages in thread
From: Asahi Lina @ 2023-03-07 14:25 UTC (permalink / raw)
To: Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
David Airlie, Daniel Vetter, Miguel Ojeda, Alex Gaynor,
Wedson Almeida Filho, Boqun Feng, Gary Guo, Björn Roy Baron,
Sumit Semwal, Christian König, Luben Tuikov,
Jarkko Sakkinen, Dave Hansen
Cc: Alyssa Rosenzweig, Karol Herbst, Ella Stanforth, Faith Ekstrand,
Mary, linux-kernel, dri-devel, rust-for-linux, linux-media,
linaro-mm-sig, linux-sgx, asahi, Asahi Lina
Some hardware may require more complex resource utilization accounting
than the simple job count supported by drm_sched internally. Add a
can_run_job callback to allow drivers to implement more logic before
deciding whether to run a GPU job.
Signed-off-by: Asahi Lina <lina@asahilina.net>
---
drivers/gpu/drm/scheduler/sched_main.c | 10 ++++++++++
include/drm/gpu_scheduler.h | 8 ++++++++
2 files changed, 18 insertions(+)
diff --git a/drivers/gpu/drm/scheduler/sched_main.c b/drivers/gpu/drm/scheduler/sched_main.c
index 4e6ad6e122bc..5c0add2c7546 100644
--- a/drivers/gpu/drm/scheduler/sched_main.c
+++ b/drivers/gpu/drm/scheduler/sched_main.c
@@ -1001,6 +1001,16 @@ static int drm_sched_main(void *param)
if (!entity)
continue;
+ if (sched->ops->can_run_job) {
+ sched_job = to_drm_sched_job(spsc_queue_peek(&entity->job_queue));
+ if (!sched_job) {
+ complete_all(&entity->entity_idle);
+ continue;
+ }
+ if (!sched->ops->can_run_job(sched_job))
+ continue;
+ }
+
sched_job = drm_sched_entity_pop_job(entity);
if (!sched_job) {
diff --git a/include/drm/gpu_scheduler.h b/include/drm/gpu_scheduler.h
index 9db9e5e504ee..bd89ea9507b9 100644
--- a/include/drm/gpu_scheduler.h
+++ b/include/drm/gpu_scheduler.h
@@ -396,6 +396,14 @@ struct drm_sched_backend_ops {
struct dma_fence *(*prepare_job)(struct drm_sched_job *sched_job,
struct drm_sched_entity *s_entity);
+ /**
+ * @can_run_job: Called before job execution to check whether the
+ * hardware is free enough to run the job. This can be used to
+ * implement more complex hardware resource policies than the
+ * hw_submission limit.
+ */
+ bool (*can_run_job)(struct drm_sched_job *sched_job);
+
/**
* @run_job: Called to execute the job once all of the dependencies
* have been resolved. This may be called multiple times, if
--
2.35.1
^ permalink raw reply related [flat|nested] 122+ messages in thread* Re: [PATCH RFC 10/18] drm/scheduler: Add can_run_job callback
2023-03-07 14:25 ` [PATCH RFC 10/18] drm/scheduler: Add can_run_job callback Asahi Lina
@ 2023-03-08 8:46 ` Christian König
2023-03-08 9:41 ` Asahi Lina
2023-03-08 12:39 ` Karol Herbst
2023-04-05 13:40 ` Daniel Vetter
1 sibling, 2 replies; 122+ messages in thread
From: Christian König @ 2023-03-08 8:46 UTC (permalink / raw)
To: Asahi Lina, Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
David Airlie, Daniel Vetter, Miguel Ojeda, Alex Gaynor,
Wedson Almeida Filho, Boqun Feng, Gary Guo, Björn Roy Baron,
Sumit Semwal, Luben Tuikov, Jarkko Sakkinen, Dave Hansen
Cc: Alyssa Rosenzweig, Karol Herbst, Ella Stanforth, Faith Ekstrand,
Mary, linux-kernel, dri-devel, rust-for-linux, linux-media,
linaro-mm-sig, linux-sgx, asahi
Am 07.03.23 um 15:25 schrieb Asahi Lina:
> Some hardware may require more complex resource utilization accounting
> than the simple job count supported by drm_sched internally. Add a
> can_run_job callback to allow drivers to implement more logic before
> deciding whether to run a GPU job.
Well complete NAK.
This is clearly going against the idea of having jobs only depend on
fences and nothing else which is mandatory for correct memory management.
If the hw is busy with something you need to return the fence for this
from the prepare_job callback so that the scheduler can be notified when
the hw is available again.
Regards,
Christian.
>
> Signed-off-by: Asahi Lina <lina@asahilina.net>
> ---
> drivers/gpu/drm/scheduler/sched_main.c | 10 ++++++++++
> include/drm/gpu_scheduler.h | 8 ++++++++
> 2 files changed, 18 insertions(+)
>
> diff --git a/drivers/gpu/drm/scheduler/sched_main.c b/drivers/gpu/drm/scheduler/sched_main.c
> index 4e6ad6e122bc..5c0add2c7546 100644
> --- a/drivers/gpu/drm/scheduler/sched_main.c
> +++ b/drivers/gpu/drm/scheduler/sched_main.c
> @@ -1001,6 +1001,16 @@ static int drm_sched_main(void *param)
> if (!entity)
> continue;
>
> + if (sched->ops->can_run_job) {
> + sched_job = to_drm_sched_job(spsc_queue_peek(&entity->job_queue));
> + if (!sched_job) {
> + complete_all(&entity->entity_idle);
> + continue;
> + }
> + if (!sched->ops->can_run_job(sched_job))
> + continue;
> + }
> +
> sched_job = drm_sched_entity_pop_job(entity);
>
> if (!sched_job) {
> diff --git a/include/drm/gpu_scheduler.h b/include/drm/gpu_scheduler.h
> index 9db9e5e504ee..bd89ea9507b9 100644
> --- a/include/drm/gpu_scheduler.h
> +++ b/include/drm/gpu_scheduler.h
> @@ -396,6 +396,14 @@ struct drm_sched_backend_ops {
> struct dma_fence *(*prepare_job)(struct drm_sched_job *sched_job,
> struct drm_sched_entity *s_entity);
>
> + /**
> + * @can_run_job: Called before job execution to check whether the
> + * hardware is free enough to run the job. This can be used to
> + * implement more complex hardware resource policies than the
> + * hw_submission limit.
> + */
> + bool (*can_run_job)(struct drm_sched_job *sched_job);
> +
> /**
> * @run_job: Called to execute the job once all of the dependencies
> * have been resolved. This may be called multiple times, if
>
^ permalink raw reply [flat|nested] 122+ messages in thread* Re: [PATCH RFC 10/18] drm/scheduler: Add can_run_job callback
2023-03-08 8:46 ` Christian König
@ 2023-03-08 9:41 ` Asahi Lina
2023-03-08 10:00 ` Christian König
2023-03-08 12:39 ` Karol Herbst
1 sibling, 1 reply; 122+ messages in thread
From: Asahi Lina @ 2023-03-08 9:41 UTC (permalink / raw)
To: Christian König, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Daniel Vetter, Miguel Ojeda,
Alex Gaynor, Wedson Almeida Filho, Boqun Feng, Gary Guo,
Björn Roy Baron, Sumit Semwal, Luben Tuikov,
Jarkko Sakkinen, Dave Hansen
Cc: Alyssa Rosenzweig, Karol Herbst, Ella Stanforth, Faith Ekstrand,
Mary, linux-kernel, dri-devel, rust-for-linux, linux-media,
linaro-mm-sig, linux-sgx, asahi
On 08/03/2023 17.46, Christian König wrote:
> Am 07.03.23 um 15:25 schrieb Asahi Lina:
>> Some hardware may require more complex resource utilization accounting
>> than the simple job count supported by drm_sched internally. Add a
>> can_run_job callback to allow drivers to implement more logic before
>> deciding whether to run a GPU job.
>
> Well complete NAK.
>
> This is clearly going against the idea of having jobs only depend on
> fences and nothing else which is mandatory for correct memory management.
>
> If the hw is busy with something you need to return the fence for this
> from the prepare_job callback so that the scheduler can be notified when
> the hw is available again.
I think you misunderstood the intent here... This isn't about job
dependencies, it's about in-flight resource limits.
drm_sched already has a hw_submission_limit that specifies the number of
submissions that can be in flight, but that doesn't work for us because
each job from drm_sched's point of view consists of multiple commands
split among 3 firmware queues. The firmware can only support up to 128
work commands in flight per queue (barriers don't count), otherwise it
overflows a fixed-size buffer.
So we need more complex accounting of how many underlying commands are
in flight per queue to determine whether it is safe to run a new job,
and that is what this callback accomplishes. This has to happen even
when individual jobs have no buffer/resource dependencies between them
(which is what the fences would express).
You can see the driver implementation of that callback in
drivers/gpu/drm/asahi/queue/mod.rs (QueueJob::can_run()), which then
calls into drivers/gpu/drm/asahi/workqueue.rs (Job::can_submit()) that
does the actual available slot count checks.
The can_run_job logic is written to mirror the hw_submission_limit logic
(just a bit later in the sched main loop since we need to actually pick
a job to do the check), and just like for that case, completion of any
job in the same scheduler will cause another run of the main loop and
another check (which is exactly what we want here).
This case (potentially scheduling more than the FW job limit) is rare
but handling it is necessary, since otherwise the entire job
completion/tracking logic gets screwed up on the firmware end and queues
end up stuck (I've managed to trigger this before).
~~ Lina
^ permalink raw reply [flat|nested] 122+ messages in thread
* Re: [PATCH RFC 10/18] drm/scheduler: Add can_run_job callback
2023-03-08 9:41 ` Asahi Lina
@ 2023-03-08 10:00 ` Christian König
2023-03-08 14:53 ` Asahi Lina
0 siblings, 1 reply; 122+ messages in thread
From: Christian König @ 2023-03-08 10:00 UTC (permalink / raw)
To: Asahi Lina, Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
David Airlie, Daniel Vetter, Miguel Ojeda, Alex Gaynor,
Wedson Almeida Filho, Boqun Feng, Gary Guo, Björn Roy Baron,
Sumit Semwal, Luben Tuikov, Jarkko Sakkinen, Dave Hansen
Cc: Alyssa Rosenzweig, Karol Herbst, Ella Stanforth, Faith Ekstrand,
Mary, linux-kernel, dri-devel, rust-for-linux, linux-media,
linaro-mm-sig, linux-sgx, asahi
Am 08.03.23 um 10:41 schrieb Asahi Lina:
> On 08/03/2023 17.46, Christian König wrote:
>> Am 07.03.23 um 15:25 schrieb Asahi Lina:
>>> Some hardware may require more complex resource utilization accounting
>>> than the simple job count supported by drm_sched internally. Add a
>>> can_run_job callback to allow drivers to implement more logic before
>>> deciding whether to run a GPU job.
>> Well complete NAK.
>>
>> This is clearly going against the idea of having jobs only depend on
>> fences and nothing else which is mandatory for correct memory management.
>>
>> If the hw is busy with something you need to return the fence for this
>> from the prepare_job callback so that the scheduler can be notified when
>> the hw is available again.
> I think you misunderstood the intent here... This isn't about job
> dependencies, it's about in-flight resource limits.
>
> drm_sched already has a hw_submission_limit that specifies the number of
> submissions that can be in flight, but that doesn't work for us because
> each job from drm_sched's point of view consists of multiple commands
> split among 3 firmware queues. The firmware can only support up to 128
> work commands in flight per queue (barriers don't count), otherwise it
> overflows a fixed-size buffer.
>
> So we need more complex accounting of how many underlying commands are
> in flight per queue to determine whether it is safe to run a new job,
> and that is what this callback accomplishes. This has to happen even
> when individual jobs have no buffer/resource dependencies between them
> (which is what the fences would express).
Yeah, I already assumed that you have something like this.
And to make it clear this is unfortunately a complete NAK to this
approach! You can't do this!
The background is that core memory management requires that signaling a
fence only depends on signaling other fences and hardware progress and
nothing else. Otherwise you immediately run into problems because of
circle dependencies or what we call infinite fences.
Jason Ekstrand gave a create presentation on that problem a few years
ago on LPC. I strongly suggest you google that one up.
> You can see the driver implementation of that callback in
> drivers/gpu/drm/asahi/queue/mod.rs (QueueJob::can_run()), which then
> calls into drivers/gpu/drm/asahi/workqueue.rs (Job::can_submit()) that
> does the actual available slot count checks.
>
> The can_run_job logic is written to mirror the hw_submission_limit logic
> (just a bit later in the sched main loop since we need to actually pick
> a job to do the check), and just like for that case, completion of any
> job in the same scheduler will cause another run of the main loop and
> another check (which is exactly what we want here).
Yeah and that hw_submission_limit is based on a fence signaling again.
When you have some firmware limitation that a job needs resources which
are currently in use by other submissions then those other submissions
have fences as well and you can return those in the prepare_job callback.
If those other submissions don't have fences, then you have a major
design problem inside your driver and we need to get back to square one
and talk about that dependency handling.
> This case (potentially scheduling more than the FW job limit) is rare
> but handling it is necessary, since otherwise the entire job
> completion/tracking logic gets screwed up on the firmware end and queues
> end up stuck (I've managed to trigger this before).
Actually that's a pretty normal use case. I've have rejected similar
requirements like this before as well.
For an example how this can work see amdgpu_job_prepare_job():
https://elixir.bootlin.com/linux/v6.3-rc1/source/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c#L251
The gang submit gives and example of a global fence lock and the VMIDs
are an example of a global shared firmware resource.
Regards,
Christian.
>
> ~~ Lina
^ permalink raw reply [flat|nested] 122+ messages in thread
* Re: [PATCH RFC 10/18] drm/scheduler: Add can_run_job callback
2023-03-08 10:00 ` Christian König
@ 2023-03-08 14:53 ` Asahi Lina
2023-03-08 15:30 ` Christian König
0 siblings, 1 reply; 122+ messages in thread
From: Asahi Lina @ 2023-03-08 14:53 UTC (permalink / raw)
To: Christian König, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Daniel Vetter, Miguel Ojeda,
Alex Gaynor, Wedson Almeida Filho, Boqun Feng, Gary Guo,
Björn Roy Baron, Sumit Semwal, Luben Tuikov,
Jarkko Sakkinen, Dave Hansen
Cc: Alyssa Rosenzweig, Karol Herbst, Ella Stanforth, Faith Ekstrand,
Mary, linux-kernel, dri-devel, rust-for-linux, linux-media,
linaro-mm-sig, linux-sgx, asahi
On 08/03/2023 19.00, Christian König wrote:
> Am 08.03.23 um 10:41 schrieb Asahi Lina:
>> On 08/03/2023 17.46, Christian König wrote:
>>> Am 07.03.23 um 15:25 schrieb Asahi Lina:
>>>> Some hardware may require more complex resource utilization accounting
>>>> than the simple job count supported by drm_sched internally. Add a
>>>> can_run_job callback to allow drivers to implement more logic before
>>>> deciding whether to run a GPU job.
>>> Well complete NAK.
>>>
>>> This is clearly going against the idea of having jobs only depend on
>>> fences and nothing else which is mandatory for correct memory management.
>>>
>>> If the hw is busy with something you need to return the fence for this
>>> from the prepare_job callback so that the scheduler can be notified when
>>> the hw is available again.
>> I think you misunderstood the intent here... This isn't about job
>> dependencies, it's about in-flight resource limits.
>>
>> drm_sched already has a hw_submission_limit that specifies the number of
>> submissions that can be in flight, but that doesn't work for us because
>> each job from drm_sched's point of view consists of multiple commands
>> split among 3 firmware queues. The firmware can only support up to 128
>> work commands in flight per queue (barriers don't count), otherwise it
>> overflows a fixed-size buffer.
>>
>> So we need more complex accounting of how many underlying commands are
>> in flight per queue to determine whether it is safe to run a new job,
>> and that is what this callback accomplishes. This has to happen even
>> when individual jobs have no buffer/resource dependencies between them
>> (which is what the fences would express).
>
> Yeah, I already assumed that you have something like this.
>
> And to make it clear this is unfortunately a complete NAK to this
> approach! You can't do this!
I think you still have some significant misconception about how this
driver works and uses drm_sched... I would appreciate it if you listen
and try to understand the design before giving hard NAKs... (this isn't
a Radeon)
> The background is that core memory management requires that signaling a
> fence only depends on signaling other fences and hardware progress and
> nothing else. Otherwise you immediately run into problems because of
> circle dependencies or what we call infinite fences.
And hardware progress is exactly the only dependency here...
> Jason Ekstrand gave a create presentation on that problem a few years
> ago on LPC. I strongly suggest you google that one up.
Faith Ekstrand (it looks like you mistyped that name...) is the person
who proposed that I should use drm_sched in this way (see below), we've
had a few private meetings about this design ^^
>> You can see the driver implementation of that callback in
>> drivers/gpu/drm/asahi/queue/mod.rs (QueueJob::can_run()), which then
>> calls into drivers/gpu/drm/asahi/workqueue.rs (Job::can_submit()) that
>> does the actual available slot count checks.
>>
>> The can_run_job logic is written to mirror the hw_submission_limit logic
>> (just a bit later in the sched main loop since we need to actually pick
>> a job to do the check), and just like for that case, completion of any
>> job in the same scheduler will cause another run of the main loop and
>> another check (which is exactly what we want here).
>
> Yeah and that hw_submission_limit is based on a fence signaling again.
I don't think so...? It's just an atomic that gets checked in
drm_sched_ready(). There are no extra fences involved (other than the
job completion fences that trigger another scheduler run). The idea is
that when the hardware queue makes forward progress you check against
the limit again and submit more jobs as needed. I'm doing the same exact
thing, I'm just using more complex logic for the notion of in-flight
queue limits!
> When you have some firmware limitation that a job needs resources which
> are currently in use by other submissions then those other submissions
> have fences as well and you can return those in the prepare_job callback.
>
> If those other submissions don't have fences, then you have a major
> design problem inside your driver and we need to get back to square one
> and talk about that dependency handling.
I think we have a disconnect in our views of what is going on here...
This hardware has firmware-side scheduling with an arbitrary (as far as
I know) number of queues. There is one scheduler instance and one entity
per userspace queue (not global!). These queues process jobs in some
logical sequence, though at the firmware level they get split into up to
three queues each (and there is some parallelism allowed). The
limitation here is in the number of in-flight jobs per firmware queue,
not global.
There is no way for things to deadlock. If jobs have been submitted to
the firmware queue, that means their dependencies were signaled already.
Jobs have intra-job dependencies via driver barriers (which drm_sched
knows nothing about), but the submission code in the driver guarantees
that they are deadlock-free since you can only barrier on past commands,
which by definition submit first.
If a firmware queue is full, drm_sched blocks. Since it is full, that
means it will run those commands (since they have no outside
dependencies and they are already queued and ready to run by the
firmware), eventually space will be freed, and each time a job completes
drm_sched will do the can_run_job check again and decide whether to run
a new job.
Since the firmware queues contain commands which only have past-facing
barriers on other already submitted commands, by definition they will
become empty at some point as long as the firmware is making forward
progress. And therefore, by definition, can_run_job will eventually
return true at some point after a job completion fence is signaled (the
one for the last job submitted prior). There is a check in the driver to
ensure that we do not allow submissions which, by themselves, would
exceed the queued command limit (we actually just limit to 64 commands
overall right now, which is conservative but seems reasonable given the
128-per-firmware-queue limit).
I get the feeling that you are conflating pending jobs with submitted
jobs. This isn't about how many jobs you can have pending in drm_sched
before running them or anything like that. Of course, at that point,
arbitrary dependencies come into play and you can end up with deadlocks
on dependency fences. But that's not the case here. What can_run_job is
waiting on is guaranteed to make forward progress.
>> This case (potentially scheduling more than the FW job limit) is rare
>> but handling it is necessary, since otherwise the entire job
>> completion/tracking logic gets screwed up on the firmware end and queues
>> end up stuck (I've managed to trigger this before).
>
> Actually that's a pretty normal use case. I've have rejected similar
> requirements like this before as well.
>
> For an example how this can work see amdgpu_job_prepare_job():
> https://elixir.bootlin.com/linux/v6.3-rc1/source/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c#L251
>
> The gang submit gives and example of a global fence lock and the VMIDs
> are an example of a global shared firmware resource.
But the resource can_run_job is checking on isn't globally shared! It's
specific to this scheduler instance, just like hw_submission_limit is,
so as long as the firmware behind the scheduler is making forward
progress, the resource will be guaranteed to be freed until another job
can run.
I actually know I have a different theoretical deadlock issue along
these lines in the driver because right now we grab actually global
resources (including a VMID) before job submission to drm_sched. This is
a known issue, and to fix it without reducing performance I need to
introduce some kind of "patching/fixup" system for firmware commands
(because we need to inject those identifiers in dozens of places, but we
don't want to construct those commands from scratch at job run time
because that introduces latency at the wrong time and makes error
handling/validation more complicated and error-prone), and that is
exactly what should happen in prepare_job, as you say. And yes, at that
point that should use fences to block when those resources are
exhausted. But that's a different discussion we should have when
reviewing the driver, it has nothing to do with the DRM abstractions nor
the can_run_job callback I'm adding here nor the firmware queue length
limit issue! (And also the global hardware devices are plentiful enough
that I would be very surprised if anyone ever deadlocks it in practice
even with the current code, so I honestly don't think that should be a
blocker for driver submission either, I can and will fix it later...)
~~ Lina
^ permalink raw reply [flat|nested] 122+ messages in thread
* Re: [PATCH RFC 10/18] drm/scheduler: Add can_run_job callback
2023-03-08 14:53 ` Asahi Lina
@ 2023-03-08 15:30 ` Christian König
2023-03-08 16:44 ` Asahi Lina
0 siblings, 1 reply; 122+ messages in thread
From: Christian König @ 2023-03-08 15:30 UTC (permalink / raw)
To: Asahi Lina, Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
David Airlie, Daniel Vetter, Miguel Ojeda, Alex Gaynor,
Wedson Almeida Filho, Boqun Feng, Gary Guo, Björn Roy Baron,
Sumit Semwal, Luben Tuikov, Jarkko Sakkinen, Dave Hansen
Cc: Alyssa Rosenzweig, Karol Herbst, Ella Stanforth, Faith Ekstrand,
Mary, linux-kernel, dri-devel, rust-for-linux, linux-media,
linaro-mm-sig, linux-sgx, asahi
Am 08.03.23 um 15:53 schrieb Asahi Lina:
> [SNIP]
>> The background is that core memory management requires that signaling a
>> fence only depends on signaling other fences and hardware progress and
>> nothing else. Otherwise you immediately run into problems because of
>> circle dependencies or what we call infinite fences.
> And hardware progress is exactly the only dependency here...
Well then you should have a fence for that hardware progress.
>> Jason Ekstrand gave a create presentation on that problem a few years
>> ago on LPC. I strongly suggest you google that one up.
> Faith Ekstrand (it looks like you mistyped that name...)
My fault I was really just mistyping that :)
> is the person
> who proposed that I should use drm_sched in this way (see below), we've
> had a few private meetings about this design ^^
>
>>> You can see the driver implementation of that callback in
>>> drivers/gpu/drm/asahi/queue/mod.rs (QueueJob::can_run()), which then
>>> calls into drivers/gpu/drm/asahi/workqueue.rs (Job::can_submit()) that
>>> does the actual available slot count checks.
>>>
>>> The can_run_job logic is written to mirror the hw_submission_limit logic
>>> (just a bit later in the sched main loop since we need to actually pick
>>> a job to do the check), and just like for that case, completion of any
>>> job in the same scheduler will cause another run of the main loop and
>>> another check (which is exactly what we want here).
>> Yeah and that hw_submission_limit is based on a fence signaling again.
> I don't think so...? It's just an atomic that gets checked in
> drm_sched_ready(). There are no extra fences involved (other than the
> job completion fences that trigger another scheduler run). The idea is
> that when the hardware queue makes forward progress you check against
> the limit again and submit more jobs as needed. I'm doing the same exact
> thing, I'm just using more complex logic for the notion of in-flight
> queue limits!
Then why can't you express that logic in a dependency fence?
>> When you have some firmware limitation that a job needs resources which
>> are currently in use by other submissions then those other submissions
>> have fences as well and you can return those in the prepare_job callback.
>>
>> If those other submissions don't have fences, then you have a major
>> design problem inside your driver and we need to get back to square one
>> and talk about that dependency handling.
> I think we have a disconnect in our views of what is going on here...
>
> This hardware has firmware-side scheduling with an arbitrary (as far as
> I know) number of queues. There is one scheduler instance and one entity
> per userspace queue (not global!). These queues process jobs in some
> logical sequence, though at the firmware level they get split into up to
> three queues each (and there is some parallelism allowed). The
> limitation here is in the number of in-flight jobs per firmware queue,
> not global.
So far I'm familiar with that design.
> There is no way for things to deadlock. If jobs have been submitted to
> the firmware queue, that means their dependencies were signaled already.
> Jobs have intra-job dependencies via driver barriers (which drm_sched
> knows nothing about), but the submission code in the driver guarantees
> that they are deadlock-free since you can only barrier on past commands,
> which by definition submit first.
>
> If a firmware queue is full, drm_sched blocks. Since it is full, that
> means it will run those commands (since they have no outside
> dependencies and they are already queued and ready to run by the
> firmware), eventually space will be freed, and each time a job completes
> drm_sched will do the can_run_job check again and decide whether to run
> a new job.
>
> Since the firmware queues contain commands which only have past-facing
> barriers on other already submitted commands, by definition they will
> become empty at some point as long as the firmware is making forward
> progress. And therefore, by definition, can_run_job will eventually
> return true at some point after a job completion fence is signaled (the
> one for the last job submitted prior). There is a check in the driver to
> ensure that we do not allow submissions which, by themselves, would
> exceed the queued command limit (we actually just limit to 64 commands
> overall right now, which is conservative but seems reasonable given the
> 128-per-firmware-queue limit).
Well then again why don't you give that fence out as dependency? Is it
because the scheduler tries to optimize those away?
> I get the feeling that you are conflating pending jobs with submitted
> jobs. This isn't about how many jobs you can have pending in drm_sched
> before running them or anything like that. Of course, at that point,
> arbitrary dependencies come into play and you can end up with deadlocks
> on dependency fences. But that's not the case here. What can_run_job is
> waiting on is guaranteed to make forward progress.
I see that we have a disconnection here. As far as I can see you can use
the can_run callback in only three ways:
1. To check for some userspace dependency (We don't need to discuss
that, it's evil and we both know it).
2. You check for some hw resource availability. Similar to VMID on
amdgpu hw.
This is what I think you do here (but I might be wrong). But this
would be extremely problematic because you can then live lock.
E.g. queue A keeps submitting jobs which take only a few resources
and by doing so delays submitting jobs from queue B indefinitely.
3. You have an intra queue dependency. E.g. you have jobs which take X
amount of resources, you can submit only to a specific limit.
But in this case you should be able to return fences from the same
queue as dependency and won't need that callback.
We would just need to adjust drm_sched_entity_add_dependency_cb() a
bit because dependencies from the same queue are currently filtered out
because it assumes a pipeline nature of submission (e.g. previous
submissions are finished before new submissions start).
>>> This case (potentially scheduling more than the FW job limit) is rare
>>> but handling it is necessary, since otherwise the entire job
>>> completion/tracking logic gets screwed up on the firmware end and queues
>>> end up stuck (I've managed to trigger this before).
>> Actually that's a pretty normal use case. I've have rejected similar
>> requirements like this before as well.
>>
>> For an example how this can work see amdgpu_job_prepare_job():
>> https://elixir.bootlin.com/linux/v6.3-rc1/source/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c#L251
>>
>> The gang submit gives and example of a global fence lock and the VMIDs
>> are an example of a global shared firmware resource.
> But the resource can_run_job is checking on isn't globally shared! It's
> specific to this scheduler instance, just like hw_submission_limit is,
> so as long as the firmware behind the scheduler is making forward
> progress, the resource will be guaranteed to be freed until another job
> can run.
Well either it should be globally shared because it is a shared resource
(similar to our VMID or gangs) or it is an intra queue limitation in
which case you could just use the fences previously submitted on the
queue as dependency.
> I actually know I have a different theoretical deadlock issue along
> these lines in the driver because right now we grab actually global
> resources (including a VMID) before job submission to drm_sched. This is
> a known issue, and to fix it without reducing performance I need to
> introduce some kind of "patching/fixup" system for firmware commands
> (because we need to inject those identifiers in dozens of places, but we
> don't want to construct those commands from scratch at job run time
> because that introduces latency at the wrong time and makes error
> handling/validation more complicated and error-prone), and that is
> exactly what should happen in prepare_job, as you say. And yes, at that
> point that should use fences to block when those resources are
> exhausted. But that's a different discussion we should have when
> reviewing the driver, it has nothing to do with the DRM abstractions nor
> the can_run_job callback I'm adding here nor the firmware queue length
> limit issue! (And also the global hardware devices are plentiful enough
> that I would be very surprised if anyone ever deadlocks it in practice
> even with the current code, so I honestly don't think that should be a
> blocker for driver submission either, I can and will fix it later...)
Well this is what I thought about those problems in amdgpu as well and
it totally shipwrecked.
We still have memory allocations in the VMID code path which I'm still
not sure how to remove.
Regards,
Christian.
>
> ~~ Lina
^ permalink raw reply [flat|nested] 122+ messages in thread
* Re: [PATCH RFC 10/18] drm/scheduler: Add can_run_job callback
2023-03-08 15:30 ` Christian König
@ 2023-03-08 16:44 ` Asahi Lina
2023-03-08 17:57 ` Christian König
0 siblings, 1 reply; 122+ messages in thread
From: Asahi Lina @ 2023-03-08 16:44 UTC (permalink / raw)
To: Christian König, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Daniel Vetter, Miguel Ojeda,
Alex Gaynor, Wedson Almeida Filho, Boqun Feng, Gary Guo,
Björn Roy Baron, Sumit Semwal, Luben Tuikov,
Jarkko Sakkinen, Dave Hansen
Cc: Alyssa Rosenzweig, Karol Herbst, Ella Stanforth, Faith Ekstrand,
Mary, linux-kernel, dri-devel, rust-for-linux, linux-media,
linaro-mm-sig, linux-sgx, asahi
On 09/03/2023 00.30, Christian König wrote:
> Am 08.03.23 um 15:53 schrieb Asahi Lina:
>> [SNIP]
>>> The background is that core memory management requires that signaling a
>>> fence only depends on signaling other fences and hardware progress and
>>> nothing else. Otherwise you immediately run into problems because of
>>> circle dependencies or what we call infinite fences.
>> And hardware progress is exactly the only dependency here...
>
> Well then you should have a fence for that hardware progress.
I do, it's the prior job hardware completion fences that drm_sched
already knows about!
Yes, I could return those in the prepare callback, it just means I need
to start stashing fence references in the underlying firmware job queue
command objects so I can find out what is the oldest pending fence is,
and return it when a queue is full. As long as drm_sched doesn't mind if
I keep giving it fences (since multiple commands can have to complete
before there is space) or the occasional already signaled fence (because
this process is inherently racy), it should work fine.
If you think this is the better way, I'll do it that way and drop this
patch. It just seemed simpler to do it with another callback, since
drm_sched is already tracking those fences and doing a hardware queue
limit check anyway, and that way I can avoid tracking the fences down
into the hardware queue code... *
(But I still maintain what I'm trying to do here is entirely correct and
deadlock-free! If you prefer I use prepare_job and return prior job
fences from that instead, that's very different from NAKing the patch
saying it's broken...)
* If you're wondering how the fences get signaled at all then: callback
closures that capture a reference to the fence when firmware commands
are constructed and submitted. I know, I know, fancy Rust stuff... ^^
If you'd rather have me use the fences for the blocking, I'll probably
just drop the signaling bit from the closures so we don't need to keep
two redundant fence references in different places per command. I still
need the closures for command completion processing though, since I use
them to process statistics too...
>>> Jason Ekstrand gave a create presentation on that problem a few years
>>> ago on LPC. I strongly suggest you google that one up.
>> Faith Ekstrand (it looks like you mistyped that name...)
>
> My fault I was really just mistyping that :)
It's all good ^^
>
> I see that we have a disconnection here. As far as I can see you can use
> the can_run callback in only three ways:
>
> 1. To check for some userspace dependency (We don't need to discuss
> that, it's evil and we both know it).
>
> 2. You check for some hw resource availability. Similar to VMID on
> amdgpu hw.
>
> This is what I think you do here (but I might be wrong).
It isn't... I agree, it would be problematic. It doesn't make any sense
to check for global resources this way, not just because you might
deadlock but also because there might be nothing to signal to the
scheduler that a resource was freed at all once it is!
> But this
> would be extremely problematic because you can then live lock.
> E.g. queue A keeps submitting jobs which take only a few resources
> and by doing so delays submitting jobs from queue B indefinitely.
This particular issue aside, fairness in global resource allocation is a
conversation I'd love to have! Right now the driver doesn't try to
ensure that, a queue can easily monopolize certain hardware resources
(though one queue can only monopolize one of each, so you'd need
something like 63 queues with 63 distinct VMs all submitting
free-running jobs back to back in order to starve other queues of
resources forever). For starters, one thing I'm thinking of doing is
reserving certain subsets of hardware resources for queues with a given
priority, so you can at least guarantee forward progress of
higher-priority queues when faced with misbehaving lower-priority
queues. But if we want to guarantee proper fairness, I think I'll have
to start doing things like switching to a CPU-roundtrip submission model
when resources become scarce (to guarantee that queues actually release
the resources once in a while) and then figure out how to add fairness
to the allocation code...
But let's have that conversation when we talk about the driver (or maybe
on IRC or something?), right now I'm more interested in getting the
abstractions reviewed ^^
> 3. You have an intra queue dependency. E.g. you have jobs which take X
> amount of resources, you can submit only to a specific limit.
> But in this case you should be able to return fences from the same
> queue as dependency and won't need that callback.
Yes, I can do this. I can just do the same check can_run_job() does and
if it fails, pick the oldest job in the full firmware queue and return
its fence (it just means I need to keep track of those fences there, as
I said above).
> We would just need to adjust drm_sched_entity_add_dependency_cb() a
> bit because dependencies from the same queue are currently filtered out
> because it assumes a pipeline nature of submission (e.g. previous
> submissions are finished before new submissions start).
Actually that should be fine, because I'd be returning the underlying
hardware completion fences (what the run() callback returns) which the
driver owns, and wouldn't be recognized as belonging to the sched.
>> I actually know I have a different theoretical deadlock issue along
>> these lines in the driver because right now we grab actually global
>> resources (including a VMID) before job submission to drm_sched. This is
>> a known issue, and to fix it without reducing performance I need to
>> introduce some kind of "patching/fixup" system for firmware commands
>> (because we need to inject those identifiers in dozens of places, but we
>> don't want to construct those commands from scratch at job run time
>> because that introduces latency at the wrong time and makes error
>> handling/validation more complicated and error-prone), and that is
>> exactly what should happen in prepare_job, as you say. And yes, at that
>> point that should use fences to block when those resources are
>> exhausted. But that's a different discussion we should have when
>> reviewing the driver, it has nothing to do with the DRM abstractions nor
>> the can_run_job callback I'm adding here nor the firmware queue length
>> limit issue! (And also the global hardware devices are plentiful enough
>> that I would be very surprised if anyone ever deadlocks it in practice
>> even with the current code, so I honestly don't think that should be a
>> blocker for driver submission either, I can and will fix it later...)
>
> Well this is what I thought about those problems in amdgpu as well and
> it totally shipwrecked.
>
> We still have memory allocations in the VMID code path which I'm still
> not sure how to remove.
We don't even have a shrinker yet, and I'm sure that's going to be a lot
of fun when we add it too... but yes, if we can't do any memory
allocations in some of these callbacks (is this documented anywhere?),
that's going to be interesting...
It's not all bad news though! All memory allocations are fallible in
kernel Rust (and therefore explicit, and also failures have to be
explicitly handled or propagated), so it's pretty easy to point out
where they are, and there are already discussions of higher-level
tooling to enforce rules like that (and things like wait contexts).
Also, Rust makes it a lot easier to refactor code in general and not be
scared that you're going to regress everything, so I'm not really
worried if I need to turn a chunk of the driver on its head to solve
some of these problems in the future ^^ (I already did that when I
switched it from the "demo" synchronous submission model to the proper
explicit sync + fences one.)
~~ Lina
^ permalink raw reply [flat|nested] 122+ messages in thread
* Re: [PATCH RFC 10/18] drm/scheduler: Add can_run_job callback
2023-03-08 16:44 ` Asahi Lina
@ 2023-03-08 17:57 ` Christian König
2023-03-08 19:05 ` Asahi Lina
0 siblings, 1 reply; 122+ messages in thread
From: Christian König @ 2023-03-08 17:57 UTC (permalink / raw)
To: Asahi Lina, Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
David Airlie, Daniel Vetter, Miguel Ojeda, Alex Gaynor,
Wedson Almeida Filho, Boqun Feng, Gary Guo, Björn Roy Baron,
Sumit Semwal, Luben Tuikov, Jarkko Sakkinen, Dave Hansen
Cc: Alyssa Rosenzweig, Karol Herbst, Ella Stanforth, Faith Ekstrand,
Mary, linux-kernel, dri-devel, rust-for-linux, linux-media,
linaro-mm-sig, linux-sgx, asahi
Am 08.03.23 um 17:44 schrieb Asahi Lina:
> On 09/03/2023 00.30, Christian König wrote:
>> Am 08.03.23 um 15:53 schrieb Asahi Lina:
>>> [SNIP]
>>>> The background is that core memory management requires that signaling a
>>>> fence only depends on signaling other fences and hardware progress and
>>>> nothing else. Otherwise you immediately run into problems because of
>>>> circle dependencies or what we call infinite fences.
>>> And hardware progress is exactly the only dependency here...
>> Well then you should have a fence for that hardware progress.
> I do, it's the prior job hardware completion fences that drm_sched
> already knows about!
>
> Yes, I could return those in the prepare callback, it just means I need
> to start stashing fence references in the underlying firmware job queue
> command objects so I can find out what is the oldest pending fence is,
> and return it when a queue is full. As long as drm_sched doesn't mind if
> I keep giving it fences (since multiple commands can have to complete
> before there is space) or the occasional already signaled fence (because
> this process is inherently racy), it should work fine.
Well this handling is intentional and necessary, but see below for a
more in deep explanation.
> If you think this is the better way, I'll do it that way and drop this
> patch. It just seemed simpler to do it with another callback, since
> drm_sched is already tracking those fences and doing a hardware queue
> limit check anyway, and that way I can avoid tracking the fences down
> into the hardware queue code... *
Well it's not the better way, it's the only way that works.
I have to admit that my bet on your intentions was wrong, but even that
use case doesn't work correctly.
See when your callback returns false it is perfectly possible that all
hw fences are signaled between returning that information and processing it.
The result would be that the scheduler goes to sleep and never wakes up
again.
That's why we have that rule that all dependencies need to be expressed
by those dma_fence objects, cause those are design with such races in mind.
> (But I still maintain what I'm trying to do here is entirely correct and
> deadlock-free! If you prefer I use prepare_job and return prior job
> fences from that instead, that's very different from NAKing the patch
> saying it's broken...)
As I said we exercised those ideas before and yes this approach here
came up before as well and no it doesn't work.
> * If you're wondering how the fences get signaled at all then: callback
> closures that capture a reference to the fence when firmware commands
> are constructed and submitted. I know, I know, fancy Rust stuff... ^^
> If you'd rather have me use the fences for the blocking, I'll probably
> just drop the signaling bit from the closures so we don't need to keep
> two redundant fence references in different places per command. I still
> need the closures for command completion processing though, since I use
> them to process statistics too...
>
>> I see that we have a disconnection here. As far as I can see you can use
>> the can_run callback in only three ways:
>>
>> 1. To check for some userspace dependency (We don't need to discuss
>> that, it's evil and we both know it).
>>
>> 2. You check for some hw resource availability. Similar to VMID on
>> amdgpu hw.
>>
>> This is what I think you do here (but I might be wrong).
> It isn't... I agree, it would be problematic. It doesn't make any sense
> to check for global resources this way, not just because you might
> deadlock but also because there might be nothing to signal to the
> scheduler that a resource was freed at all once it is!
>
>> But this
>> would be extremely problematic because you can then live lock.
>> E.g. queue A keeps submitting jobs which take only a few resources
>> and by doing so delays submitting jobs from queue B indefinitely.
> This particular issue aside, fairness in global resource allocation is a
> conversation I'd love to have! Right now the driver doesn't try to
> ensure that, a queue can easily monopolize certain hardware resources
> (though one queue can only monopolize one of each, so you'd need
> something like 63 queues with 63 distinct VMs all submitting
> free-running jobs back to back in order to starve other queues of
> resources forever). For starters, one thing I'm thinking of doing is
> reserving certain subsets of hardware resources for queues with a given
> priority, so you can at least guarantee forward progress of
> higher-priority queues when faced with misbehaving lower-priority
> queues. But if we want to guarantee proper fairness, I think I'll have
> to start doing things like switching to a CPU-roundtrip submission model
> when resources become scarce (to guarantee that queues actually release
> the resources once in a while) and then figure out how to add fairness
> to the allocation code...
>
> But let's have that conversation when we talk about the driver (or maybe
> on IRC or something?), right now I'm more interested in getting the
> abstractions reviewed ^^
Well that stuff is highly problematic as well. The fairness aside you
risk starvation which in turn breaks the guarantee of forward progress.
In this particular case you can catch this with a timeout for the hw
operation, but you should consider blocking that from the sw side as well.
>> 3. You have an intra queue dependency. E.g. you have jobs which take X
>> amount of resources, you can submit only to a specific limit.
>> But in this case you should be able to return fences from the same
>> queue as dependency and won't need that callback.
> Yes, I can do this. I can just do the same check can_run_job() does and
> if it fails, pick the oldest job in the full firmware queue and return
> its fence (it just means I need to keep track of those fences there, as
> I said above).
>
>> We would just need to adjust drm_sched_entity_add_dependency_cb() a
>> bit because dependencies from the same queue are currently filtered out
>> because it assumes a pipeline nature of submission (e.g. previous
>> submissions are finished before new submissions start).
> Actually that should be fine, because I'd be returning the underlying
> hardware completion fences (what the run() callback returns) which the
> driver owns, and wouldn't be recognized as belonging to the sched.
>
>>> I actually know I have a different theoretical deadlock issue along
>>> these lines in the driver because right now we grab actually global
>>> resources (including a VMID) before job submission to drm_sched. This is
>>> a known issue, and to fix it without reducing performance I need to
>>> introduce some kind of "patching/fixup" system for firmware commands
>>> (because we need to inject those identifiers in dozens of places, but we
>>> don't want to construct those commands from scratch at job run time
>>> because that introduces latency at the wrong time and makes error
>>> handling/validation more complicated and error-prone), and that is
>>> exactly what should happen in prepare_job, as you say. And yes, at that
>>> point that should use fences to block when those resources are
>>> exhausted. But that's a different discussion we should have when
>>> reviewing the driver, it has nothing to do with the DRM abstractions nor
>>> the can_run_job callback I'm adding here nor the firmware queue length
>>> limit issue! (And also the global hardware devices are plentiful enough
>>> that I would be very surprised if anyone ever deadlocks it in practice
>>> even with the current code, so I honestly don't think that should be a
>>> blocker for driver submission either, I can and will fix it later...)
>> Well this is what I thought about those problems in amdgpu as well and
>> it totally shipwrecked.
>>
>> We still have memory allocations in the VMID code path which I'm still
>> not sure how to remove.
> We don't even have a shrinker yet, and I'm sure that's going to be a lot
> of fun when we add it too... but yes, if we can't do any memory
> allocations in some of these callbacks (is this documented anywhere?),
> that's going to be interesting...
Yes, that is all part of the dma_fence documentation. It's just
absolutely not obvious what all this means.
> It's not all bad news though! All memory allocations are fallible in
> kernel Rust (and therefore explicit, and also failures have to be
> explicitly handled or propagated), so it's pretty easy to point out
> where they are, and there are already discussions of higher-level
> tooling to enforce rules like that (and things like wait contexts).
> Also, Rust makes it a lot easier to refactor code in general and not be
> scared that you're going to regress everything, so I'm not really
> worried if I need to turn a chunk of the driver on its head to solve
> some of these problems in the future ^^ (I already did that when I
> switched it from the "demo" synchronous submission model to the proper
> explicit sync + fences one.)
Yeah, well the problem isn't that you run into memory allocation failure.
The problem is rather something like this:
1. You try to allocate memory to signal your fence.
2. This memory allocation can't be fulfilled and goes to sleep to wait
for reclaim.
3. On another CPU reclaim is running and through the general purpose
shrinker, page fault or MMU notifier ends up wait for your dma_fence.
You don't even need to implement the shrinker for this to go boom
extremely easy.
So everything involved with signaling the fence can allocate memory only
with GFP_ATOMIC and only if you absolutely have to.
Christian.
>
> ~~ Lina
^ permalink raw reply [flat|nested] 122+ messages in thread
* Re: [PATCH RFC 10/18] drm/scheduler: Add can_run_job callback
2023-03-08 17:57 ` Christian König
@ 2023-03-08 19:05 ` Asahi Lina
2023-03-08 19:12 ` Christian König
0 siblings, 1 reply; 122+ messages in thread
From: Asahi Lina @ 2023-03-08 19:05 UTC (permalink / raw)
To: Christian König, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Daniel Vetter, Miguel Ojeda,
Alex Gaynor, Wedson Almeida Filho, Boqun Feng, Gary Guo,
Björn Roy Baron, Sumit Semwal, Luben Tuikov,
Jarkko Sakkinen, Dave Hansen
Cc: Alyssa Rosenzweig, Karol Herbst, Ella Stanforth, Faith Ekstrand,
Mary, linux-kernel, dri-devel, rust-for-linux, linux-media,
linaro-mm-sig, linux-sgx, asahi
On 09/03/2023 02.57, Christian König wrote:
> Am 08.03.23 um 17:44 schrieb Asahi Lina:
>> On 09/03/2023 00.30, Christian König wrote:
>>> Am 08.03.23 um 15:53 schrieb Asahi Lina:
>>>> [SNIP]
>>>>> The background is that core memory management requires that signaling a
>>>>> fence only depends on signaling other fences and hardware progress and
>>>>> nothing else. Otherwise you immediately run into problems because of
>>>>> circle dependencies or what we call infinite fences.
>>>> And hardware progress is exactly the only dependency here...
>>> Well then you should have a fence for that hardware progress.
>> I do, it's the prior job hardware completion fences that drm_sched
>> already knows about!
>>
>> Yes, I could return those in the prepare callback, it just means I need
>> to start stashing fence references in the underlying firmware job queue
>> command objects so I can find out what is the oldest pending fence is,
>> and return it when a queue is full. As long as drm_sched doesn't mind if
>> I keep giving it fences (since multiple commands can have to complete
>> before there is space) or the occasional already signaled fence (because
>> this process is inherently racy), it should work fine.
>
> Well this handling is intentional and necessary, but see below for a
> more in deep explanation.
>
>> If you think this is the better way, I'll do it that way and drop this
>> patch. It just seemed simpler to do it with another callback, since
>> drm_sched is already tracking those fences and doing a hardware queue
>> limit check anyway, and that way I can avoid tracking the fences down
>> into the hardware queue code... *
>
> Well it's not the better way, it's the only way that works.
>
> I have to admit that my bet on your intentions was wrong, but even that
> use case doesn't work correctly.
>
> See when your callback returns false it is perfectly possible that all
> hw fences are signaled between returning that information and processing it.
>
> The result would be that the scheduler goes to sleep and never wakes up
> again.
That can't happen, because it will just go into another iteration of the
drm_sched main loop since there is an entity available still.
Rather there is probably the opposite bug in this patch: the can_run_job
logic should be moved into the wait_event_interruptible() condition
check, otherwise I think it can end up busy-looping since the condition
itself can be true even when the can_run_job check blocks it.
But there is no risk of it going to sleep and never waking up because
job completions will wake up the waitqueue by definition, and that
happens after the driver-side queues are popped. If this problem could
happen, then the existing hw_submission_limit logic would be broken in
the same way. It is logically equivalent in how it works.
Basically, if properly done in wait_event_interruptible, it is exactly
the logic of that macro that prevents this race condition and makes
everything work at all. Without it, drm_sched would be completely broken.
> As I said we exercised those ideas before and yes this approach here
> came up before as well and no it doesn't work.
It can never deadlock with this patch as it stands (though it could busy
loop), and if properly moved into the wait_event_interruptible(), it
would also never busy loop and work entirely as intended. The actual API
change is sound.
I don't know why you're trying so hard to convince everyone that this
approach is fundamentally broken... It might be a bad idea for other
reasons, it might encourage incorrect usage, it might not be the best
option, there are plenty of arguments you can make... but you just keep
trying to make an argument that it just can't work at all for some
reason. Why? I already said I'm happy dropping it in favor of the fences...
It's intended to mirror the hw_submission_limit logic. If you think this
is broken, then that's broken too. They are equivalent mechanisms.
>> This particular issue aside, fairness in global resource allocation is a
>> conversation I'd love to have! Right now the driver doesn't try to
>> ensure that, a queue can easily monopolize certain hardware resources
>> (though one queue can only monopolize one of each, so you'd need
>> something like 63 queues with 63 distinct VMs all submitting
>> free-running jobs back to back in order to starve other queues of
>> resources forever). For starters, one thing I'm thinking of doing is
>> reserving certain subsets of hardware resources for queues with a given
>> priority, so you can at least guarantee forward progress of
>> higher-priority queues when faced with misbehaving lower-priority
>> queues. But if we want to guarantee proper fairness, I think I'll have
>> to start doing things like switching to a CPU-roundtrip submission model
>> when resources become scarce (to guarantee that queues actually release
>> the resources once in a while) and then figure out how to add fairness
>> to the allocation code...
>>
>> But let's have that conversation when we talk about the driver (or maybe
>> on IRC or something?), right now I'm more interested in getting the
>> abstractions reviewed ^^
>
> Well that stuff is highly problematic as well. The fairness aside you
> risk starvation which in turn breaks the guarantee of forward progress.
>
> In this particular case you can catch this with a timeout for the hw
> operation, but you should consider blocking that from the sw side as well.
In the current state I actually think it's not really that problematic,
because the resources are acquired directly in the ioctl path. So that
can block if starved, but if that can cause overall forward progress to
stop because some fence doesn't get signaled, then so can just not doing
the ioctl in the first place, so there's not much point (userspace can
always misbehave with its fence usage...). By the time anything gets
submitted to drm_sched, the resources are already guaranteed to be
acquired, we never block in the run callback.
It needs to be fixed of course, but if the threat model is a malicious
GPU process, well, there are many other ways to DoS your system... and I
don't think it's very likely that 63+ queues (which usually means 63+
processes with OpenGL) will end up accidentally starving the GPU in a
tight loop at the same time. I'd love to hear about real-world scenarios
where this kind of thing has been a real problem and not just a
theoretical one though... maybe I'm missing something?
Basically my priorities with the driver are:
1. Make sure it never crashes
2. Make sure it works well for real users
3. Make it work smoothly for real users under reasonable load
(priorities, CPU scheduler interactions, etc.)
4. Make it handle accidental problems more gracefully (OOMs etc, I need
to look into private GEM BO accounting to processes so the OOM killer
has better data to work with)
5. Make it more robust against deliberate abuse/starvation (this should
matter more once we have some kind of paravirtualization solution...)
And right now we're somewhere between 2 and 3. So if there are cases
where this resource acquisition stuff can cause a problem for real
users, I'll want to fix it earlier. But if this is more theoretical than
anything (with the resource limits of AGX GPUs), I'd rather focus on
things like memory accounting and shrinker support first.
>> We don't even have a shrinker yet, and I'm sure that's going to be a lot
>> of fun when we add it too... but yes, if we can't do any memory
>> allocations in some of these callbacks (is this documented anywhere?),
>> that's going to be interesting...
>
> Yes, that is all part of the dma_fence documentation. It's just
> absolutely not obvious what all this means.
I mean is there any documentation on how this interacts with drm_sched?
Like, am I not allowed to allocate memory in prepare()? What about
run()? What about GPU interrupt work? (not a raw IRQ handler context, I
mean the execution path from GPU IRQ to drm_sched run() fences getting
signaled)
>> It's not all bad news though! All memory allocations are fallible in
>> kernel Rust (and therefore explicit, and also failures have to be
>> explicitly handled or propagated), so it's pretty easy to point out
>> where they are, and there are already discussions of higher-level
>> tooling to enforce rules like that (and things like wait contexts).
>> Also, Rust makes it a lot easier to refactor code in general and not be
>> scared that you're going to regress everything, so I'm not really
>> worried if I need to turn a chunk of the driver on its head to solve
>> some of these problems in the future ^^ (I already did that when I
>> switched it from the "demo" synchronous submission model to the proper
>> explicit sync + fences one.)
>
> Yeah, well the problem isn't that you run into memory allocation failure.
What I mean is that the mandatory failure handling means it's relatively
easy to audit where memory allocations can actually happen.
> The problem is rather something like this:
> 1. You try to allocate memory to signal your fence.
> 2. This memory allocation can't be fulfilled and goes to sleep to wait
> for reclaim.
> 3. On another CPU reclaim is running and through the general purpose
> shrinker, page fault or MMU notifier ends up wait for your dma_fence.
>
> You don't even need to implement the shrinker for this to go boom
> extremely easy.
Hmm, can you actually get something waiting on a dma_fence like that
today with this driver? We don't have a shrinker, we don't have
synchronous page faults or MMU notifications for the GPU, and this is
explicit sync so all in/out fences cross over into userspace so surely
they can't be trusted anyway?
I'm definitely not familiar with the intricacies of DMA fences and how
they interact with everything else yet, but it's starting to sound like
either this isn't quite broken for our simple driver yet, or it must be
broken pretty much everywhere in some way...
> So everything involved with signaling the fence can allocate memory only
> with GFP_ATOMIC and only if you absolutely have to.
I don't think we even have a good story for passing around gfp_flags in
Rust code so that will be interesting... though I need to actually audit
the code paths and see how many allocations we really do. I know I alloc
some vectors for holding completed commands and stuff like that, but I'm
pretty sure I can fix that one with some reworking, and I'm not sure how
many other random things there really are...? Obviously most allocations
happen at command creation time, on completion you mostly get a lot of
freeing, so maybe I can just eliminate all allocs and not worry about
GFP_ATOMIC.
~~ Lina
^ permalink raw reply [flat|nested] 122+ messages in thread
* Re: [PATCH RFC 10/18] drm/scheduler: Add can_run_job callback
2023-03-08 19:05 ` Asahi Lina
@ 2023-03-08 19:12 ` Christian König
2023-03-08 19:45 ` Asahi Lina
0 siblings, 1 reply; 122+ messages in thread
From: Christian König @ 2023-03-08 19:12 UTC (permalink / raw)
To: Asahi Lina, Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
David Airlie, Daniel Vetter, Miguel Ojeda, Alex Gaynor,
Wedson Almeida Filho, Boqun Feng, Gary Guo, Björn Roy Baron,
Sumit Semwal, Luben Tuikov, Jarkko Sakkinen, Dave Hansen
Cc: Alyssa Rosenzweig, Karol Herbst, Ella Stanforth, Faith Ekstrand,
Mary, linux-kernel, dri-devel, rust-for-linux, linux-media,
linaro-mm-sig, linux-sgx, asahi
Am 08.03.23 um 20:05 schrieb Asahi Lina:
> [SNIP]
>> Well it's not the better way, it's the only way that works.
>>
>> I have to admit that my bet on your intentions was wrong, but even that
>> use case doesn't work correctly.
>>
>> See when your callback returns false it is perfectly possible that all
>> hw fences are signaled between returning that information and processing it.
>>
>> The result would be that the scheduler goes to sleep and never wakes up
>> again.
> That can't happen, because it will just go into another iteration of the
> drm_sched main loop since there is an entity available still.
>
> Rather there is probably the opposite bug in this patch: the can_run_job
> logic should be moved into the wait_event_interruptible() condition
> check, otherwise I think it can end up busy-looping since the condition
> itself can be true even when the can_run_job check blocks it.
>
> But there is no risk of it going to sleep and never waking up because
> job completions will wake up the waitqueue by definition, and that
> happens after the driver-side queues are popped. If this problem could
> happen, then the existing hw_submission_limit logic would be broken in
> the same way. It is logically equivalent in how it works.
>
> Basically, if properly done in wait_event_interruptible, it is exactly
> the logic of that macro that prevents this race condition and makes
> everything work at all. Without it, drm_sched would be completely broken.
>
>> As I said we exercised those ideas before and yes this approach here
>> came up before as well and no it doesn't work.
> It can never deadlock with this patch as it stands (though it could busy
> loop), and if properly moved into the wait_event_interruptible(), it
> would also never busy loop and work entirely as intended. The actual API
> change is sound.
>
> I don't know why you're trying so hard to convince everyone that this
> approach is fundamentally broken... It might be a bad idea for other
> reasons, it might encourage incorrect usage, it might not be the best
> option, there are plenty of arguments you can make... but you just keep
> trying to make an argument that it just can't work at all for some
> reason. Why? I already said I'm happy dropping it in favor of the fences...
Well because it is broken.
When you move the check into the wait_event_interruptible condition then
who is going to call wait_event_interruptible when the condition changes?
As I said this idea came up before and was rejected multiple times.
Regards,
Christian.
>
> It's intended to mirror the hw_submission_limit logic. If you think this
> is broken, then that's broken too. They are equivalent mechanisms.
>
>>> This particular issue aside, fairness in global resource allocation is a
>>> conversation I'd love to have! Right now the driver doesn't try to
>>> ensure that, a queue can easily monopolize certain hardware resources
>>> (though one queue can only monopolize one of each, so you'd need
>>> something like 63 queues with 63 distinct VMs all submitting
>>> free-running jobs back to back in order to starve other queues of
>>> resources forever). For starters, one thing I'm thinking of doing is
>>> reserving certain subsets of hardware resources for queues with a given
>>> priority, so you can at least guarantee forward progress of
>>> higher-priority queues when faced with misbehaving lower-priority
>>> queues. But if we want to guarantee proper fairness, I think I'll have
>>> to start doing things like switching to a CPU-roundtrip submission model
>>> when resources become scarce (to guarantee that queues actually release
>>> the resources once in a while) and then figure out how to add fairness
>>> to the allocation code...
>>>
>>> But let's have that conversation when we talk about the driver (or maybe
>>> on IRC or something?), right now I'm more interested in getting the
>>> abstractions reviewed ^^
>> Well that stuff is highly problematic as well. The fairness aside you
>> risk starvation which in turn breaks the guarantee of forward progress.
>>
>> In this particular case you can catch this with a timeout for the hw
>> operation, but you should consider blocking that from the sw side as well.
> In the current state I actually think it's not really that problematic,
> because the resources are acquired directly in the ioctl path. So that
> can block if starved, but if that can cause overall forward progress to
> stop because some fence doesn't get signaled, then so can just not doing
> the ioctl in the first place, so there's not much point (userspace can
> always misbehave with its fence usage...). By the time anything gets
> submitted to drm_sched, the resources are already guaranteed to be
> acquired, we never block in the run callback.
>
> It needs to be fixed of course, but if the threat model is a malicious
> GPU process, well, there are many other ways to DoS your system... and I
> don't think it's very likely that 63+ queues (which usually means 63+
> processes with OpenGL) will end up accidentally starving the GPU in a
> tight loop at the same time. I'd love to hear about real-world scenarios
> where this kind of thing has been a real problem and not just a
> theoretical one though... maybe I'm missing something?
>
> Basically my priorities with the driver are:
>
> 1. Make sure it never crashes
> 2. Make sure it works well for real users
> 3. Make it work smoothly for real users under reasonable load
> (priorities, CPU scheduler interactions, etc.)
> 4. Make it handle accidental problems more gracefully (OOMs etc, I need
> to look into private GEM BO accounting to processes so the OOM killer
> has better data to work with)
> 5. Make it more robust against deliberate abuse/starvation (this should
> matter more once we have some kind of paravirtualization solution...)
>
> And right now we're somewhere between 2 and 3. So if there are cases
> where this resource acquisition stuff can cause a problem for real
> users, I'll want to fix it earlier. But if this is more theoretical than
> anything (with the resource limits of AGX GPUs), I'd rather focus on
> things like memory accounting and shrinker support first.
>
>>> We don't even have a shrinker yet, and I'm sure that's going to be a lot
>>> of fun when we add it too... but yes, if we can't do any memory
>>> allocations in some of these callbacks (is this documented anywhere?),
>>> that's going to be interesting...
>> Yes, that is all part of the dma_fence documentation. It's just
>> absolutely not obvious what all this means.
> I mean is there any documentation on how this interacts with drm_sched?
> Like, am I not allowed to allocate memory in prepare()? What about
> run()? What about GPU interrupt work? (not a raw IRQ handler context, I
> mean the execution path from GPU IRQ to drm_sched run() fences getting
> signaled)
>
>>> It's not all bad news though! All memory allocations are fallible in
>>> kernel Rust (and therefore explicit, and also failures have to be
>>> explicitly handled or propagated), so it's pretty easy to point out
>>> where they are, and there are already discussions of higher-level
>>> tooling to enforce rules like that (and things like wait contexts).
>>> Also, Rust makes it a lot easier to refactor code in general and not be
>>> scared that you're going to regress everything, so I'm not really
>>> worried if I need to turn a chunk of the driver on its head to solve
>>> some of these problems in the future ^^ (I already did that when I
>>> switched it from the "demo" synchronous submission model to the proper
>>> explicit sync + fences one.)
>> Yeah, well the problem isn't that you run into memory allocation failure.
> What I mean is that the mandatory failure handling means it's relatively
> easy to audit where memory allocations can actually happen.
>
>> The problem is rather something like this:
>> 1. You try to allocate memory to signal your fence.
>> 2. This memory allocation can't be fulfilled and goes to sleep to wait
>> for reclaim.
>> 3. On another CPU reclaim is running and through the general purpose
>> shrinker, page fault or MMU notifier ends up wait for your dma_fence.
>>
>> You don't even need to implement the shrinker for this to go boom
>> extremely easy.
> Hmm, can you actually get something waiting on a dma_fence like that
> today with this driver? We don't have a shrinker, we don't have
> synchronous page faults or MMU notifications for the GPU, and this is
> explicit sync so all in/out fences cross over into userspace so surely
> they can't be trusted anyway?
>
> I'm definitely not familiar with the intricacies of DMA fences and how
> they interact with everything else yet, but it's starting to sound like
> either this isn't quite broken for our simple driver yet, or it must be
> broken pretty much everywhere in some way...
>
>> So everything involved with signaling the fence can allocate memory only
>> with GFP_ATOMIC and only if you absolutely have to.
> I don't think we even have a good story for passing around gfp_flags in
> Rust code so that will be interesting... though I need to actually audit
> the code paths and see how many allocations we really do. I know I alloc
> some vectors for holding completed commands and stuff like that, but I'm
> pretty sure I can fix that one with some reworking, and I'm not sure how
> many other random things there really are...? Obviously most allocations
> happen at command creation time, on completion you mostly get a lot of
> freeing, so maybe I can just eliminate all allocs and not worry about
> GFP_ATOMIC.
>
> ~~ Lina
^ permalink raw reply [flat|nested] 122+ messages in thread
* Re: [PATCH RFC 10/18] drm/scheduler: Add can_run_job callback
2023-03-08 19:12 ` Christian König
@ 2023-03-08 19:45 ` Asahi Lina
2023-03-08 20:14 ` Christian König
0 siblings, 1 reply; 122+ messages in thread
From: Asahi Lina @ 2023-03-08 19:45 UTC (permalink / raw)
To: Christian König, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Daniel Vetter, Miguel Ojeda,
Alex Gaynor, Wedson Almeida Filho, Boqun Feng, Gary Guo,
Björn Roy Baron, Sumit Semwal, Luben Tuikov,
Jarkko Sakkinen, Dave Hansen
Cc: Alyssa Rosenzweig, Karol Herbst, Ella Stanforth, Faith Ekstrand,
Mary, linux-kernel, dri-devel, rust-for-linux, linux-media,
linaro-mm-sig, linux-sgx, asahi
On 09/03/2023 04.12, Christian König wrote:
> Am 08.03.23 um 20:05 schrieb Asahi Lina:
>> [SNIP]
>>> Well it's not the better way, it's the only way that works.
>>>
>>> I have to admit that my bet on your intentions was wrong, but even that
>>> use case doesn't work correctly.
>>>
>>> See when your callback returns false it is perfectly possible that all
>>> hw fences are signaled between returning that information and processing it.
>>>
>>> The result would be that the scheduler goes to sleep and never wakes up
>>> again.
>> That can't happen, because it will just go into another iteration of the
>> drm_sched main loop since there is an entity available still.
>>
>> Rather there is probably the opposite bug in this patch: the can_run_job
>> logic should be moved into the wait_event_interruptible() condition
>> check, otherwise I think it can end up busy-looping since the condition
>> itself can be true even when the can_run_job check blocks it.
>>
>> But there is no risk of it going to sleep and never waking up because
>> job completions will wake up the waitqueue by definition, and that
>> happens after the driver-side queues are popped. If this problem could
>> happen, then the existing hw_submission_limit logic would be broken in
>> the same way. It is logically equivalent in how it works.
>>
>> Basically, if properly done in wait_event_interruptible, it is exactly
>> the logic of that macro that prevents this race condition and makes
>> everything work at all. Without it, drm_sched would be completely broken.
>>
>>> As I said we exercised those ideas before and yes this approach here
>>> came up before as well and no it doesn't work.
>> It can never deadlock with this patch as it stands (though it could busy
>> loop), and if properly moved into the wait_event_interruptible(), it
>> would also never busy loop and work entirely as intended. The actual API
>> change is sound.
>>
>> I don't know why you're trying so hard to convince everyone that this
>> approach is fundamentally broken... It might be a bad idea for other
>> reasons, it might encourage incorrect usage, it might not be the best
>> option, there are plenty of arguments you can make... but you just keep
>> trying to make an argument that it just can't work at all for some
>> reason. Why? I already said I'm happy dropping it in favor of the fences...
>
> Well because it is broken.
>
> When you move the check into the wait_event_interruptible condition then
> who is going to call wait_event_interruptible when the condition changes?
I think you mean wake_up_interruptible(). That would be
drm_sched_job_done(), on the fence callback when a job completes, which
as I keep saying is the same logic used for
hw_rq_count/hw_submission_limit tracking.
Please think about it for a second, it's really not that complicated to
see why it works:
- Driver pops off completed commands <-- can_run_job condition satisfied
- Driver signals fence
- drm_sched_job_done_cb()
- drm_sched_job_done()
- atomic_dec(&sched->hw_rq_count); <-- hw_submission_limit satisfied
- ...
- wake_up_interruptible(&sched->wake_up_worker);
^- happens after both conditions are potentially satisfied
It really is completely equivalent to just making the hw_rq_count logic
customizable by the driver. The actual flow is the same. As long as the
driver guarantees it satisfies the can_run_job() condition before
signaling the completion fence that triggered that change, it works fine.
> As I said this idea came up before and was rejected multiple times.
Maybe it was a different idea, or maybe it was rejected for other
reasons, or maybe it was wrongly rejected for being broken when it isn't ^^
~~ Lina
^ permalink raw reply [flat|nested] 122+ messages in thread* Re: [PATCH RFC 10/18] drm/scheduler: Add can_run_job callback
2023-03-08 19:45 ` Asahi Lina
@ 2023-03-08 20:14 ` Christian König
2023-03-09 6:30 ` Asahi Lina
0 siblings, 1 reply; 122+ messages in thread
From: Christian König @ 2023-03-08 20:14 UTC (permalink / raw)
To: Asahi Lina, Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
David Airlie, Daniel Vetter, Miguel Ojeda, Alex Gaynor,
Wedson Almeida Filho, Boqun Feng, Gary Guo, Björn Roy Baron,
Sumit Semwal, Luben Tuikov, Jarkko Sakkinen, Dave Hansen
Cc: Alyssa Rosenzweig, Karol Herbst, Ella Stanforth, Faith Ekstrand,
Mary, linux-kernel, dri-devel, rust-for-linux, linux-media,
linaro-mm-sig, linux-sgx, asahi
Am 08.03.23 um 20:45 schrieb Asahi Lina:
> On 09/03/2023 04.12, Christian König wrote:
>> Am 08.03.23 um 20:05 schrieb Asahi Lina:
>>> [SNIP]
>>>> Well it's not the better way, it's the only way that works.
>>>>
>>>> I have to admit that my bet on your intentions was wrong, but even that
>>>> use case doesn't work correctly.
>>>>
>>>> See when your callback returns false it is perfectly possible that all
>>>> hw fences are signaled between returning that information and processing it.
>>>>
>>>> The result would be that the scheduler goes to sleep and never wakes up
>>>> again.
>>> That can't happen, because it will just go into another iteration of the
>>> drm_sched main loop since there is an entity available still.
>>>
>>> Rather there is probably the opposite bug in this patch: the can_run_job
>>> logic should be moved into the wait_event_interruptible() condition
>>> check, otherwise I think it can end up busy-looping since the condition
>>> itself can be true even when the can_run_job check blocks it.
>>>
>>> But there is no risk of it going to sleep and never waking up because
>>> job completions will wake up the waitqueue by definition, and that
>>> happens after the driver-side queues are popped. If this problem could
>>> happen, then the existing hw_submission_limit logic would be broken in
>>> the same way. It is logically equivalent in how it works.
>>>
>>> Basically, if properly done in wait_event_interruptible, it is exactly
>>> the logic of that macro that prevents this race condition and makes
>>> everything work at all. Without it, drm_sched would be completely broken.
>>>
>>>> As I said we exercised those ideas before and yes this approach here
>>>> came up before as well and no it doesn't work.
>>> It can never deadlock with this patch as it stands (though it could busy
>>> loop), and if properly moved into the wait_event_interruptible(), it
>>> would also never busy loop and work entirely as intended. The actual API
>>> change is sound.
>>>
>>> I don't know why you're trying so hard to convince everyone that this
>>> approach is fundamentally broken... It might be a bad idea for other
>>> reasons, it might encourage incorrect usage, it might not be the best
>>> option, there are plenty of arguments you can make... but you just keep
>>> trying to make an argument that it just can't work at all for some
>>> reason. Why? I already said I'm happy dropping it in favor of the fences...
>> Well because it is broken.
>>
>> When you move the check into the wait_event_interruptible condition then
>> who is going to call wait_event_interruptible when the condition changes?
> I think you mean wake_up_interruptible(). That would be
> drm_sched_job_done(), on the fence callback when a job completes, which
> as I keep saying is the same logic used for
> hw_rq_count/hw_submission_limit tracking.
As the documentation to wait_event says:
* wake_up() has to be called after changing any variable that could
* change the result of the wait condition.
So what you essentially try to do here is to skip that and say
drm_sched_job_done() would call that anyway, but when you read any
variable to determine that state then as far as I can see nothing is
guarantying that order.
The only other possibility how you could use the callback correctly
would be to call drm_fence_is_signaled() to query the state of your hw
submission from the same fence which is then signaled. But then the
question is once more why you don't give that fence directly to the
scheduler?
> Please think about it for a second,
Yeah, I'm trying to really follow your intentions here. But that doesn't
really makes sense.
Either you are trying to do something invalid or you are trying to
circumvent the object model somehow and add a shortcut for the signaling
API. Both would be more than fishy.
Regards,
Christian.
> it's really not that complicated to
> see why it works:
>
> - Driver pops off completed commands <-- can_run_job condition satisfied
> - Driver signals fence
> - drm_sched_job_done_cb()
> - drm_sched_job_done()
> - atomic_dec(&sched->hw_rq_count); <-- hw_submission_limit satisfied
> - ...
> - wake_up_interruptible(&sched->wake_up_worker);
> ^- happens after both conditions are potentially satisfied
>
> It really is completely equivalent to just making the hw_rq_count logic
> customizable by the driver. The actual flow is the same. As long as the
> driver guarantees it satisfies the can_run_job() condition before
> signaling the completion fence that triggered that change, it works fine.
>
>> As I said this idea came up before and was rejected multiple times.
> Maybe it was a different idea, or maybe it was rejected for other
> reasons, or maybe it was wrongly rejected for being broken when it isn't ^^
>
> ~~ Lina
^ permalink raw reply [flat|nested] 122+ messages in thread
* Re: [PATCH RFC 10/18] drm/scheduler: Add can_run_job callback
2023-03-08 20:14 ` Christian König
@ 2023-03-09 6:30 ` Asahi Lina
2023-03-09 8:05 ` Christian König
0 siblings, 1 reply; 122+ messages in thread
From: Asahi Lina @ 2023-03-09 6:30 UTC (permalink / raw)
To: Christian König, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Daniel Vetter, Miguel Ojeda,
Alex Gaynor, Wedson Almeida Filho, Boqun Feng, Gary Guo,
Björn Roy Baron, Sumit Semwal, Luben Tuikov,
Jarkko Sakkinen, Dave Hansen
Cc: Alyssa Rosenzweig, Karol Herbst, Ella Stanforth, Faith Ekstrand,
Mary, linux-kernel, dri-devel, rust-for-linux, linux-media,
linaro-mm-sig, linux-sgx, asahi
On 09/03/2023 05.14, Christian König wrote:
>> I think you mean wake_up_interruptible(). That would be
>> drm_sched_job_done(), on the fence callback when a job completes, which
>> as I keep saying is the same logic used for
>> hw_rq_count/hw_submission_limit tracking.
>
> As the documentation to wait_event says:
>
> * wake_up() has to be called after changing any variable that could
> * change the result of the wait condition.
>
> So what you essentially try to do here is to skip that and say
> drm_sched_job_done() would call that anyway, but when you read any
> variable to determine that state then as far as I can see nothing is
> guarantying that order.
The driver needs to guarantee that any changes to that state precede a
job completion fence signal of course, that's the entire idea of the
API. It's supposed to represent a check for per-scheduler (or more
specific, but not more global) resources that are released on job
completion. Of course if you misuse the API you could cause a problem,
but what I'm trying to say is that the API as designed and when used as
intended does work properly.
Put another way: job completions always need to cause the sched main
loop to run an iteration anyway (otherwise we wouldn't make forward
progress), and job completions are exactly the signal that the
can_run_job() condition may have changed.
> The only other possibility how you could use the callback correctly
> would be to call drm_fence_is_signaled() to query the state of your hw
> submission from the same fence which is then signaled. But then the
> question is once more why you don't give that fence directly to the
> scheduler?
But the driver is supposed to guarantee that the ordering is always 1.
resources freed, 2. fence signaled. So you don't need to check for the
fence, you can just check for the resource state. If the callback
returns false then by definition the fence wasn't yet signaled at some
point during its execution (because the resources weren't yet freed),
and since it would be in the wait_event_interruptible() check path, by
definition the fence signaling at any point during or after the check
would cause the thread to wake up again and re-check.
Thread 1 Thread 2
1. wait_event_interruptible() arms wq 1. Free resources
2. can_run_job() checks resources 2. Signal fence
3. wait_event_interruptible() sleeps on wq 3. Fence wakes up wq
4. loop
There is no possible interleaving of those sequences that leads to a
lost event and the thread not waking up:
- If T2.3 happens before T1.1, that means T2.1 happened earlier and T1.2
must return true.
- If T2.3 happens after T1.1 but before T1.3, the wq code will ensure
the wq does not sleep (or immediately wakes up) at T1.3 since it was
signaled during the condition check, after the wq was armed. At the next
check loop, T1.2 will then return true, since T2.1 already happened
before T2.3.
- If T2.3 happens during T1.3, the wq wakes up normally and does another
check, and at that point T1.2 returns true.
QED.
~~ Lina
^ permalink raw reply [flat|nested] 122+ messages in thread
* Re: [PATCH RFC 10/18] drm/scheduler: Add can_run_job callback
2023-03-09 6:30 ` Asahi Lina
@ 2023-03-09 8:05 ` Christian König
2023-03-09 9:14 ` Asahi Lina
0 siblings, 1 reply; 122+ messages in thread
From: Christian König @ 2023-03-09 8:05 UTC (permalink / raw)
To: Asahi Lina, Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
David Airlie, Daniel Vetter, Miguel Ojeda, Alex Gaynor,
Wedson Almeida Filho, Boqun Feng, Gary Guo, Björn Roy Baron,
Sumit Semwal, Luben Tuikov, Jarkko Sakkinen, Dave Hansen
Cc: Alyssa Rosenzweig, Karol Herbst, Ella Stanforth, Faith Ekstrand,
Mary, linux-kernel, dri-devel, rust-for-linux, linux-media,
linaro-mm-sig, linux-sgx, asahi
Am 09.03.23 um 07:30 schrieb Asahi Lina:
> On 09/03/2023 05.14, Christian König wrote:
>>> I think you mean wake_up_interruptible(). That would be
>>> drm_sched_job_done(), on the fence callback when a job completes, which
>>> as I keep saying is the same logic used for
>>> hw_rq_count/hw_submission_limit tracking.
>> As the documentation to wait_event says:
>>
>> * wake_up() has to be called after changing any variable that could
>> * change the result of the wait condition.
>>
>> So what you essentially try to do here is to skip that and say
>> drm_sched_job_done() would call that anyway, but when you read any
>> variable to determine that state then as far as I can see nothing is
>> guarantying that order.
> The driver needs to guarantee that any changes to that state precede a
> job completion fence signal of course, that's the entire idea of the
> API. It's supposed to represent a check for per-scheduler (or more
> specific, but not more global) resources that are released on job
> completion. Of course if you misuse the API you could cause a problem,
> but what I'm trying to say is that the API as designed and when used as
> intended does work properly.
>
> Put another way: job completions always need to cause the sched main
> loop to run an iteration anyway (otherwise we wouldn't make forward
> progress), and job completions are exactly the signal that the
> can_run_job() condition may have changed.
>
>> The only other possibility how you could use the callback correctly
>> would be to call drm_fence_is_signaled() to query the state of your hw
>> submission from the same fence which is then signaled. But then the
>> question is once more why you don't give that fence directly to the
>> scheduler?
> But the driver is supposed to guarantee that the ordering is always 1.
> resources freed, 2. fence signaled. So you don't need to check for the
> fence, you can just check for the resource state.
Yeah, but this is exactly what the dma_fence framework tried to prevent.
We try very hard to avoid such side channel signaling :)
But putting that issue aside for a moment. What I don't get is when you
have such intra queue dependencies, then why can't you check that at a
much higher level?
In other words even userspace should be able to predict that for it's
submissions X amount of resources are needed and when all of my
submissions run in parallel that won't work.
Asking the firmware for a status is usually a magnitudes slower than
just computing it before submission.
Regards,
Christian.
> If the callback
> returns false then by definition the fence wasn't yet signaled at some
> point during its execution (because the resources weren't yet freed),
> and since it would be in the wait_event_interruptible() check path, by
> definition the fence signaling at any point during or after the check
> would cause the thread to wake up again and re-check.
>
> Thread 1 Thread 2
> 1. wait_event_interruptible() arms wq 1. Free resources
> 2. can_run_job() checks resources 2. Signal fence
> 3. wait_event_interruptible() sleeps on wq 3. Fence wakes up wq
> 4. loop
>
> There is no possible interleaving of those sequences that leads to a
> lost event and the thread not waking up:
> - If T2.3 happens before T1.1, that means T2.1 happened earlier and T1.2
> must return true.
> - If T2.3 happens after T1.1 but before T1.3, the wq code will ensure
> the wq does not sleep (or immediately wakes up) at T1.3 since it was
> signaled during the condition check, after the wq was armed. At the next
> check loop, T1.2 will then return true, since T2.1 already happened
> before T2.3.
> - If T2.3 happens during T1.3, the wq wakes up normally and does another
> check, and at that point T1.2 returns true.
>
> QED.
>
> ~~ Lina
^ permalink raw reply [flat|nested] 122+ messages in thread
* Re: [PATCH RFC 10/18] drm/scheduler: Add can_run_job callback
2023-03-09 8:05 ` Christian König
@ 2023-03-09 9:14 ` Asahi Lina
2023-03-09 18:50 ` Faith Ekstrand
0 siblings, 1 reply; 122+ messages in thread
From: Asahi Lina @ 2023-03-09 9:14 UTC (permalink / raw)
To: Christian König, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Daniel Vetter, Miguel Ojeda,
Alex Gaynor, Wedson Almeida Filho, Boqun Feng, Gary Guo,
Björn Roy Baron, Sumit Semwal, Luben Tuikov,
Jarkko Sakkinen, Dave Hansen
Cc: Alyssa Rosenzweig, Karol Herbst, Ella Stanforth, Faith Ekstrand,
Mary, linux-kernel, dri-devel, rust-for-linux, linux-media,
linaro-mm-sig, linux-sgx, asahi
On 09/03/2023 17.05, Christian König wrote:
> Am 09.03.23 um 07:30 schrieb Asahi Lina:
>> On 09/03/2023 05.14, Christian König wrote:
>>>> I think you mean wake_up_interruptible(). That would be
>>>> drm_sched_job_done(), on the fence callback when a job completes, which
>>>> as I keep saying is the same logic used for
>>>> hw_rq_count/hw_submission_limit tracking.
>>> As the documentation to wait_event says:
>>>
>>> * wake_up() has to be called after changing any variable that could
>>> * change the result of the wait condition.
>>>
>>> So what you essentially try to do here is to skip that and say
>>> drm_sched_job_done() would call that anyway, but when you read any
>>> variable to determine that state then as far as I can see nothing is
>>> guarantying that order.
>> The driver needs to guarantee that any changes to that state precede a
>> job completion fence signal of course, that's the entire idea of the
>> API. It's supposed to represent a check for per-scheduler (or more
>> specific, but not more global) resources that are released on job
>> completion. Of course if you misuse the API you could cause a problem,
>> but what I'm trying to say is that the API as designed and when used as
>> intended does work properly.
>>
>> Put another way: job completions always need to cause the sched main
>> loop to run an iteration anyway (otherwise we wouldn't make forward
>> progress), and job completions are exactly the signal that the
>> can_run_job() condition may have changed.
>>
>>> The only other possibility how you could use the callback correctly
>>> would be to call drm_fence_is_signaled() to query the state of your hw
>>> submission from the same fence which is then signaled. But then the
>>> question is once more why you don't give that fence directly to the
>>> scheduler?
>> But the driver is supposed to guarantee that the ordering is always 1.
>> resources freed, 2. fence signaled. So you don't need to check for the
>> fence, you can just check for the resource state.
>
> Yeah, but this is exactly what the dma_fence framework tried to prevent.
> We try very hard to avoid such side channel signaling :)
Right, and it's fine, I can use the fences directly easily enough. I'm
just trying to explain why my original idea works too, even if it's not
the best solution for other reasons!
Of course I don't have the context of what other drivers are doing or
did historically and what the pitfalls are, so I can't know what the
"right" solution for any of this is in that context. I did my best to
understand the drm_sched code and come up with a solution that works
(which it does) without any more info. When I saw the hw submission
limit stuff, I thought "okay, I need the same thing but with slightly
more complex logic, so let's add a callback so the driver can customize
it and do its own inflight counting".
After this discussion, I can see that this is equivalent to doing the
same check in prepare_job() followed by returning the oldest running
job's fence (as long as there's no race there... it should be fine if
the fence reference is taken first, before the resource check, or if
everything is done within the same critical section taking the firmware
queue lock), so I'm happy to switch to that and drop this patch.
But keep in mind none of this is documented, and there's no way for us
driver authors to understand what we're supposed to do without
documentation. As I said I spent a long time trying to understand
drm_sched, and then my original attempt missed the drm_sched_fini()
issue with dangling jobs and Alyssa managed to hit an oops on the test
branch, I guessed what the problem was from her trace, figured out a way
to reproduce it (the kill-loop glmark2 thing), and fixed it in the next
patch in this series. So even trying my best to figure out how to do
this, reading the code and what scarce docs there are, I managed to miss
something that caused a potential oops on the first try. If I can't even
get the API usage right after spending hours on it trying really hard
not to (because it's not just about my driver, I need the Rust
abstraction to be safe for any driver), there's no way I'm going to
divine what approaches to resource/dependency signaling are
problematic/easy to abuse... the most I can hope for is "I got the
wrapper right and the API/driver interaction is correct and guarantees
forward progress if the driver follows the rules".
So when I submit something, and you reply with "Well complete NAK",
that's just not nice. Honestly, I was kind of upset when I got that
email. It sounded as if you were saying my solution was completely
broken and couldn't work, but no matter how I looked at it I couldn't
figure out how it's broken. And then it took several emails to even
understand what you were suggesting with the prepare_job callback (and
yes, that works too and is probably harder to abuse than a new
callback). I'm trying really hard to make this all work and be correct,
and of course I make mistakes too... but then I look at the code and no
matter what I can come up with it seems to work and be correct, what am
I supposed to do? I'm happy to learn and figure out better approaches
for everything that lead to better drivers, but I need an actual
explanation of the issues, not just a NAK...
I also would appreciate it if people give me the benefit of the doubt
and let me explain what I'm doing and how I'm doing it and how this
hardware works, because the whole thing is subtle to the core and very
different to other GPUs. Honestly, I don't think any reviewer that
hasn't spent hours poring over the driver/abstraction code could
confidently say that a certain subtle sync issue exists at a first pass
(other than for really obvious bad code sequences). I'm happy to look
into issues and I definitely want to know what cases to look at and what
to check for and fix anything we find... but isn't it better if we work
together instead of shouting "this is broken" at the first hint of
possible trouble?
> But putting that issue aside for a moment. What I don't get is when you
> have such intra queue dependencies, then why can't you check that at a
> much higher level?
>
> In other words even userspace should be able to predict that for it's
> submissions X amount of resources are needed and when all of my
> submissions run in parallel that won't work.
Technically yes, but we can't trust userspace to honor this, since
overflowing the firmware queue breaks everything, so the kernel has to
do the check... plus we're trying to insulate userspace from the details
of how work is queued at the firmware. We need to support multiple
firmware versions including future ones we can't predict yet without
breaking UAPI, so the less the UAPI depends on firmware details, the
better. That's why at the UAPI level, this is boiled down to a simpler
"max commands per submission" limit that gets passed in the params
struct, which is conservative, and then the kernel can deal with the
actual in-flight count tracking and only submit things to the hardware
when they fit.
In the future we could even support job splitting on the kernel side and
remove the max commands per submission limit altogether (though it
probably still makes sense to have for other reasons, like bounding how
much kernel/firmware memory a single queue can consume, so I'm not sure
this is even worth doing at all).
> Asking the firmware for a status is usually a magnitudes slower than
> just computing it before submission.
I'm not asking the firmware for status, I'm just asking my own firmware
queue code how many slots are currently free in each backing queue.
That's just based on internal driver state, there is no firmware round trip!
I could technically compute this before submission and figure out how
much work has been queued and pre-populate fences that ensure we never
exceed the max, but honestly that's a lot more code to track job sizes
and I don't think it makes sense when I can just ask "Do we have space?
No? Okay, return the oldest running job fence for now and try again when
it completes" in prepare_job(). Maybe it's faster in pathological cases
to do something fancier, but let's wait until Vulkan works and we can
run real AAA games and see where the bottlenecks are before going down
the optimization road ^^
~~ Lina
^ permalink raw reply [flat|nested] 122+ messages in thread
* Re: [PATCH RFC 10/18] drm/scheduler: Add can_run_job callback
2023-03-09 9:14 ` Asahi Lina
@ 2023-03-09 18:50 ` Faith Ekstrand
2023-03-10 9:16 ` Asahi Lina
0 siblings, 1 reply; 122+ messages in thread
From: Faith Ekstrand @ 2023-03-09 18:50 UTC (permalink / raw)
To: Asahi Lina, Christian König, Maarten Lankhorst,
Maxime Ripard, Thomas Zimmermann, David Airlie, Daniel Vetter,
Miguel Ojeda, Alex Gaynor, Wedson Almeida Filho, Boqun Feng,
Gary Guo, Björn Roy Baron, Sumit Semwal, Luben Tuikov,
Jarkko Sakkinen, Dave Hansen
Cc: Alyssa Rosenzweig, Karol Herbst, Ella Stanforth, Mary,
linux-kernel, dri-devel, rust-for-linux, linux-media,
linaro-mm-sig, linux-sgx, asahi
Jumping in here quick... (Sorry, I was out yesterday and was ignoring
my e-mail on Tuesday so I could finally type some compiler code.)
On Thu, 2023-03-09 at 18:14 +0900, Asahi Lina wrote:
> On 09/03/2023 17.05, Christian König wrote:
> > Am 09.03.23 um 07:30 schrieb Asahi Lina:
> > > On 09/03/2023 05.14, Christian König wrote:
> > > > > I think you mean wake_up_interruptible(). That would be
> > > > > drm_sched_job_done(), on the fence callback when a job
> > > > > completes, which
> > > > > as I keep saying is the same logic used for
> > > > > hw_rq_count/hw_submission_limit tracking.
> > > > As the documentation to wait_event says:
> > > >
> > > > * wake_up() has to be called after changing any variable
> > > > that could
> > > > * change the result of the wait condition.
> > > >
> > > > So what you essentially try to do here is to skip that and say
> > > > drm_sched_job_done() would call that anyway, but when you read
> > > > any
> > > > variable to determine that state then as far as I can see
> > > > nothing is
> > > > guarantying that order.
> > > The driver needs to guarantee that any changes to that state
> > > precede a
> > > job completion fence signal of course, that's the entire idea of
> > > the
> > > API. It's supposed to represent a check for per-scheduler (or
> > > more
> > > specific, but not more global) resources that are released on job
> > > completion. Of course if you misuse the API you could cause a
> > > problem,
> > > but what I'm trying to say is that the API as designed and when
> > > used as
> > > intended does work properly.
> > >
> > > Put another way: job completions always need to cause the sched
> > > main
> > > loop to run an iteration anyway (otherwise we wouldn't make
> > > forward
> > > progress), and job completions are exactly the signal that the
> > > can_run_job() condition may have changed.
> > >
> > > > The only other possibility how you could use the callback
> > > > correctly
> > > > would be to call drm_fence_is_signaled() to query the state of
> > > > your hw
> > > > submission from the same fence which is then signaled. But then
> > > > the
> > > > question is once more why you don't give that fence directly to
> > > > the
> > > > scheduler?
> > > But the driver is supposed to guarantee that the ordering is
> > > always 1.
> > > resources freed, 2. fence signaled. So you don't need to check
> > > for the
> > > fence, you can just check for the resource state.
> >
> > Yeah, but this is exactly what the dma_fence framework tried to
> > prevent.
> > We try very hard to avoid such side channel signaling :)
>
> Right, and it's fine, I can use the fences directly easily enough.
> I'm
> just trying to explain why my original idea works too, even if it's
> not
> the best solution for other reasons!
>
> Of course I don't have the context of what other drivers are doing or
> did historically and what the pitfalls are, so I can't know what the
> "right" solution for any of this is in that context. I did my best to
> understand the drm_sched code and come up with a solution that works
> (which it does) without any more info. When I saw the hw submission
> limit stuff, I thought "okay, I need the same thing but with slightly
> more complex logic, so let's add a callback so the driver can
> customize
> it and do its own inflight counting".
So, I think there's a difference here between "impossible to implement
correctly", "likely to be implemented correctly", and "impossible to
implement incorrectly". It's obviously possible to implement
correctly. You can just always return true or do exactly the same
check or do some simple thing where you can guarantee that it will only
ever return false when there's a bunch of other stuff in the queue.
That doesn't mean that it's likely to be implemented correctly by some
other driver. Some idiot will come along and try to take advantage of
it and cause themselves horrible problems.
And, to be clear, for the purposes of this discussion, we're ALL
idiots, myself included. If there's one thing the DRM community has
learned over the years, it's that drivers are so complex that we all
turn into idiots at some point, relative to the complexity of the code
and hardware behavior. That's why things like dma_fence are written so
incredibly defensively and why we're so harsh about the rules. It's
the rules and not our individual smarts that keep us from making
mistakes. (Kinda like Rust, in a way.) So while I appreciate the
frustration of "I'm just trying to do something that's clearly correct
here", that doesn't mean that then next person to come by and fix a bug
by tweaking that callback isn't going to screw it up irreparably. That
person may even be you in 6 to 12 months after this e-mail thread is a
distant memory.
So, yes, does the implementation you have today work without deadlocks
or starvation? Maybe it does. I've not verified. Is the suggested
callback a giant foot-gun in the already treacherous territory of
scheduling and fencing? Yeah, it probably is and there's another way
to implement the same behavior which is likely safer in the long run.
> After this discussion, I can see that this is equivalent to doing the
> same check in prepare_job() followed by returning the oldest running
> job's fence (as long as there's no race there... it should be fine if
> the fence reference is taken first, before the resource check, or if
> everything is done within the same critical section taking the
> firmware
> queue lock), so I'm happy to switch to that and drop this patch.
>
> But keep in mind none of this is documented, and there's no way for
> us
> driver authors to understand what we're supposed to do without
> documentation. As I said I spent a long time trying to understand
> drm_sched, and then my original attempt missed the drm_sched_fini()
> issue with dangling jobs and Alyssa managed to hit an oops on the
> test
> branch, I guessed what the problem was from her trace, figured out a
> way
> to reproduce it (the kill-loop glmark2 thing), and fixed it in the
> next
> patch in this series. So even trying my best to figure out how to do
> this, reading the code and what scarce docs there are, I managed to
> miss
> something that caused a potential oops on the first try. If I can't
> even
> get the API usage right after spending hours on it trying really hard
> not to (because it's not just about my driver, I need the Rust
> abstraction to be safe for any driver), there's no way I'm going to
> divine what approaches to resource/dependency signaling are
> problematic/easy to abuse... the most I can hope for is "I got the
> wrapper right and the API/driver interaction is correct and
> guarantees
> forward progress if the driver follows the rules".
Your frustration with the lack of good documentation in DRM is entirely
justified. It's a mess and there's not a whole lot of people who
understand all these subtleties. Connecting to the hive mind via e-
mail and asking questions is the best you can do a lot of the time, I'm
afraid. I wish we had better documentation for a lot of things and I'd
be happy to see the situation improved added but we've got a lot of
debt there and not always a lot of time. (Yeah, I know, that's every
senior engineer's excuse...) We really are trying to be better about
it moving forward, though. Daniel has been pushing people to document
things a lot more in recent years. But, yeah, lots of debt...
Also, in a weird way, I think these conversations are sometimes better
than documentation. It took a while to get around to it all but
there's a lot of context that was brought together in this e-mail
thread that wouldn't have been in the docs no matter how good they are.
A lot of it isn't an isolated thing that should clearly be explained in
the run_job docs. It's subtle interactions which happen when all the
pieces come together. I see this complaint a lot about Vulkan as well.
There are behaviors which only become evident when you find the right 5
pieces of the spec and put them all together and squint. It'd be good
to call those out sometimes but there's no way we can document all of
them.
> So when I submit something, and you reply with "Well complete NAK",
> that's just not nice. Honestly, I was kind of upset when I got that
> email. It sounded as if you were saying my solution was completely
> broken and couldn't work, but no matter how I looked at it I couldn't
> figure out how it's broken. And then it took several emails to even
> understand what you were suggesting with the prepare_job callback
> (and
> yes, that works too and is probably harder to abuse than a new
> callback). I'm trying really hard to make this all work and be
> correct,
> and of course I make mistakes too... but then I look at the code and
> no
> matter what I can come up with it seems to work and be correct, what
> am
> I supposed to do? I'm happy to learn and figure out better approaches
> for everything that lead to better drivers, but I need an actual
> explanation of the issues, not just a NAK...
>
> I also would appreciate it if people give me the benefit of the doubt
> and let me explain what I'm doing and how I'm doing it and how this
> hardware works, because the whole thing is subtle to the core and
> very
> different to other GPUs. Honestly, I don't think any reviewer that
> hasn't spent hours poring over the driver/abstraction code could
> confidently say that a certain subtle sync issue exists at a first
> pass
> (other than for really obvious bad code sequences). I'm happy to look
> into issues and I definitely want to know what cases to look at and
> what
> to check for and fix anything we find... but isn't it better if we
> work
> together instead of shouting "this is broken" at the first hint of
> possible trouble?
Debating if I want to wade in in this one because this thread is
already getting a bit warm and I don't want to make it worse. But, I'm
an idiot, so...
Knowing what I do of both people in this thread, I think Christian is
giving you more benefit of the doubt than you realize. Yes, his tone
may be a bit abrupt but he continued to spend his time responding in
detail to every question you raised. That means he was taking you
seriously, even if he wasn't yielding ground.
Communication is hard, especially with all the different personalities,
languages, and cultures involved in an international community like
this. Sometimes the clarity of saying "no, this isn't going to work"
up-front is necessary. Sometimes the person on the other end of the e-
mail could benefit from a gentler response. It's hard to know from
early interactions. Enough people have been wrong about dma_fence over
the years (Hi! It's me!) that "no" is often the right starting
position. 😭️ It doesn't always feel great to be on the receiving end
of that but Christian is pretty much guarding a dragon cave, so...
To be clear, none of that is a defense of the toxicity for which the
Linux community has gotten a reputation. A lot of subsystem
maintainers have been known to start of with "no" to any idea they
didn't already think of. That's bad. Generally, you shouldn't assume
everyone but you is an idiot. When it comes to dma_fence, though, the
assumption is that we're ALL idiots and the "No, seriously, don't go
into the dragon cave. You won't come out alive. You're not that
special." signs are justified. 😓️
I hope the context I'm providing here is helpful. If not, feel free to
ignore me. It looks like you got the technical issues sorted.
~Faith
>
^ permalink raw reply [flat|nested] 122+ messages in thread
* Re: [PATCH RFC 10/18] drm/scheduler: Add can_run_job callback
2023-03-09 18:50 ` Faith Ekstrand
@ 2023-03-10 9:16 ` Asahi Lina
0 siblings, 0 replies; 122+ messages in thread
From: Asahi Lina @ 2023-03-10 9:16 UTC (permalink / raw)
To: Faith Ekstrand, Christian König, Maarten Lankhorst,
Maxime Ripard, Thomas Zimmermann, David Airlie, Daniel Vetter,
Miguel Ojeda, Alex Gaynor, Wedson Almeida Filho, Boqun Feng,
Gary Guo, Björn Roy Baron, Sumit Semwal, Luben Tuikov,
Jarkko Sakkinen, Dave Hansen
Cc: Alyssa Rosenzweig, Karol Herbst, Ella Stanforth, Mary,
linux-kernel, dri-devel, rust-for-linux, linux-media,
linaro-mm-sig, linux-sgx, asahi
On 10/03/2023 03.50, Faith Ekstrand wrote:
> Jumping in here quick... (Sorry, I was out yesterday and was ignoring
> my e-mail on Tuesday so I could finally type some compiler code.)
>
> On Thu, 2023-03-09 at 18:14 +0900, Asahi Lina wrote:
>> On 09/03/2023 17.05, Christian König wrote:
>>> Am 09.03.23 um 07:30 schrieb Asahi Lina:
>>>> On 09/03/2023 05.14, Christian König wrote:
>>>>>> I think you mean wake_up_interruptible(). That would be
>>>>>> drm_sched_job_done(), on the fence callback when a job
>>>>>> completes, which
>>>>>> as I keep saying is the same logic used for
>>>>>> hw_rq_count/hw_submission_limit tracking.
>>>>> As the documentation to wait_event says:
>>>>>
>>>>> * wake_up() has to be called after changing any variable
>>>>> that could
>>>>> * change the result of the wait condition.
>>>>>
>>>>> So what you essentially try to do here is to skip that and say
>>>>> drm_sched_job_done() would call that anyway, but when you read
>>>>> any
>>>>> variable to determine that state then as far as I can see
>>>>> nothing is
>>>>> guarantying that order.
>>>> The driver needs to guarantee that any changes to that state
>>>> precede a
>>>> job completion fence signal of course, that's the entire idea of
>>>> the
>>>> API. It's supposed to represent a check for per-scheduler (or
>>>> more
>>>> specific, but not more global) resources that are released on job
>>>> completion. Of course if you misuse the API you could cause a
>>>> problem,
>>>> but what I'm trying to say is that the API as designed and when
>>>> used as
>>>> intended does work properly.
>>>>
>>>> Put another way: job completions always need to cause the sched
>>>> main
>>>> loop to run an iteration anyway (otherwise we wouldn't make
>>>> forward
>>>> progress), and job completions are exactly the signal that the
>>>> can_run_job() condition may have changed.
>>>>
>>>>> The only other possibility how you could use the callback
>>>>> correctly
>>>>> would be to call drm_fence_is_signaled() to query the state of
>>>>> your hw
>>>>> submission from the same fence which is then signaled. But then
>>>>> the
>>>>> question is once more why you don't give that fence directly to
>>>>> the
>>>>> scheduler?
>>>> But the driver is supposed to guarantee that the ordering is
>>>> always 1.
>>>> resources freed, 2. fence signaled. So you don't need to check
>>>> for the
>>>> fence, you can just check for the resource state.
>>>
>>> Yeah, but this is exactly what the dma_fence framework tried to
>>> prevent.
>>> We try very hard to avoid such side channel signaling :)
>>
>> Right, and it's fine, I can use the fences directly easily enough.
>> I'm
>> just trying to explain why my original idea works too, even if it's
>> not
>> the best solution for other reasons!
>>
>> Of course I don't have the context of what other drivers are doing or
>> did historically and what the pitfalls are, so I can't know what the
>> "right" solution for any of this is in that context. I did my best to
>> understand the drm_sched code and come up with a solution that works
>> (which it does) without any more info. When I saw the hw submission
>> limit stuff, I thought "okay, I need the same thing but with slightly
>> more complex logic, so let's add a callback so the driver can
>> customize
>> it and do its own inflight counting".
>
> So, I think there's a difference here between "impossible to implement
> correctly", "likely to be implemented correctly", and "impossible to
> implement incorrectly". It's obviously possible to implement
> correctly. You can just always return true or do exactly the same
> check or do some simple thing where you can guarantee that it will only
> ever return false when there's a bunch of other stuff in the queue.
> That doesn't mean that it's likely to be implemented correctly by some
> other driver. Some idiot will come along and try to take advantage of
> it and cause themselves horrible problems.
>
> And, to be clear, for the purposes of this discussion, we're ALL
> idiots, myself included. If there's one thing the DRM community has
> learned over the years, it's that drivers are so complex that we all
> turn into idiots at some point, relative to the complexity of the code
> and hardware behavior. That's why things like dma_fence are written so
> incredibly defensively and why we're so harsh about the rules. It's
> the rules and not our individual smarts that keep us from making
> mistakes. (Kinda like Rust, in a way.) So while I appreciate the
> frustration of "I'm just trying to do something that's clearly correct
> here", that doesn't mean that then next person to come by and fix a bug
> by tweaking that callback isn't going to screw it up irreparably. That
> person may even be you in 6 to 12 months after this e-mail thread is a
> distant memory.
>
> So, yes, does the implementation you have today work without deadlocks
> or starvation? Maybe it does. I've not verified. Is the suggested
> callback a giant foot-gun in the already treacherous territory of
> scheduling and fencing? Yeah, it probably is and there's another way
> to implement the same behavior which is likely safer in the long run.
I understand that... I just wish the response had been along the lines
of "this is a huge footgun for these reasons, and you don't need it
because you can do it this other way instead", not "the concept is
completely broken, NAK".
If the discussion were phrased around how the API can be used and
abused, then I can understand what the concern is. But it was somehow
always about me and what I'm doing...
> This is clearly going against the idea of having jobs only depend on
> fences and nothing else which is mandatory for correct memory management.
That implies what I'm doing breaks memory management (and that it is
obvious).
> And to make it clear this is unfortunately a complete NAK to this
> approach! You can't do this!
Again that I can't do it... and then we got an argument over whether the
code is actually broken or not. But that doesn't even matter, since the
issue is how easy the API is to use or misuse, not whether I actually
misuse it...
I'll switch to prepare_job() fences for the next version, so it's not an
issue. Using that didn't even cross my mind because, knowing nothing
about the intended usage here, the prepare_job() callback docs are quite
obtuse:
> Called when the scheduler is considering scheduling this job next> to get another struct dma_fence for this job to block on. Once i>
returns NULL, run_job() may be called.
>
> Can be NULL if no additional preparation to the dependencies are necessary.> Skipped when jobs are killed instead of run.
What's a "dependency"? To me that sounded like execution dependencies,
and we clearly express those in the jobs themselves ahead of time. But
it turns out the purpose of this callback is to grab resources just in
time before execution or block on them becoming available through a
fence, and then it makes a lot more sense how to use it to do in-flight
command count limiting.
Aside: now that I understand this, I'm tempted to make the Rust
signature for this return a Result<(), Fence>. Returning a fence is
essentially the "error" case here, and that means in the implementation
you can just do:
if job.foo_res.is_none() {
job.foo_res = Some(foo.get_resource()?);
}
if job.bar_res.is_none() {
job.bar_res = Some(bar.get_resource()?);
}
As long as all the get_resource() calls return a Result<Resource, Fence>.
There's even more undocumented subtlety here though, since as far as I
can tell if all the resources aren't always grabbed in the same order,
or more than one of a single resource is grabbed separately you could
deadlock or even livelock?
This is theoretical since right now I don't handle this properly at all
other than the command count limit (I need the command struct fixup
system for this to be reasonably possible), but for example, I'll need
1-3 event IDs per job, and if I grab them one by one, you could end up
deadlocking with all event IDs used by jobs waiting for more. And if I
don't store them eagerly (so drop the IDs if you can't get all of them),
then you can end up with livelocks where every scheduler is grabbing an
ID, then dropping it when we can't get another one, which signals a
fence for another blocked scheduler to grab another ID, which then drops
it because it can't get more, etc. So I probably need to grab a number
of event IDs atomically.
> Also, in a weird way, I think these conversations are sometimes better
> than documentation. It took a while to get around to it all but
> there's a lot of context that was brought together in this e-mail
> thread that wouldn't have been in the docs no matter how good they are.
> A lot of it isn't an isolated thing that should clearly be explained in
> the run_job docs. It's subtle interactions which happen when all the
> pieces come together. I see this complaint a lot about Vulkan as well.
> There are behaviors which only become evident when you find the right 5
> pieces of the spec and put them all together and squint. It'd be good
> to call those out sometimes but there's no way we can document all of
> them.
That's true, but I think we could improve things a lot even with just
better docs and more hyperlinking between docs... For example, the GEM
and DMA fence docs do have quite a bit of prose that gets you some
context (even if it's a bit outdated and not complete). But drm_sched
just has one paragraph and a list giving a high-level design, and then
goes straight into function docs. It definitely takes putting together
the sched, fence, dma_resv, etc. docs together to get the big picture,
but if those docs all at least point at each other and are individually
reasonably complete, then we'd have a chance ^^
~~ Lina
^ permalink raw reply [flat|nested] 122+ messages in thread
* Re: [PATCH RFC 10/18] drm/scheduler: Add can_run_job callback
2023-03-08 8:46 ` Christian König
2023-03-08 9:41 ` Asahi Lina
@ 2023-03-08 12:39 ` Karol Herbst
2023-03-08 13:47 ` Christian König
1 sibling, 1 reply; 122+ messages in thread
From: Karol Herbst @ 2023-03-08 12:39 UTC (permalink / raw)
To: Christian König
Cc: Asahi Lina, Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
David Airlie, Daniel Vetter, Miguel Ojeda, Alex Gaynor,
Wedson Almeida Filho, Boqun Feng, Gary Guo, Björn Roy Baron,
Sumit Semwal, Luben Tuikov, Jarkko Sakkinen, Dave Hansen,
Alyssa Rosenzweig, Ella Stanforth, Faith Ekstrand, Mary,
linux-kernel, dri-devel, rust-for-linux, linux-media,
linaro-mm-sig, linux-sgx, asahi
On Wed, Mar 8, 2023 at 9:46 AM Christian König <christian.koenig@amd.com> wrote:
>
> Am 07.03.23 um 15:25 schrieb Asahi Lina:
> > Some hardware may require more complex resource utilization accounting
> > than the simple job count supported by drm_sched internally. Add a
> > can_run_job callback to allow drivers to implement more logic before
> > deciding whether to run a GPU job.
>
> Well complete NAK.
>
There hasn't even been any kind of discussion yet you already come
around with a "Well complete NAK"
First, this can be seen as rude behavior and me being part of the drm
community I don't want to have to see this kind of thing.
Obviously, any kind of strong "technical" review point is a nak until
people settle with an agreement on what to land, there is no point in
pointing out a "NAK", especially if that's the first thing you say. If
you want to express your strong disagreement with the proposed
solution, then state what your pain points are directly.
If there is a long discussion and a maintainer feels it's going
nowhere and no conclusion will be reached it might be this kind of
"speaking with authority" point has to be made. But not as the starter
into a discussion. This is unnecessarily hostile towards the
contributor. And I wished we wouldn't have to see this kind of
behavior here.
Yes, some kernel maintainers do this a lot, but kernel maintainers
also have this kind of reputation and people don't want to have to
deal with this nonsense and decide to not contribute at all. So please
just drop this attitude.
> This is clearly going against the idea of having jobs only depend on
> fences and nothing else which is mandatory for correct memory management.
>
I'm sure it's all documented and there is a design document on how
things have to look like you can point out? Might help to get a better
understanding on how things should be.
> If the hw is busy with something you need to return the fence for this
> from the prepare_job callback so that the scheduler can be notified when
> the hw is available again.
>
> Regards,
> Christian.
>
> >
> > Signed-off-by: Asahi Lina <lina@asahilina.net>
> > ---
> > drivers/gpu/drm/scheduler/sched_main.c | 10 ++++++++++
> > include/drm/gpu_scheduler.h | 8 ++++++++
> > 2 files changed, 18 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/scheduler/sched_main.c b/drivers/gpu/drm/scheduler/sched_main.c
> > index 4e6ad6e122bc..5c0add2c7546 100644
> > --- a/drivers/gpu/drm/scheduler/sched_main.c
> > +++ b/drivers/gpu/drm/scheduler/sched_main.c
> > @@ -1001,6 +1001,16 @@ static int drm_sched_main(void *param)
> > if (!entity)
> > continue;
> >
> > + if (sched->ops->can_run_job) {
> > + sched_job = to_drm_sched_job(spsc_queue_peek(&entity->job_queue));
> > + if (!sched_job) {
> > + complete_all(&entity->entity_idle);
> > + continue;
> > + }
> > + if (!sched->ops->can_run_job(sched_job))
> > + continue;
> > + }
> > +
> > sched_job = drm_sched_entity_pop_job(entity);
> >
> > if (!sched_job) {
> > diff --git a/include/drm/gpu_scheduler.h b/include/drm/gpu_scheduler.h
> > index 9db9e5e504ee..bd89ea9507b9 100644
> > --- a/include/drm/gpu_scheduler.h
> > +++ b/include/drm/gpu_scheduler.h
> > @@ -396,6 +396,14 @@ struct drm_sched_backend_ops {
> > struct dma_fence *(*prepare_job)(struct drm_sched_job *sched_job,
> > struct drm_sched_entity *s_entity);
> >
> > + /**
> > + * @can_run_job: Called before job execution to check whether the
> > + * hardware is free enough to run the job. This can be used to
> > + * implement more complex hardware resource policies than the
> > + * hw_submission limit.
> > + */
> > + bool (*can_run_job)(struct drm_sched_job *sched_job);
> > +
> > /**
> > * @run_job: Called to execute the job once all of the dependencies
> > * have been resolved. This may be called multiple times, if
> >
>
^ permalink raw reply [flat|nested] 122+ messages in thread* Re: [PATCH RFC 10/18] drm/scheduler: Add can_run_job callback
2023-03-08 12:39 ` Karol Herbst
@ 2023-03-08 13:47 ` Christian König
2023-03-08 14:43 ` Karol Herbst
0 siblings, 1 reply; 122+ messages in thread
From: Christian König @ 2023-03-08 13:47 UTC (permalink / raw)
To: Karol Herbst
Cc: Asahi Lina, Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
David Airlie, Daniel Vetter, Miguel Ojeda, Alex Gaynor,
Wedson Almeida Filho, Boqun Feng, Gary Guo, Björn Roy Baron,
Sumit Semwal, Luben Tuikov, Jarkko Sakkinen, Dave Hansen,
Alyssa Rosenzweig, Ella Stanforth, Faith Ekstrand, Mary,
linux-kernel, dri-devel, rust-for-linux, linux-media,
linaro-mm-sig, linux-sgx, asahi
Am 08.03.23 um 13:39 schrieb Karol Herbst:
> On Wed, Mar 8, 2023 at 9:46 AM Christian König <christian.koenig@amd.com> wrote:
>> Am 07.03.23 um 15:25 schrieb Asahi Lina:
>>> Some hardware may require more complex resource utilization accounting
>>> than the simple job count supported by drm_sched internally. Add a
>>> can_run_job callback to allow drivers to implement more logic before
>>> deciding whether to run a GPU job.
>> Well complete NAK.
>>
> There hasn't even been any kind of discussion yet you already come
> around with a "Well complete NAK"
>
> First, this can be seen as rude behavior and me being part of the drm
> community I don't want to have to see this kind of thing.
>
> Obviously, any kind of strong "technical" review point is a nak until
> people settle with an agreement on what to land, there is no point in
> pointing out a "NAK", especially if that's the first thing you say. If
> you want to express your strong disagreement with the proposed
> solution, then state what your pain points are directly.
>
> If there is a long discussion and a maintainer feels it's going
> nowhere and no conclusion will be reached it might be this kind of
> "speaking with authority" point has to be made. But not as the starter
> into a discussion. This is unnecessarily hostile towards the
> contributor. And I wished we wouldn't have to see this kind of
> behavior here.
>
> Yes, some kernel maintainers do this a lot, but kernel maintainers
> also have this kind of reputation and people don't want to have to
> deal with this nonsense and decide to not contribute at all. So please
> just drop this attitude.
Yes, you are completely right with that, but getting this message to the
recipient is intentional on my side.
I give completely NAKs when the author of a patch has missed such a
fundamental technical connection that further discussion doesn't make sense.
It's not meant to be in any way rude or offending. I can put a smiley
behind it if it somehow helps, but we still need a way to raise this big
red stop sign.
>> This is clearly going against the idea of having jobs only depend on
>> fences and nothing else which is mandatory for correct memory management.
>>
> I'm sure it's all documented and there is a design document on how
> things have to look like you can point out? Might help to get a better
> understanding on how things should be.
Yeah, that's the problematic part. We have documented this very
extensively:
https://www.kernel.org/doc/html/v5.9/driver-api/dma-buf.html#indefinite-dma-fences
And both Jason and Daniel gave talks about the underlying problem and
try to come up with patches to raise warnings when that happens, but
people still keep coming up with the same idea over and over again.
It's just that the technical relationship between preventing jobs from
running and with that preventing dma_fences from signaling and the core
memory management with page faults and shrinkers waiting for those
fences is absolutely not obvious.
We had at least 10 different teams from different companies falling into
the same trap already and either the patches were rejected of hand or
had to painfully reverted or mitigated later on.
Regards,
Christian.
>
>> If the hw is busy with something you need to return the fence for this
>> from the prepare_job callback so that the scheduler can be notified when
>> the hw is available again.
>>
>> Regards,
>> Christian.
>>
>>> Signed-off-by: Asahi Lina <lina@asahilina.net>
>>> ---
>>> drivers/gpu/drm/scheduler/sched_main.c | 10 ++++++++++
>>> include/drm/gpu_scheduler.h | 8 ++++++++
>>> 2 files changed, 18 insertions(+)
>>>
>>> diff --git a/drivers/gpu/drm/scheduler/sched_main.c b/drivers/gpu/drm/scheduler/sched_main.c
>>> index 4e6ad6e122bc..5c0add2c7546 100644
>>> --- a/drivers/gpu/drm/scheduler/sched_main.c
>>> +++ b/drivers/gpu/drm/scheduler/sched_main.c
>>> @@ -1001,6 +1001,16 @@ static int drm_sched_main(void *param)
>>> if (!entity)
>>> continue;
>>>
>>> + if (sched->ops->can_run_job) {
>>> + sched_job = to_drm_sched_job(spsc_queue_peek(&entity->job_queue));
>>> + if (!sched_job) {
>>> + complete_all(&entity->entity_idle);
>>> + continue;
>>> + }
>>> + if (!sched->ops->can_run_job(sched_job))
>>> + continue;
>>> + }
>>> +
>>> sched_job = drm_sched_entity_pop_job(entity);
>>>
>>> if (!sched_job) {
>>> diff --git a/include/drm/gpu_scheduler.h b/include/drm/gpu_scheduler.h
>>> index 9db9e5e504ee..bd89ea9507b9 100644
>>> --- a/include/drm/gpu_scheduler.h
>>> +++ b/include/drm/gpu_scheduler.h
>>> @@ -396,6 +396,14 @@ struct drm_sched_backend_ops {
>>> struct dma_fence *(*prepare_job)(struct drm_sched_job *sched_job,
>>> struct drm_sched_entity *s_entity);
>>>
>>> + /**
>>> + * @can_run_job: Called before job execution to check whether the
>>> + * hardware is free enough to run the job. This can be used to
>>> + * implement more complex hardware resource policies than the
>>> + * hw_submission limit.
>>> + */
>>> + bool (*can_run_job)(struct drm_sched_job *sched_job);
>>> +
>>> /**
>>> * @run_job: Called to execute the job once all of the dependencies
>>> * have been resolved. This may be called multiple times, if
>>>
^ permalink raw reply [flat|nested] 122+ messages in thread* Re: [PATCH RFC 10/18] drm/scheduler: Add can_run_job callback
2023-03-08 13:47 ` Christian König
@ 2023-03-08 14:43 ` Karol Herbst
2023-03-08 15:02 ` Christian König
0 siblings, 1 reply; 122+ messages in thread
From: Karol Herbst @ 2023-03-08 14:43 UTC (permalink / raw)
To: Christian König
Cc: Asahi Lina, Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
David Airlie, Daniel Vetter, Miguel Ojeda, Alex Gaynor,
Wedson Almeida Filho, Boqun Feng, Gary Guo, Björn Roy Baron,
Sumit Semwal, Luben Tuikov, Jarkko Sakkinen, Dave Hansen,
Alyssa Rosenzweig, Ella Stanforth, Faith Ekstrand, Mary,
linux-kernel, dri-devel, rust-for-linux, linux-media,
linaro-mm-sig, linux-sgx, asahi
On Wed, Mar 8, 2023 at 2:47 PM Christian König <christian.koenig@amd.com> wrote:
>
> Am 08.03.23 um 13:39 schrieb Karol Herbst:
> > On Wed, Mar 8, 2023 at 9:46 AM Christian König <christian.koenig@amd.com> wrote:
> >> Am 07.03.23 um 15:25 schrieb Asahi Lina:
> >>> Some hardware may require more complex resource utilization accounting
> >>> than the simple job count supported by drm_sched internally. Add a
> >>> can_run_job callback to allow drivers to implement more logic before
> >>> deciding whether to run a GPU job.
> >> Well complete NAK.
> >>
> > There hasn't even been any kind of discussion yet you already come
> > around with a "Well complete NAK"
> >
> > First, this can be seen as rude behavior and me being part of the drm
> > community I don't want to have to see this kind of thing.
> >
> > Obviously, any kind of strong "technical" review point is a nak until
> > people settle with an agreement on what to land, there is no point in
> > pointing out a "NAK", especially if that's the first thing you say. If
> > you want to express your strong disagreement with the proposed
> > solution, then state what your pain points are directly.
> >
> > If there is a long discussion and a maintainer feels it's going
> > nowhere and no conclusion will be reached it might be this kind of
> > "speaking with authority" point has to be made. But not as the starter
> > into a discussion. This is unnecessarily hostile towards the
> > contributor. And I wished we wouldn't have to see this kind of
> > behavior here.
> >
> > Yes, some kernel maintainers do this a lot, but kernel maintainers
> > also have this kind of reputation and people don't want to have to
> > deal with this nonsense and decide to not contribute at all. So please
> > just drop this attitude.
>
> Yes, you are completely right with that, but getting this message to the
> recipient is intentional on my side.
>
> I give completely NAKs when the author of a patch has missed such a
> fundamental technical connection that further discussion doesn't make sense.
>
> It's not meant to be in any way rude or offending. I can put a smiley
> behind it if it somehow helps, but we still need a way to raise this big
> red stop sign.
>
"further"? There was no discussion at all, you just started off like
that. If you think somebody misses that connection, you can point out
to documentation/videos whatever so the contributor can understand
what's wrong with an approach. You did that, so that's fine. It's just
starting off _any_ discussion with a "Well complete NAK" is terrible
style. I'd feel uncomfortable if that happened to me and I'm sure
there are enough people like that that we should be more reasonable
with our replies. Just.. don't.
We are all humans here and people react negatively to such things. And
if people do it on purpose it just makes it worse.
> >> This is clearly going against the idea of having jobs only depend on
> >> fences and nothing else which is mandatory for correct memory management.
> >>
> > I'm sure it's all documented and there is a design document on how
> > things have to look like you can point out? Might help to get a better
> > understanding on how things should be.
>
> Yeah, that's the problematic part. We have documented this very
> extensively:
> https://www.kernel.org/doc/html/v5.9/driver-api/dma-buf.html#indefinite-dma-fences
>
> And both Jason and Daniel gave talks about the underlying problem and
fyi:
s/Jason/Faith/g
> try to come up with patches to raise warnings when that happens, but
> people still keep coming up with the same idea over and over again.
>
Yes, and we'll have to tell them over and over again. Nothing wrong
with that. That's just part of maintaining such a big subsystem. And
that's definitely not a valid reason to phrase things like above.
> It's just that the technical relationship between preventing jobs from
> running and with that preventing dma_fences from signaling and the core
> memory management with page faults and shrinkers waiting for those
> fences is absolutely not obvious.
>
> We had at least 10 different teams from different companies falling into
> the same trap already and either the patches were rejected of hand or
> had to painfully reverted or mitigated later on.
>
Sure, but that's just part of the job. And pointing out fundamental
mistakes early on is important, but the situation won't get any better
by being like that. Yes, we'll have to repeat the same words over and
over again, and yes that might be annoying, but that's just how it is.
> Regards,
> Christian.
>
> >
> >> If the hw is busy with something you need to return the fence for this
> >> from the prepare_job callback so that the scheduler can be notified when
> >> the hw is available again.
> >>
> >> Regards,
> >> Christian.
> >>
> >>> Signed-off-by: Asahi Lina <lina@asahilina.net>
> >>> ---
> >>> drivers/gpu/drm/scheduler/sched_main.c | 10 ++++++++++
> >>> include/drm/gpu_scheduler.h | 8 ++++++++
> >>> 2 files changed, 18 insertions(+)
> >>>
> >>> diff --git a/drivers/gpu/drm/scheduler/sched_main.c b/drivers/gpu/drm/scheduler/sched_main.c
> >>> index 4e6ad6e122bc..5c0add2c7546 100644
> >>> --- a/drivers/gpu/drm/scheduler/sched_main.c
> >>> +++ b/drivers/gpu/drm/scheduler/sched_main.c
> >>> @@ -1001,6 +1001,16 @@ static int drm_sched_main(void *param)
> >>> if (!entity)
> >>> continue;
> >>>
> >>> + if (sched->ops->can_run_job) {
> >>> + sched_job = to_drm_sched_job(spsc_queue_peek(&entity->job_queue));
> >>> + if (!sched_job) {
> >>> + complete_all(&entity->entity_idle);
> >>> + continue;
> >>> + }
> >>> + if (!sched->ops->can_run_job(sched_job))
> >>> + continue;
> >>> + }
> >>> +
> >>> sched_job = drm_sched_entity_pop_job(entity);
> >>>
> >>> if (!sched_job) {
> >>> diff --git a/include/drm/gpu_scheduler.h b/include/drm/gpu_scheduler.h
> >>> index 9db9e5e504ee..bd89ea9507b9 100644
> >>> --- a/include/drm/gpu_scheduler.h
> >>> +++ b/include/drm/gpu_scheduler.h
> >>> @@ -396,6 +396,14 @@ struct drm_sched_backend_ops {
> >>> struct dma_fence *(*prepare_job)(struct drm_sched_job *sched_job,
> >>> struct drm_sched_entity *s_entity);
> >>>
> >>> + /**
> >>> + * @can_run_job: Called before job execution to check whether the
> >>> + * hardware is free enough to run the job. This can be used to
> >>> + * implement more complex hardware resource policies than the
> >>> + * hw_submission limit.
> >>> + */
> >>> + bool (*can_run_job)(struct drm_sched_job *sched_job);
> >>> +
> >>> /**
> >>> * @run_job: Called to execute the job once all of the dependencies
> >>> * have been resolved. This may be called multiple times, if
> >>>
>
^ permalink raw reply [flat|nested] 122+ messages in thread* Re: [PATCH RFC 10/18] drm/scheduler: Add can_run_job callback
2023-03-08 14:43 ` Karol Herbst
@ 2023-03-08 15:02 ` Christian König
2023-03-08 15:19 ` Karol Herbst
0 siblings, 1 reply; 122+ messages in thread
From: Christian König @ 2023-03-08 15:02 UTC (permalink / raw)
To: Karol Herbst
Cc: Asahi Lina, Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
David Airlie, Daniel Vetter, Miguel Ojeda, Alex Gaynor,
Wedson Almeida Filho, Boqun Feng, Gary Guo, Björn Roy Baron,
Sumit Semwal, Luben Tuikov, Jarkko Sakkinen, Dave Hansen,
Alyssa Rosenzweig, Ella Stanforth, Faith Ekstrand, Mary,
linux-kernel, dri-devel, rust-for-linux, linux-media,
linaro-mm-sig, linux-sgx, asahi
Am 08.03.23 um 15:43 schrieb Karol Herbst:
> [SNIP]
> "further"? There was no discussion at all,
Yeah, well that is exactly what I wanted to archive.
> you just started off like
> that. If you think somebody misses that connection, you can point out
> to documentation/videos whatever so the contributor can understand
> what's wrong with an approach. You did that, so that's fine. It's just
> starting off _any_ discussion with a "Well complete NAK" is terrible
> style. I'd feel uncomfortable if that happened to me and I'm sure
> there are enough people like that that we should be more reasonable
> with our replies. Just.. don't.
>
> We are all humans here and people react negatively to such things. And
> if people do it on purpose it just makes it worse.
I completely see your point, I just don't know how to improve it.
I don't stop people like this because I want to make them uncomfortable
but because I want to prevent further discussions on that topic.
In other words how can I make people notice that this is something
fundamental while still being polite?
>>>> This is clearly going against the idea of having jobs only depend on
>>>> fences and nothing else which is mandatory for correct memory management.
>>>>
>>> I'm sure it's all documented and there is a design document on how
>>> things have to look like you can point out? Might help to get a better
>>> understanding on how things should be.
>> Yeah, that's the problematic part. We have documented this very
>> extensively:
>> https://www.kernel.org/doc/html/v5.9/driver-api/dma-buf.html#indefinite-dma-fences
>>
>> And both Jason and Daniel gave talks about the underlying problem and
> fyi:
> s/Jason/Faith/g
+1. I wasn't aware of that.
>> try to come up with patches to raise warnings when that happens, but
>> people still keep coming up with the same idea over and over again.
>>
> Yes, and we'll have to tell them over and over again. Nothing wrong
> with that. That's just part of maintaining such a big subsystem. And
> that's definitely not a valid reason to phrase things like above.
>
>> It's just that the technical relationship between preventing jobs from
>> running and with that preventing dma_fences from signaling and the core
>> memory management with page faults and shrinkers waiting for those
>> fences is absolutely not obvious.
>>
>> We had at least 10 different teams from different companies falling into
>> the same trap already and either the patches were rejected of hand or
>> had to painfully reverted or mitigated later on.
>>
> Sure, but that's just part of the job. And pointing out fundamental
> mistakes early on is important, but the situation won't get any better
> by being like that. Yes, we'll have to repeat the same words over and
> over again, and yes that might be annoying, but that's just how it is.
Well I have no problem explaining people why a solution doesn't work.
But what usually happens is that people don't realize that they need to
back of from a design and completely start over.
Regards,
Christian.
>
>> Regards,
>> Christian.
>>
>>>> If the hw is busy with something you need to return the fence for this
>>>> from the prepare_job callback so that the scheduler can be notified when
>>>> the hw is available again.
>>>>
>>>> Regards,
>>>> Christian.
>>>>
>>>>> Signed-off-by: Asahi Lina <lina@asahilina.net>
>>>>> ---
>>>>> drivers/gpu/drm/scheduler/sched_main.c | 10 ++++++++++
>>>>> include/drm/gpu_scheduler.h | 8 ++++++++
>>>>> 2 files changed, 18 insertions(+)
>>>>>
>>>>> diff --git a/drivers/gpu/drm/scheduler/sched_main.c b/drivers/gpu/drm/scheduler/sched_main.c
>>>>> index 4e6ad6e122bc..5c0add2c7546 100644
>>>>> --- a/drivers/gpu/drm/scheduler/sched_main.c
>>>>> +++ b/drivers/gpu/drm/scheduler/sched_main.c
>>>>> @@ -1001,6 +1001,16 @@ static int drm_sched_main(void *param)
>>>>> if (!entity)
>>>>> continue;
>>>>>
>>>>> + if (sched->ops->can_run_job) {
>>>>> + sched_job = to_drm_sched_job(spsc_queue_peek(&entity->job_queue));
>>>>> + if (!sched_job) {
>>>>> + complete_all(&entity->entity_idle);
>>>>> + continue;
>>>>> + }
>>>>> + if (!sched->ops->can_run_job(sched_job))
>>>>> + continue;
>>>>> + }
>>>>> +
>>>>> sched_job = drm_sched_entity_pop_job(entity);
>>>>>
>>>>> if (!sched_job) {
>>>>> diff --git a/include/drm/gpu_scheduler.h b/include/drm/gpu_scheduler.h
>>>>> index 9db9e5e504ee..bd89ea9507b9 100644
>>>>> --- a/include/drm/gpu_scheduler.h
>>>>> +++ b/include/drm/gpu_scheduler.h
>>>>> @@ -396,6 +396,14 @@ struct drm_sched_backend_ops {
>>>>> struct dma_fence *(*prepare_job)(struct drm_sched_job *sched_job,
>>>>> struct drm_sched_entity *s_entity);
>>>>>
>>>>> + /**
>>>>> + * @can_run_job: Called before job execution to check whether the
>>>>> + * hardware is free enough to run the job. This can be used to
>>>>> + * implement more complex hardware resource policies than the
>>>>> + * hw_submission limit.
>>>>> + */
>>>>> + bool (*can_run_job)(struct drm_sched_job *sched_job);
>>>>> +
>>>>> /**
>>>>> * @run_job: Called to execute the job once all of the dependencies
>>>>> * have been resolved. This may be called multiple times, if
>>>>>
^ permalink raw reply [flat|nested] 122+ messages in thread* Re: [PATCH RFC 10/18] drm/scheduler: Add can_run_job callback
2023-03-08 15:02 ` Christian König
@ 2023-03-08 15:19 ` Karol Herbst
2023-03-16 13:40 ` Daniel Vetter
0 siblings, 1 reply; 122+ messages in thread
From: Karol Herbst @ 2023-03-08 15:19 UTC (permalink / raw)
To: Christian König
Cc: Asahi Lina, Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
David Airlie, Daniel Vetter, Miguel Ojeda, Alex Gaynor,
Wedson Almeida Filho, Boqun Feng, Gary Guo, Björn Roy Baron,
Sumit Semwal, Luben Tuikov, Jarkko Sakkinen, Dave Hansen,
Alyssa Rosenzweig, Ella Stanforth, Faith Ekstrand, Mary,
linux-kernel, dri-devel, rust-for-linux, linux-media,
linaro-mm-sig, linux-sgx, asahi
On Wed, Mar 8, 2023 at 4:09 PM Christian König <christian.koenig@amd.com> wrote:
>
> Am 08.03.23 um 15:43 schrieb Karol Herbst:
> > [SNIP]
> > "further"? There was no discussion at all,
>
> Yeah, well that is exactly what I wanted to archive.
>
> > you just started off like
> > that. If you think somebody misses that connection, you can point out
> > to documentation/videos whatever so the contributor can understand
> > what's wrong with an approach. You did that, so that's fine. It's just
> > starting off _any_ discussion with a "Well complete NAK" is terrible
> > style. I'd feel uncomfortable if that happened to me and I'm sure
> > there are enough people like that that we should be more reasonable
> > with our replies. Just.. don't.
> >
> > We are all humans here and people react negatively to such things. And
> > if people do it on purpose it just makes it worse.
>
> I completely see your point, I just don't know how to improve it.
>
> I don't stop people like this because I want to make them uncomfortable
> but because I want to prevent further discussions on that topic.
>
> In other words how can I make people notice that this is something
> fundamental while still being polite?
>
I think a little improvement over this would be to at least wait a few
replies before resorting to those strong statements. Just before it
becomes a risk in just wasting time.
> >>>> This is clearly going against the idea of having jobs only depend on
> >>>> fences and nothing else which is mandatory for correct memory management.
> >>>>
> >>> I'm sure it's all documented and there is a design document on how
> >>> things have to look like you can point out? Might help to get a better
> >>> understanding on how things should be.
> >> Yeah, that's the problematic part. We have documented this very
> >> extensively:
> >> https://www.kernel.org/doc/html/v5.9/driver-api/dma-buf.html#indefinite-dma-fences
> >>
> >> And both Jason and Daniel gave talks about the underlying problem and
> > fyi:
> > s/Jason/Faith/g
>
> +1. I wasn't aware of that.
>
> >> try to come up with patches to raise warnings when that happens, but
> >> people still keep coming up with the same idea over and over again.
> >>
> > Yes, and we'll have to tell them over and over again. Nothing wrong
> > with that. That's just part of maintaining such a big subsystem. And
> > that's definitely not a valid reason to phrase things like above.
> >
> >> It's just that the technical relationship between preventing jobs from
> >> running and with that preventing dma_fences from signaling and the core
> >> memory management with page faults and shrinkers waiting for those
> >> fences is absolutely not obvious.
> >>
> >> We had at least 10 different teams from different companies falling into
> >> the same trap already and either the patches were rejected of hand or
> >> had to painfully reverted or mitigated later on.
> >>
> > Sure, but that's just part of the job. And pointing out fundamental
> > mistakes early on is important, but the situation won't get any better
> > by being like that. Yes, we'll have to repeat the same words over and
> > over again, and yes that might be annoying, but that's just how it is.
>
> Well I have no problem explaining people why a solution doesn't work.
>
> But what usually happens is that people don't realize that they need to
> back of from a design and completely start over.
>
> Regards,
> Christian.
>
> >
> >> Regards,
> >> Christian.
> >>
> >>>> If the hw is busy with something you need to return the fence for this
> >>>> from the prepare_job callback so that the scheduler can be notified when
> >>>> the hw is available again.
> >>>>
> >>>> Regards,
> >>>> Christian.
> >>>>
> >>>>> Signed-off-by: Asahi Lina <lina@asahilina.net>
> >>>>> ---
> >>>>> drivers/gpu/drm/scheduler/sched_main.c | 10 ++++++++++
> >>>>> include/drm/gpu_scheduler.h | 8 ++++++++
> >>>>> 2 files changed, 18 insertions(+)
> >>>>>
> >>>>> diff --git a/drivers/gpu/drm/scheduler/sched_main.c b/drivers/gpu/drm/scheduler/sched_main.c
> >>>>> index 4e6ad6e122bc..5c0add2c7546 100644
> >>>>> --- a/drivers/gpu/drm/scheduler/sched_main.c
> >>>>> +++ b/drivers/gpu/drm/scheduler/sched_main.c
> >>>>> @@ -1001,6 +1001,16 @@ static int drm_sched_main(void *param)
> >>>>> if (!entity)
> >>>>> continue;
> >>>>>
> >>>>> + if (sched->ops->can_run_job) {
> >>>>> + sched_job = to_drm_sched_job(spsc_queue_peek(&entity->job_queue));
> >>>>> + if (!sched_job) {
> >>>>> + complete_all(&entity->entity_idle);
> >>>>> + continue;
> >>>>> + }
> >>>>> + if (!sched->ops->can_run_job(sched_job))
> >>>>> + continue;
> >>>>> + }
> >>>>> +
> >>>>> sched_job = drm_sched_entity_pop_job(entity);
> >>>>>
> >>>>> if (!sched_job) {
> >>>>> diff --git a/include/drm/gpu_scheduler.h b/include/drm/gpu_scheduler.h
> >>>>> index 9db9e5e504ee..bd89ea9507b9 100644
> >>>>> --- a/include/drm/gpu_scheduler.h
> >>>>> +++ b/include/drm/gpu_scheduler.h
> >>>>> @@ -396,6 +396,14 @@ struct drm_sched_backend_ops {
> >>>>> struct dma_fence *(*prepare_job)(struct drm_sched_job *sched_job,
> >>>>> struct drm_sched_entity *s_entity);
> >>>>>
> >>>>> + /**
> >>>>> + * @can_run_job: Called before job execution to check whether the
> >>>>> + * hardware is free enough to run the job. This can be used to
> >>>>> + * implement more complex hardware resource policies than the
> >>>>> + * hw_submission limit.
> >>>>> + */
> >>>>> + bool (*can_run_job)(struct drm_sched_job *sched_job);
> >>>>> +
> >>>>> /**
> >>>>> * @run_job: Called to execute the job once all of the dependencies
> >>>>> * have been resolved. This may be called multiple times, if
> >>>>>
>
^ permalink raw reply [flat|nested] 122+ messages in thread* Re: [PATCH RFC 10/18] drm/scheduler: Add can_run_job callback
2023-03-08 15:19 ` Karol Herbst
@ 2023-03-16 13:40 ` Daniel Vetter
0 siblings, 0 replies; 122+ messages in thread
From: Daniel Vetter @ 2023-03-16 13:40 UTC (permalink / raw)
To: Karol Herbst
Cc: Christian König, Asahi Lina, Maarten Lankhorst,
Maxime Ripard, Thomas Zimmermann, David Airlie, Daniel Vetter,
Miguel Ojeda, Alex Gaynor, Wedson Almeida Filho, Boqun Feng,
Gary Guo, Björn Roy Baron, Sumit Semwal, Luben Tuikov,
Jarkko Sakkinen, Dave Hansen, Alyssa Rosenzweig, Ella Stanforth,
Faith Ekstrand, Mary, linux-kernel, dri-devel, rust-for-linux,
linux-media, linaro-mm-sig, linux-sgx, asahi
On Wed, Mar 08, 2023 at 04:19:17PM +0100, Karol Herbst wrote:
> On Wed, Mar 8, 2023 at 4:09 PM Christian König <christian.koenig@amd.com> wrote:
> >
> > Am 08.03.23 um 15:43 schrieb Karol Herbst:
> > > [SNIP]
> > > "further"? There was no discussion at all,
> >
> > Yeah, well that is exactly what I wanted to archive.
> >
> > > you just started off like
> > > that. If you think somebody misses that connection, you can point out
> > > to documentation/videos whatever so the contributor can understand
> > > what's wrong with an approach. You did that, so that's fine. It's just
> > > starting off _any_ discussion with a "Well complete NAK" is terrible
> > > style. I'd feel uncomfortable if that happened to me and I'm sure
> > > there are enough people like that that we should be more reasonable
> > > with our replies. Just.. don't.
> > >
> > > We are all humans here and people react negatively to such things. And
> > > if people do it on purpose it just makes it worse.
> >
> > I completely see your point, I just don't know how to improve it.
> >
> > I don't stop people like this because I want to make them uncomfortable
> > but because I want to prevent further discussions on that topic.
> >
> > In other words how can I make people notice that this is something
> > fundamental while still being polite?
Ask them to improve the docs. Gets them on board, and for bonus point you
- can check they actually get it when you review the doc patch
- get scheduler docs for free
- have an easily pasteable link for next time around instead of just an
aggressive NAK that helps no one really (aside from getting people
boiling).
It's not really about being polite but making sure that efficient
communiction happens and that you don't have to repeat yourself. In rare
cases you get to type the docs themself when people are too dense to learn
(like what I had to do with the various dma_fence docs).
> I think a little improvement over this would be to at least wait a few
> replies before resorting to those strong statements. Just before it
> becomes a risk in just wasting time.
See above what I'm trying to do. When the message doesn't sink in as
either a proper doc patch or when linking to the doc patch for next time
around (because let's face it, this entire concept of "dma_fence committed
for execution" is extremely trick, there will be repeations of this
question until we've sunset dma_fence, which is probably decades away).
If the learning does not happen, then it's the time to whack the big
hammer (and if people don't get it, you can escalate to Dave&me, we have
tools to make sure people get the message). But this really should be the
end, not the start of the escalation chain :-)
Cheers, Daniel
>
> > >>>> This is clearly going against the idea of having jobs only depend on
> > >>>> fences and nothing else which is mandatory for correct memory management.
> > >>>>
> > >>> I'm sure it's all documented and there is a design document on how
> > >>> things have to look like you can point out? Might help to get a better
> > >>> understanding on how things should be.
> > >> Yeah, that's the problematic part. We have documented this very
> > >> extensively:
> > >> https://www.kernel.org/doc/html/v5.9/driver-api/dma-buf.html#indefinite-dma-fences
> > >>
> > >> And both Jason and Daniel gave talks about the underlying problem and
> > > fyi:
> > > s/Jason/Faith/g
> >
> > +1. I wasn't aware of that.
> >
> > >> try to come up with patches to raise warnings when that happens, but
> > >> people still keep coming up with the same idea over and over again.
> > >>
> > > Yes, and we'll have to tell them over and over again. Nothing wrong
> > > with that. That's just part of maintaining such a big subsystem. And
> > > that's definitely not a valid reason to phrase things like above.
> > >
> > >> It's just that the technical relationship between preventing jobs from
> > >> running and with that preventing dma_fences from signaling and the core
> > >> memory management with page faults and shrinkers waiting for those
> > >> fences is absolutely not obvious.
> > >>
> > >> We had at least 10 different teams from different companies falling into
> > >> the same trap already and either the patches were rejected of hand or
> > >> had to painfully reverted or mitigated later on.
> > >>
> > > Sure, but that's just part of the job. And pointing out fundamental
> > > mistakes early on is important, but the situation won't get any better
> > > by being like that. Yes, we'll have to repeat the same words over and
> > > over again, and yes that might be annoying, but that's just how it is.
> >
> > Well I have no problem explaining people why a solution doesn't work.
> >
> > But what usually happens is that people don't realize that they need to
> > back of from a design and completely start over.
> >
> > Regards,
> > Christian.
> >
> > >
> > >> Regards,
> > >> Christian.
> > >>
> > >>>> If the hw is busy with something you need to return the fence for this
> > >>>> from the prepare_job callback so that the scheduler can be notified when
> > >>>> the hw is available again.
> > >>>>
> > >>>> Regards,
> > >>>> Christian.
> > >>>>
> > >>>>> Signed-off-by: Asahi Lina <lina@asahilina.net>
> > >>>>> ---
> > >>>>> drivers/gpu/drm/scheduler/sched_main.c | 10 ++++++++++
> > >>>>> include/drm/gpu_scheduler.h | 8 ++++++++
> > >>>>> 2 files changed, 18 insertions(+)
> > >>>>>
> > >>>>> diff --git a/drivers/gpu/drm/scheduler/sched_main.c b/drivers/gpu/drm/scheduler/sched_main.c
> > >>>>> index 4e6ad6e122bc..5c0add2c7546 100644
> > >>>>> --- a/drivers/gpu/drm/scheduler/sched_main.c
> > >>>>> +++ b/drivers/gpu/drm/scheduler/sched_main.c
> > >>>>> @@ -1001,6 +1001,16 @@ static int drm_sched_main(void *param)
> > >>>>> if (!entity)
> > >>>>> continue;
> > >>>>>
> > >>>>> + if (sched->ops->can_run_job) {
> > >>>>> + sched_job = to_drm_sched_job(spsc_queue_peek(&entity->job_queue));
> > >>>>> + if (!sched_job) {
> > >>>>> + complete_all(&entity->entity_idle);
> > >>>>> + continue;
> > >>>>> + }
> > >>>>> + if (!sched->ops->can_run_job(sched_job))
> > >>>>> + continue;
> > >>>>> + }
> > >>>>> +
> > >>>>> sched_job = drm_sched_entity_pop_job(entity);
> > >>>>>
> > >>>>> if (!sched_job) {
> > >>>>> diff --git a/include/drm/gpu_scheduler.h b/include/drm/gpu_scheduler.h
> > >>>>> index 9db9e5e504ee..bd89ea9507b9 100644
> > >>>>> --- a/include/drm/gpu_scheduler.h
> > >>>>> +++ b/include/drm/gpu_scheduler.h
> > >>>>> @@ -396,6 +396,14 @@ struct drm_sched_backend_ops {
> > >>>>> struct dma_fence *(*prepare_job)(struct drm_sched_job *sched_job,
> > >>>>> struct drm_sched_entity *s_entity);
> > >>>>>
> > >>>>> + /**
> > >>>>> + * @can_run_job: Called before job execution to check whether the
> > >>>>> + * hardware is free enough to run the job. This can be used to
> > >>>>> + * implement more complex hardware resource policies than the
> > >>>>> + * hw_submission limit.
> > >>>>> + */
> > >>>>> + bool (*can_run_job)(struct drm_sched_job *sched_job);
> > >>>>> +
> > >>>>> /**
> > >>>>> * @run_job: Called to execute the job once all of the dependencies
> > >>>>> * have been resolved. This may be called multiple times, if
> > >>>>>
> >
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
^ permalink raw reply [flat|nested] 122+ messages in thread
* Re: [PATCH RFC 10/18] drm/scheduler: Add can_run_job callback
2023-03-07 14:25 ` [PATCH RFC 10/18] drm/scheduler: Add can_run_job callback Asahi Lina
2023-03-08 8:46 ` Christian König
@ 2023-04-05 13:40 ` Daniel Vetter
2023-04-05 14:14 ` Christian König
1 sibling, 1 reply; 122+ messages in thread
From: Daniel Vetter @ 2023-04-05 13:40 UTC (permalink / raw)
To: Asahi Lina
Cc: Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
David Airlie, Daniel Vetter, Miguel Ojeda, Alex Gaynor,
Wedson Almeida Filho, Boqun Feng, Gary Guo, Björn Roy Baron,
Sumit Semwal, Christian König, Luben Tuikov,
Jarkko Sakkinen, Dave Hansen, Alyssa Rosenzweig, Karol Herbst,
Ella Stanforth, Faith Ekstrand, Mary, linux-kernel, dri-devel,
rust-for-linux, linux-media, linaro-mm-sig, linux-sgx, asahi
On Tue, Mar 07, 2023 at 11:25:35PM +0900, Asahi Lina wrote:
> Some hardware may require more complex resource utilization accounting
> than the simple job count supported by drm_sched internally. Add a
> can_run_job callback to allow drivers to implement more logic before
> deciding whether to run a GPU job.
>
> Signed-off-by: Asahi Lina <lina@asahilina.net>
Ok scheduler rules, or trying to summarize the entire discussion:
dma_fence rules are very tricky. The two main chapters in the docs are
https://dri.freedesktop.org/docs/drm/driver-api/dma-buf.html?highlight=dma_buf#dma-fence-cross-driver-contract
https://dri.freedesktop.org/docs/drm/driver-api/dma-buf.html?highlight=dma_buf#indefinite-dma-fences
Unforutunately I don't think it's possible to check this at compile time,
thus far all we can do is validate at runtime. I've posted two patches for
this:
https://lore.kernel.org/dri-devel/20201023122216.2373294-17-daniel.vetter@ffwll.ch/
https://lore.kernel.org/dri-devel/20201023122216.2373294-20-daniel.vetter@ffwll.ch/
Unfortunately most drivers are buggy and get this completely wrong, so
realistically we'd need to make this a per-driver opt-out and annotate all
current drivers. Well except amdgpu is correct by now I think (they'd
still need to test that). And Rob Clark is working on patches to fix up
msm.
I think best here is if you work together with Rob to make sure these
annotations are mandatory for any rust drivers (I don't want new buggy
drivers at least). Would also be great to improve the kerneldoc for all
the driver hooks to explain these restrictions and link to the relevant
kerneldocs (there's also one for the dma_fence signalling annotations
which might be worth linking too).
I don't see any way to make this explicit in rust types, it's really only
something runtime tests (using lockdep) can catch. Somewhat disappointing.
For the other things discussed here:
- Option<Dma_Fence> as the return value for ->prepare_job makes sense to
me.
- I don't see any way a driver can use ->can_run_job without breaking the
above rules, that really doesn't sound like a good idea to me.
Cheers, Daniel
> ---
> drivers/gpu/drm/scheduler/sched_main.c | 10 ++++++++++
> include/drm/gpu_scheduler.h | 8 ++++++++
> 2 files changed, 18 insertions(+)
>
> diff --git a/drivers/gpu/drm/scheduler/sched_main.c b/drivers/gpu/drm/scheduler/sched_main.c
> index 4e6ad6e122bc..5c0add2c7546 100644
> --- a/drivers/gpu/drm/scheduler/sched_main.c
> +++ b/drivers/gpu/drm/scheduler/sched_main.c
> @@ -1001,6 +1001,16 @@ static int drm_sched_main(void *param)
> if (!entity)
> continue;
>
> + if (sched->ops->can_run_job) {
> + sched_job = to_drm_sched_job(spsc_queue_peek(&entity->job_queue));
> + if (!sched_job) {
> + complete_all(&entity->entity_idle);
> + continue;
> + }
> + if (!sched->ops->can_run_job(sched_job))
> + continue;
> + }
> +
> sched_job = drm_sched_entity_pop_job(entity);
>
> if (!sched_job) {
> diff --git a/include/drm/gpu_scheduler.h b/include/drm/gpu_scheduler.h
> index 9db9e5e504ee..bd89ea9507b9 100644
> --- a/include/drm/gpu_scheduler.h
> +++ b/include/drm/gpu_scheduler.h
> @@ -396,6 +396,14 @@ struct drm_sched_backend_ops {
> struct dma_fence *(*prepare_job)(struct drm_sched_job *sched_job,
> struct drm_sched_entity *s_entity);
>
> + /**
> + * @can_run_job: Called before job execution to check whether the
> + * hardware is free enough to run the job. This can be used to
> + * implement more complex hardware resource policies than the
> + * hw_submission limit.
> + */
> + bool (*can_run_job)(struct drm_sched_job *sched_job);
> +
> /**
> * @run_job: Called to execute the job once all of the dependencies
> * have been resolved. This may be called multiple times, if
>
> --
> 2.35.1
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
^ permalink raw reply [flat|nested] 122+ messages in thread* Re: [PATCH RFC 10/18] drm/scheduler: Add can_run_job callback
2023-04-05 13:40 ` Daniel Vetter
@ 2023-04-05 14:14 ` Christian König
2023-04-05 14:21 ` Daniel Vetter
0 siblings, 1 reply; 122+ messages in thread
From: Christian König @ 2023-04-05 14:14 UTC (permalink / raw)
To: Asahi Lina, Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
David Airlie, Miguel Ojeda, Alex Gaynor, Wedson Almeida Filho,
Boqun Feng, Gary Guo, Björn Roy Baron, Sumit Semwal,
Luben Tuikov, Jarkko Sakkinen, Dave Hansen, Alyssa Rosenzweig,
Karol Herbst, Ella Stanforth, Faith Ekstrand, Mary, linux-kernel,
dri-devel, rust-for-linux, linux-media, linaro-mm-sig, linux-sgx,
asahi
Am 05.04.23 um 15:40 schrieb Daniel Vetter:
> On Tue, Mar 07, 2023 at 11:25:35PM +0900, Asahi Lina wrote:
>> Some hardware may require more complex resource utilization accounting
>> than the simple job count supported by drm_sched internally. Add a
>> can_run_job callback to allow drivers to implement more logic before
>> deciding whether to run a GPU job.
>>
>> Signed-off-by: Asahi Lina <lina@asahilina.net>
> Ok scheduler rules, or trying to summarize the entire discussion:
>
> dma_fence rules are very tricky. The two main chapters in the docs are
>
> https://dri.freedesktop.org/docs/drm/driver-api/dma-buf.html?highlight=dma_buf#dma-fence-cross-driver-contract
> https://dri.freedesktop.org/docs/drm/driver-api/dma-buf.html?highlight=dma_buf#indefinite-dma-fences
>
> Unforutunately I don't think it's possible to check this at compile time,
> thus far all we can do is validate at runtime. I've posted two patches for
> this:
>
> https://lore.kernel.org/dri-devel/20201023122216.2373294-17-daniel.vetter@ffwll.ch/
> https://lore.kernel.org/dri-devel/20201023122216.2373294-20-daniel.vetter@ffwll.ch/
>
> Unfortunately most drivers are buggy and get this completely wrong, so
> realistically we'd need to make this a per-driver opt-out and annotate all
> current drivers. Well except amdgpu is correct by now I think (they'd
> still need to test that).
There is still one potential memory allocation in the run_job callback
in amdgpu which I wasn't able to fix yet.
But that one is purely academic and could potentially be trivially
replaced with using GFP_ATOMIC if we ever have to.
Christian.
> And Rob Clark is working on patches to fix up
> msm.
>
> I think best here is if you work together with Rob to make sure these
> annotations are mandatory for any rust drivers (I don't want new buggy
> drivers at least). Would also be great to improve the kerneldoc for all
> the driver hooks to explain these restrictions and link to the relevant
> kerneldocs (there's also one for the dma_fence signalling annotations
> which might be worth linking too).
>
> I don't see any way to make this explicit in rust types, it's really only
> something runtime tests (using lockdep) can catch. Somewhat disappointing.
>
> For the other things discussed here:
>
> - Option<Dma_Fence> as the return value for ->prepare_job makes sense to
> me.
>
> - I don't see any way a driver can use ->can_run_job without breaking the
> above rules, that really doesn't sound like a good idea to me.
>
> Cheers, Daniel
>
>> ---
>> drivers/gpu/drm/scheduler/sched_main.c | 10 ++++++++++
>> include/drm/gpu_scheduler.h | 8 ++++++++
>> 2 files changed, 18 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/scheduler/sched_main.c b/drivers/gpu/drm/scheduler/sched_main.c
>> index 4e6ad6e122bc..5c0add2c7546 100644
>> --- a/drivers/gpu/drm/scheduler/sched_main.c
>> +++ b/drivers/gpu/drm/scheduler/sched_main.c
>> @@ -1001,6 +1001,16 @@ static int drm_sched_main(void *param)
>> if (!entity)
>> continue;
>>
>> + if (sched->ops->can_run_job) {
>> + sched_job = to_drm_sched_job(spsc_queue_peek(&entity->job_queue));
>> + if (!sched_job) {
>> + complete_all(&entity->entity_idle);
>> + continue;
>> + }
>> + if (!sched->ops->can_run_job(sched_job))
>> + continue;
>> + }
>> +
>> sched_job = drm_sched_entity_pop_job(entity);
>>
>> if (!sched_job) {
>> diff --git a/include/drm/gpu_scheduler.h b/include/drm/gpu_scheduler.h
>> index 9db9e5e504ee..bd89ea9507b9 100644
>> --- a/include/drm/gpu_scheduler.h
>> +++ b/include/drm/gpu_scheduler.h
>> @@ -396,6 +396,14 @@ struct drm_sched_backend_ops {
>> struct dma_fence *(*prepare_job)(struct drm_sched_job *sched_job,
>> struct drm_sched_entity *s_entity);
>>
>> + /**
>> + * @can_run_job: Called before job execution to check whether the
>> + * hardware is free enough to run the job. This can be used to
>> + * implement more complex hardware resource policies than the
>> + * hw_submission limit.
>> + */
>> + bool (*can_run_job)(struct drm_sched_job *sched_job);
>> +
>> /**
>> * @run_job: Called to execute the job once all of the dependencies
>> * have been resolved. This may be called multiple times, if
>>
>> --
>> 2.35.1
>>
^ permalink raw reply [flat|nested] 122+ messages in thread* Re: [PATCH RFC 10/18] drm/scheduler: Add can_run_job callback
2023-04-05 14:14 ` Christian König
@ 2023-04-05 14:21 ` Daniel Vetter
0 siblings, 0 replies; 122+ messages in thread
From: Daniel Vetter @ 2023-04-05 14:21 UTC (permalink / raw)
To: Christian König
Cc: Asahi Lina, Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
David Airlie, Miguel Ojeda, Alex Gaynor, Wedson Almeida Filho,
Boqun Feng, Gary Guo, Björn Roy Baron, Sumit Semwal,
Luben Tuikov, Jarkko Sakkinen, Dave Hansen, Alyssa Rosenzweig,
Karol Herbst, Ella Stanforth, Faith Ekstrand, Mary, linux-kernel,
dri-devel, rust-for-linux, linux-media, linaro-mm-sig, linux-sgx,
asahi
On Wed, Apr 05, 2023 at 04:14:11PM +0200, Christian König wrote:
> Am 05.04.23 um 15:40 schrieb Daniel Vetter:
> > On Tue, Mar 07, 2023 at 11:25:35PM +0900, Asahi Lina wrote:
> > > Some hardware may require more complex resource utilization accounting
> > > than the simple job count supported by drm_sched internally. Add a
> > > can_run_job callback to allow drivers to implement more logic before
> > > deciding whether to run a GPU job.
> > >
> > > Signed-off-by: Asahi Lina <lina@asahilina.net>
> > Ok scheduler rules, or trying to summarize the entire discussion:
> >
> > dma_fence rules are very tricky. The two main chapters in the docs are
> >
> > https://dri.freedesktop.org/docs/drm/driver-api/dma-buf.html?highlight=dma_buf#dma-fence-cross-driver-contract
> > https://dri.freedesktop.org/docs/drm/driver-api/dma-buf.html?highlight=dma_buf#indefinite-dma-fences
> >
> > Unforutunately I don't think it's possible to check this at compile time,
> > thus far all we can do is validate at runtime. I've posted two patches for
> > this:
> >
> > https://lore.kernel.org/dri-devel/20201023122216.2373294-17-daniel.vetter@ffwll.ch/
> > https://lore.kernel.org/dri-devel/20201023122216.2373294-20-daniel.vetter@ffwll.ch/
> >
> > Unfortunately most drivers are buggy and get this completely wrong, so
> > realistically we'd need to make this a per-driver opt-out and annotate all
> > current drivers. Well except amdgpu is correct by now I think (they'd
> > still need to test that).
>
> There is still one potential memory allocation in the run_job callback in
> amdgpu which I wasn't able to fix yet.
>
> But that one is purely academic and could potentially be trivially replaced
> with using GFP_ATOMIC if we ever have to.
I think the modeset in the tdr code was more scary, and I'm not sure you
really managed to get rid of absolutely everything in there yet.
-Daniel
>
> Christian.
>
> > And Rob Clark is working on patches to fix up
> > msm.
> >
> > I think best here is if you work together with Rob to make sure these
> > annotations are mandatory for any rust drivers (I don't want new buggy
> > drivers at least). Would also be great to improve the kerneldoc for all
> > the driver hooks to explain these restrictions and link to the relevant
> > kerneldocs (there's also one for the dma_fence signalling annotations
> > which might be worth linking too).
> >
> > I don't see any way to make this explicit in rust types, it's really only
> > something runtime tests (using lockdep) can catch. Somewhat disappointing.
> >
> > For the other things discussed here:
> >
> > - Option<Dma_Fence> as the return value for ->prepare_job makes sense to
> > me.
> >
> > - I don't see any way a driver can use ->can_run_job without breaking the
> > above rules, that really doesn't sound like a good idea to me.
> >
> > Cheers, Daniel
> >
> > > ---
> > > drivers/gpu/drm/scheduler/sched_main.c | 10 ++++++++++
> > > include/drm/gpu_scheduler.h | 8 ++++++++
> > > 2 files changed, 18 insertions(+)
> > >
> > > diff --git a/drivers/gpu/drm/scheduler/sched_main.c b/drivers/gpu/drm/scheduler/sched_main.c
> > > index 4e6ad6e122bc..5c0add2c7546 100644
> > > --- a/drivers/gpu/drm/scheduler/sched_main.c
> > > +++ b/drivers/gpu/drm/scheduler/sched_main.c
> > > @@ -1001,6 +1001,16 @@ static int drm_sched_main(void *param)
> > > if (!entity)
> > > continue;
> > > + if (sched->ops->can_run_job) {
> > > + sched_job = to_drm_sched_job(spsc_queue_peek(&entity->job_queue));
> > > + if (!sched_job) {
> > > + complete_all(&entity->entity_idle);
> > > + continue;
> > > + }
> > > + if (!sched->ops->can_run_job(sched_job))
> > > + continue;
> > > + }
> > > +
> > > sched_job = drm_sched_entity_pop_job(entity);
> > > if (!sched_job) {
> > > diff --git a/include/drm/gpu_scheduler.h b/include/drm/gpu_scheduler.h
> > > index 9db9e5e504ee..bd89ea9507b9 100644
> > > --- a/include/drm/gpu_scheduler.h
> > > +++ b/include/drm/gpu_scheduler.h
> > > @@ -396,6 +396,14 @@ struct drm_sched_backend_ops {
> > > struct dma_fence *(*prepare_job)(struct drm_sched_job *sched_job,
> > > struct drm_sched_entity *s_entity);
> > > + /**
> > > + * @can_run_job: Called before job execution to check whether the
> > > + * hardware is free enough to run the job. This can be used to
> > > + * implement more complex hardware resource policies than the
> > > + * hw_submission limit.
> > > + */
> > > + bool (*can_run_job)(struct drm_sched_job *sched_job);
> > > +
> > > /**
> > > * @run_job: Called to execute the job once all of the dependencies
> > > * have been resolved. This may be called multiple times, if
> > >
> > > --
> > > 2.35.1
> > >
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
^ permalink raw reply [flat|nested] 122+ messages in thread
* [PATCH RFC 11/18] drm/scheduler: Clean up jobs when the scheduler is torn down
2023-03-07 14:25 [PATCH RFC 00/18] Rust DRM subsystem abstractions (& preview AGX driver) Asahi Lina
` (9 preceding siblings ...)
2023-03-07 14:25 ` [PATCH RFC 10/18] drm/scheduler: Add can_run_job callback Asahi Lina
@ 2023-03-07 14:25 ` Asahi Lina
2023-03-08 9:57 ` Maarten Lankhorst
2023-04-05 13:52 ` Daniel Vetter
2023-03-07 14:25 ` [PATCH RFC 12/18] rust: drm: sched: Add GPU scheduler abstraction Asahi Lina
` (7 subsequent siblings)
18 siblings, 2 replies; 122+ messages in thread
From: Asahi Lina @ 2023-03-07 14:25 UTC (permalink / raw)
To: Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
David Airlie, Daniel Vetter, Miguel Ojeda, Alex Gaynor,
Wedson Almeida Filho, Boqun Feng, Gary Guo, Björn Roy Baron,
Sumit Semwal, Christian König, Luben Tuikov,
Jarkko Sakkinen, Dave Hansen
Cc: Alyssa Rosenzweig, Karol Herbst, Ella Stanforth, Faith Ekstrand,
Mary, linux-kernel, dri-devel, rust-for-linux, linux-media,
linaro-mm-sig, linux-sgx, asahi, Asahi Lina
drm_sched_fini() currently leaves any pending jobs dangling, which
causes segfaults and other badness when job completion fences are
signaled after the scheduler is torn down.
Explicitly detach all jobs from their completion callbacks and free
them. This makes it possible to write a sensible safe abstraction for
drm_sched, without having to externally duplicate the tracking of
in-flight jobs.
This shouldn't regress any existing drivers, since calling
drm_sched_fini() with any pending jobs is broken and this change should
be a no-op if there are no pending jobs.
Signed-off-by: Asahi Lina <lina@asahilina.net>
---
drivers/gpu/drm/scheduler/sched_main.c | 27 +++++++++++++++++++++++++--
1 file changed, 25 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/scheduler/sched_main.c b/drivers/gpu/drm/scheduler/sched_main.c
index 5c0add2c7546..0aab1e0aebdd 100644
--- a/drivers/gpu/drm/scheduler/sched_main.c
+++ b/drivers/gpu/drm/scheduler/sched_main.c
@@ -1119,10 +1119,33 @@ EXPORT_SYMBOL(drm_sched_init);
void drm_sched_fini(struct drm_gpu_scheduler *sched)
{
struct drm_sched_entity *s_entity;
+ struct drm_sched_job *s_job, *tmp;
int i;
- if (sched->thread)
- kthread_stop(sched->thread);
+ if (!sched->thread)
+ return;
+
+ /*
+ * Stop the scheduler, detaching all jobs from their hardware callbacks
+ * and cleaning up complete jobs.
+ */
+ drm_sched_stop(sched, NULL);
+
+ /*
+ * Iterate through the pending job list and free all jobs.
+ * This assumes the driver has either guaranteed jobs are already stopped, or that
+ * otherwise it is responsible for keeping any necessary data structures for
+ * in-progress jobs alive even when the free_job() callback is called early (e.g. by
+ * putting them in its own queue or doing its own refcounting).
+ */
+ list_for_each_entry_safe(s_job, tmp, &sched->pending_list, list) {
+ spin_lock(&sched->job_list_lock);
+ list_del_init(&s_job->list);
+ spin_unlock(&sched->job_list_lock);
+ sched->ops->free_job(s_job);
+ }
+
+ kthread_stop(sched->thread);
for (i = DRM_SCHED_PRIORITY_COUNT - 1; i >= DRM_SCHED_PRIORITY_MIN; i--) {
struct drm_sched_rq *rq = &sched->sched_rq[i];
--
2.35.1
^ permalink raw reply related [flat|nested] 122+ messages in thread* Re: [PATCH RFC 11/18] drm/scheduler: Clean up jobs when the scheduler is torn down
2023-03-07 14:25 ` [PATCH RFC 11/18] drm/scheduler: Clean up jobs when the scheduler is torn down Asahi Lina
@ 2023-03-08 9:57 ` Maarten Lankhorst
2023-03-08 10:03 ` Christian König
2023-04-05 13:52 ` Daniel Vetter
1 sibling, 1 reply; 122+ messages in thread
From: Maarten Lankhorst @ 2023-03-08 9:57 UTC (permalink / raw)
To: Asahi Lina, Maxime Ripard, Thomas Zimmermann, David Airlie,
Daniel Vetter, Miguel Ojeda, Alex Gaynor, Wedson Almeida Filho,
Boqun Feng, Gary Guo, Björn Roy Baron, Sumit Semwal,
Christian König, Luben Tuikov, Jarkko Sakkinen, Dave Hansen
Cc: Alyssa Rosenzweig, Karol Herbst, Ella Stanforth, Faith Ekstrand,
Mary, linux-kernel, dri-devel, rust-for-linux, linux-media,
linaro-mm-sig, linux-sgx, asahi
On 2023-03-07 15:25, Asahi Lina wrote:
> drm_sched_fini() currently leaves any pending jobs dangling, which
> causes segfaults and other badness when job completion fences are
> signaled after the scheduler is torn down.
>
> Explicitly detach all jobs from their completion callbacks and free
> them. This makes it possible to write a sensible safe abstraction for
> drm_sched, without having to externally duplicate the tracking of
> in-flight jobs.
>
> This shouldn't regress any existing drivers, since calling
> drm_sched_fini() with any pending jobs is broken and this change should
> be a no-op if there are no pending jobs.
>
> Signed-off-by: Asahi Lina <lina@asahilina.net>
> ---
> drivers/gpu/drm/scheduler/sched_main.c | 27 +++++++++++++++++++++++++--
> 1 file changed, 25 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/scheduler/sched_main.c b/drivers/gpu/drm/scheduler/sched_main.c
> index 5c0add2c7546..0aab1e0aebdd 100644
> --- a/drivers/gpu/drm/scheduler/sched_main.c
> +++ b/drivers/gpu/drm/scheduler/sched_main.c
> @@ -1119,10 +1119,33 @@ EXPORT_SYMBOL(drm_sched_init);
> void drm_sched_fini(struct drm_gpu_scheduler *sched)
> {
> struct drm_sched_entity *s_entity;
> + struct drm_sched_job *s_job, *tmp;
> int i;
>
> - if (sched->thread)
> - kthread_stop(sched->thread);
> + if (!sched->thread)
> + return;
> +
> + /*
> + * Stop the scheduler, detaching all jobs from their hardware callbacks
> + * and cleaning up complete jobs.
> + */
> + drm_sched_stop(sched, NULL);
> +
> + /*
> + * Iterate through the pending job list and free all jobs.
> + * This assumes the driver has either guaranteed jobs are already stopped, or that
> + * otherwise it is responsible for keeping any necessary data structures for
> + * in-progress jobs alive even when the free_job() callback is called early (e.g. by
> + * putting them in its own queue or doing its own refcounting).
> + */
> + list_for_each_entry_safe(s_job, tmp, &sched->pending_list, list) {
> + spin_lock(&sched->job_list_lock);
> + list_del_init(&s_job->list);
> + spin_unlock(&sched->job_list_lock);
> + sched->ops->free_job(s_job);
> + }
I would stop the kthread first, then delete all jobs without spinlock
since nothing else can race against sched_fini?
If you do need the spinlock, It would need to guard list_for_each_entry too.
> +
> + kthread_stop(sched->thread);
>
> for (i = DRM_SCHED_PRIORITY_COUNT - 1; i >= DRM_SCHED_PRIORITY_MIN; i--) {
> struct drm_sched_rq *rq = &sched->sched_rq[i];
>
^ permalink raw reply [flat|nested] 122+ messages in thread* Re: [PATCH RFC 11/18] drm/scheduler: Clean up jobs when the scheduler is torn down
2023-03-08 9:57 ` Maarten Lankhorst
@ 2023-03-08 10:03 ` Christian König
2023-03-08 15:18 ` Asahi Lina
0 siblings, 1 reply; 122+ messages in thread
From: Christian König @ 2023-03-08 10:03 UTC (permalink / raw)
To: Maarten Lankhorst, Asahi Lina, Maxime Ripard, Thomas Zimmermann,
David Airlie, Daniel Vetter, Miguel Ojeda, Alex Gaynor,
Wedson Almeida Filho, Boqun Feng, Gary Guo, Björn Roy Baron,
Sumit Semwal, Luben Tuikov, Jarkko Sakkinen, Dave Hansen
Cc: Alyssa Rosenzweig, Karol Herbst, Ella Stanforth, Faith Ekstrand,
Mary, linux-kernel, dri-devel, rust-for-linux, linux-media,
linaro-mm-sig, linux-sgx, asahi
Am 08.03.23 um 10:57 schrieb Maarten Lankhorst:
>
> On 2023-03-07 15:25, Asahi Lina wrote:
>> drm_sched_fini() currently leaves any pending jobs dangling, which
>> causes segfaults and other badness when job completion fences are
>> signaled after the scheduler is torn down.
>>
>> Explicitly detach all jobs from their completion callbacks and free
>> them. This makes it possible to write a sensible safe abstraction for
>> drm_sched, without having to externally duplicate the tracking of
>> in-flight jobs.
>>
>> This shouldn't regress any existing drivers, since calling
>> drm_sched_fini() with any pending jobs is broken and this change should
>> be a no-op if there are no pending jobs.
>>
>> Signed-off-by: Asahi Lina <lina@asahilina.net>
>> ---
>> drivers/gpu/drm/scheduler/sched_main.c | 27
>> +++++++++++++++++++++++++--
>> 1 file changed, 25 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/scheduler/sched_main.c
>> b/drivers/gpu/drm/scheduler/sched_main.c
>> index 5c0add2c7546..0aab1e0aebdd 100644
>> --- a/drivers/gpu/drm/scheduler/sched_main.c
>> +++ b/drivers/gpu/drm/scheduler/sched_main.c
>> @@ -1119,10 +1119,33 @@ EXPORT_SYMBOL(drm_sched_init);
>> void drm_sched_fini(struct drm_gpu_scheduler *sched)
>> {
>> struct drm_sched_entity *s_entity;
>> + struct drm_sched_job *s_job, *tmp;
>> int i;
>> - if (sched->thread)
>> - kthread_stop(sched->thread);
>> + if (!sched->thread)
>> + return;
>> +
>> + /*
>> + * Stop the scheduler, detaching all jobs from their hardware
>> callbacks
>> + * and cleaning up complete jobs.
>> + */
>> + drm_sched_stop(sched, NULL);
>> +
>> + /*
>> + * Iterate through the pending job list and free all jobs.
>> + * This assumes the driver has either guaranteed jobs are
>> already stopped, or that
>> + * otherwise it is responsible for keeping any necessary data
>> structures for
>> + * in-progress jobs alive even when the free_job() callback is
>> called early (e.g. by
>> + * putting them in its own queue or doing its own refcounting).
>> + */
>> + list_for_each_entry_safe(s_job, tmp, &sched->pending_list, list) {
>> + spin_lock(&sched->job_list_lock);
>> + list_del_init(&s_job->list);
>> + spin_unlock(&sched->job_list_lock);
>> + sched->ops->free_job(s_job);
>> + }
>
> I would stop the kthread first, then delete all jobs without spinlock
> since nothing else can race against sched_fini?
>
> If you do need the spinlock, It would need to guard
> list_for_each_entry too.
Well this case here actually should not happen in the first place.
Jobs depend on their device, so as long as there are jobs there should
also be a reference to the scheduler.
What could be is that you have allocated a scheduler instance
dynamically, but even then you should first tear down all entities and
then the scheduler.
Regards,
Christian.
>
>> +
>> + kthread_stop(sched->thread);
>> for (i = DRM_SCHED_PRIORITY_COUNT - 1; i >=
>> DRM_SCHED_PRIORITY_MIN; i--) {
>> struct drm_sched_rq *rq = &sched->sched_rq[i];
>>
^ permalink raw reply [flat|nested] 122+ messages in thread* Re: [PATCH RFC 11/18] drm/scheduler: Clean up jobs when the scheduler is torn down
2023-03-08 10:03 ` Christian König
@ 2023-03-08 15:18 ` Asahi Lina
2023-03-08 15:42 ` Christian König
0 siblings, 1 reply; 122+ messages in thread
From: Asahi Lina @ 2023-03-08 15:18 UTC (permalink / raw)
To: Christian König, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Daniel Vetter, Miguel Ojeda,
Alex Gaynor, Wedson Almeida Filho, Boqun Feng, Gary Guo,
Björn Roy Baron, Sumit Semwal, Luben Tuikov,
Jarkko Sakkinen, Dave Hansen
Cc: Alyssa Rosenzweig, Karol Herbst, Ella Stanforth, Faith Ekstrand,
Mary, linux-kernel, dri-devel, rust-for-linux, linux-media,
linaro-mm-sig, linux-sgx, asahi
On 08/03/2023 19.03, Christian König wrote:
> Am 08.03.23 um 10:57 schrieb Maarten Lankhorst:
>>
>> On 2023-03-07 15:25, Asahi Lina wrote:
>>> drm_sched_fini() currently leaves any pending jobs dangling, which
>>> causes segfaults and other badness when job completion fences are
>>> signaled after the scheduler is torn down.
>>>
>>> Explicitly detach all jobs from their completion callbacks and free
>>> them. This makes it possible to write a sensible safe abstraction for
>>> drm_sched, without having to externally duplicate the tracking of
>>> in-flight jobs.
>>>
>>> This shouldn't regress any existing drivers, since calling
>>> drm_sched_fini() with any pending jobs is broken and this change should
>>> be a no-op if there are no pending jobs.
>>>
>>> Signed-off-by: Asahi Lina <lina@asahilina.net>
>>> ---
>>> drivers/gpu/drm/scheduler/sched_main.c | 27
>>> +++++++++++++++++++++++++--
>>> 1 file changed, 25 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/scheduler/sched_main.c
>>> b/drivers/gpu/drm/scheduler/sched_main.c
>>> index 5c0add2c7546..0aab1e0aebdd 100644
>>> --- a/drivers/gpu/drm/scheduler/sched_main.c
>>> +++ b/drivers/gpu/drm/scheduler/sched_main.c
>>> @@ -1119,10 +1119,33 @@ EXPORT_SYMBOL(drm_sched_init);
>>> void drm_sched_fini(struct drm_gpu_scheduler *sched)
>>> {
>>> struct drm_sched_entity *s_entity;
>>> + struct drm_sched_job *s_job, *tmp;
>>> int i;
>>> - if (sched->thread)
>>> - kthread_stop(sched->thread);
>>> + if (!sched->thread)
>>> + return;
>>> +
>>> + /*
>>> + * Stop the scheduler, detaching all jobs from their hardware
>>> callbacks
>>> + * and cleaning up complete jobs.
>>> + */
>>> + drm_sched_stop(sched, NULL);
>>> +
>>> + /*
>>> + * Iterate through the pending job list and free all jobs.
>>> + * This assumes the driver has either guaranteed jobs are
>>> already stopped, or that
>>> + * otherwise it is responsible for keeping any necessary data
>>> structures for
>>> + * in-progress jobs alive even when the free_job() callback is
>>> called early (e.g. by
>>> + * putting them in its own queue or doing its own refcounting).
>>> + */
>>> + list_for_each_entry_safe(s_job, tmp, &sched->pending_list, list) {
>>> + spin_lock(&sched->job_list_lock);
>>> + list_del_init(&s_job->list);
>>> + spin_unlock(&sched->job_list_lock);
>>> + sched->ops->free_job(s_job);
>>> + }
>>
>> I would stop the kthread first, then delete all jobs without spinlock
>> since nothing else can race against sched_fini?
>>
>> If you do need the spinlock, It would need to guard
>> list_for_each_entry too.
>
> Well this case here actually should not happen in the first place.
"This should not happen in the first place" is how you end up with C
APIs that have corner cases that lead to kernel oopses...
The idea with Rust abstractions is that it needs to be actually
impossible to create memory safety problems for the user of the
abstraction, you can't impose arbitrary constraints like "you must wait
for all jobs to finish before destroying the scheduler"... it needs to
be intrinsically safe.
> Jobs depend on their device, so as long as there are jobs there should
> also be a reference to the scheduler.
These schedulers are created dynamically per userspace queue. The memory
management and reference counting involved make it safe to destroy the
scheduler even when behind the scenes hardware jobs are still running,
as long as drm_sched itself doesn't crash on fences firing without a
scheduler (which is what this patch fixes).
This is the power of Rust: it forces you to architect your code in a way
that you don't have complex high-level dependencies that span the entire
driver and are difficult to prove hold. In my driver, you can kill a
process and that destroys the drm_sched, closes all GEM objects,
everything, even if the GPU is still running jobs from that process. The
worst that can happen is that the GPU faults as in-use userspace buffers
are unmapped out from under the running user job, but that's fine (GPU
faults are recoverable). The actual firmware resources, queues, etc. in
use are all kept alive until the commands finish executing (or fault,
which is just an abnormal completion), even if the userspace process
that owned them is long gone. I've tested this extensively by doing
things like large-resolution glmark runs in a loop that get `kill -9`'d
repeatedly, and it works very well! Tons of GPU faults but no firmware
crashes, no oopses, nothing. And the firmware *will* crash irrecoverably
if anything goes wrong with its shared memory structures, so that it
doesn't is pretty good evidence that all this works!
> What could be is that you have allocated a scheduler instance
> dynamically, but even then you should first tear down all entities and
> then the scheduler.
This is about creating a safe Rust abstraction, so we can't impose
requirements on users like that, the abstraction has to take care of it.
Unfortunately, the jobs cannot depend on the scheduler at the
abstraction level. I tried that (putting a reference counted reference
to the scheduler in the job abstraction), but it doesn't work because a
job completing can end up dropping the last reference to the scheduler,
and then you end up trying to stop and clean up the scheduler from a
callback called from the scheduler kthread itself, which deadlocks. We
could throw those cleanups into a workqueue or something, but that's
just adding bandages around the problem that the drm_sched interface
today is just not safe without this patch...
Right now, it is not possible to create a safe Rust abstraction for
drm_sched without doing something like duplicating all job tracking in
the abstraction, or the above backreference + deferred cleanup mess, or
something equally silly. So let's just fix the C side please ^^
So far, drm_sched is the only DRM API that has had such a fundamental
API safety issue that I had to make a change like this to the C to make
the Rust abstraction possible/reasonable... drm_sched has also been by
far the hardest DRM component API to understand from a safety point of
view, with the most inconsistent documentation about what the
ownership/freeing rules are, and what objects need to outlive what other
objects (I had to just read the code to figure most of this out). That's
also one nice outcome of writing Rust abstractions: it forces us to make
all these rules and invariants explicit, instead of leaving them as
unwritten assumptions (almost nobody consistently documents this in C
APIs...).
If I got it right, anyone using the Rust drm_sched abstraction doesn't
have to worry about this any more because if they do something that
would oops with it, their code won't compile. But I need this patch to
be able to make that guarantee...
~~ Lina
^ permalink raw reply [flat|nested] 122+ messages in thread* Re: [PATCH RFC 11/18] drm/scheduler: Clean up jobs when the scheduler is torn down
2023-03-08 15:18 ` Asahi Lina
@ 2023-03-08 15:42 ` Christian König
2023-03-08 17:32 ` Asahi Lina
2023-03-08 17:39 ` alyssa
0 siblings, 2 replies; 122+ messages in thread
From: Christian König @ 2023-03-08 15:42 UTC (permalink / raw)
To: Asahi Lina, Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
David Airlie, Daniel Vetter, Miguel Ojeda, Alex Gaynor,
Wedson Almeida Filho, Boqun Feng, Gary Guo, Björn Roy Baron,
Sumit Semwal, Luben Tuikov, Jarkko Sakkinen, Dave Hansen
Cc: Alyssa Rosenzweig, Karol Herbst, Ella Stanforth, Faith Ekstrand,
Mary, linux-kernel, dri-devel, rust-for-linux, linux-media,
linaro-mm-sig, linux-sgx, asahi
Am 08.03.23 um 16:18 schrieb Asahi Lina:
> On 08/03/2023 19.03, Christian König wrote:
>> Am 08.03.23 um 10:57 schrieb Maarten Lankhorst:
>>> On 2023-03-07 15:25, Asahi Lina wrote:
>>>> drm_sched_fini() currently leaves any pending jobs dangling, which
>>>> causes segfaults and other badness when job completion fences are
>>>> signaled after the scheduler is torn down.
>>>>
>>>> Explicitly detach all jobs from their completion callbacks and free
>>>> them. This makes it possible to write a sensible safe abstraction for
>>>> drm_sched, without having to externally duplicate the tracking of
>>>> in-flight jobs.
>>>>
>>>> This shouldn't regress any existing drivers, since calling
>>>> drm_sched_fini() with any pending jobs is broken and this change should
>>>> be a no-op if there are no pending jobs.
>>>>
>>>> Signed-off-by: Asahi Lina <lina@asahilina.net>
>>>> ---
>>>> drivers/gpu/drm/scheduler/sched_main.c | 27
>>>> +++++++++++++++++++++++++--
>>>> 1 file changed, 25 insertions(+), 2 deletions(-)
>>>>
>>>> diff --git a/drivers/gpu/drm/scheduler/sched_main.c
>>>> b/drivers/gpu/drm/scheduler/sched_main.c
>>>> index 5c0add2c7546..0aab1e0aebdd 100644
>>>> --- a/drivers/gpu/drm/scheduler/sched_main.c
>>>> +++ b/drivers/gpu/drm/scheduler/sched_main.c
>>>> @@ -1119,10 +1119,33 @@ EXPORT_SYMBOL(drm_sched_init);
>>>> void drm_sched_fini(struct drm_gpu_scheduler *sched)
>>>> {
>>>> struct drm_sched_entity *s_entity;
>>>> + struct drm_sched_job *s_job, *tmp;
>>>> int i;
>>>> - if (sched->thread)
>>>> - kthread_stop(sched->thread);
>>>> + if (!sched->thread)
>>>> + return;
>>>> +
>>>> + /*
>>>> + * Stop the scheduler, detaching all jobs from their hardware
>>>> callbacks
>>>> + * and cleaning up complete jobs.
>>>> + */
>>>> + drm_sched_stop(sched, NULL);
>>>> +
>>>> + /*
>>>> + * Iterate through the pending job list and free all jobs.
>>>> + * This assumes the driver has either guaranteed jobs are
>>>> already stopped, or that
>>>> + * otherwise it is responsible for keeping any necessary data
>>>> structures for
>>>> + * in-progress jobs alive even when the free_job() callback is
>>>> called early (e.g. by
>>>> + * putting them in its own queue or doing its own refcounting).
>>>> + */
>>>> + list_for_each_entry_safe(s_job, tmp, &sched->pending_list, list) {
>>>> + spin_lock(&sched->job_list_lock);
>>>> + list_del_init(&s_job->list);
>>>> + spin_unlock(&sched->job_list_lock);
>>>> + sched->ops->free_job(s_job);
>>>> + }
>>> I would stop the kthread first, then delete all jobs without spinlock
>>> since nothing else can race against sched_fini?
>>>
>>> If you do need the spinlock, It would need to guard
>>> list_for_each_entry too.
>> Well this case here actually should not happen in the first place.
> "This should not happen in the first place" is how you end up with C
> APIs that have corner cases that lead to kernel oopses...
>
> The idea with Rust abstractions is that it needs to be actually
> impossible to create memory safety problems for the user of the
> abstraction, you can't impose arbitrary constraints like "you must wait
> for all jobs to finish before destroying the scheduler"... it needs to
> be intrinsically safe.
>
>> Jobs depend on their device, so as long as there are jobs there should
>> also be a reference to the scheduler.
> These schedulers are created dynamically per userspace queue. The memory
> management and reference counting involved make it safe to destroy the
> scheduler even when behind the scenes hardware jobs are still running,
> as long as drm_sched itself doesn't crash on fences firing without a
> scheduler (which is what this patch fixes).
We have originally rejected that approach, but I still think it might
work if done right.
> This is the power of Rust: it forces you to architect your code in a way
> that you don't have complex high-level dependencies that span the entire
> driver and are difficult to prove hold. In my driver, you can kill a
> process and that destroys the drm_sched, closes all GEM objects,
> everything, even if the GPU is still running jobs from that process. The
> worst that can happen is that the GPU faults as in-use userspace buffers
> are unmapped out from under the running user job, but that's fine (GPU
> faults are recoverable). The actual firmware resources, queues, etc. in
> use are all kept alive until the commands finish executing (or fault,
> which is just an abnormal completion), even if the userspace process
> that owned them is long gone. I've tested this extensively by doing
> things like large-resolution glmark runs in a loop that get `kill -9`'d
> repeatedly, and it works very well! Tons of GPU faults but no firmware
> crashes, no oopses, nothing. And the firmware *will* crash irrecoverably
> if anything goes wrong with its shared memory structures, so that it
> doesn't is pretty good evidence that all this works!
Well testing is no prove at all of a correct design.
>> What could be is that you have allocated a scheduler instance
>> dynamically, but even then you should first tear down all entities and
>> then the scheduler.
> This is about creating a safe Rust abstraction, so we can't impose
> requirements on users like that, the abstraction has to take care of it.
> Unfortunately, the jobs cannot depend on the scheduler at the
> abstraction level. I tried that (putting a reference counted reference
> to the scheduler in the job abstraction), but it doesn't work because a
> job completing can end up dropping the last reference to the scheduler,
> and then you end up trying to stop and clean up the scheduler from a
> callback called from the scheduler kthread itself, which deadlocks. We
> could throw those cleanups into a workqueue or something, but that's
> just adding bandages around the problem that the drm_sched interface
> today is just not safe without this patch...
Well that won't work like this. The scheduler has a pretty clear tear
down procedure.
And that procedure implies that all entities which might provide jobs
are destroyed before the scheduler is destroyed.
Destroying the entities in turn cleans up the pending jobs inside of
them. We could add a warning when users of this API doesn't do this
correctly, but cleaning up incorrect API use is clearly something we
don't want here.
> Right now, it is not possible to create a safe Rust abstraction for
> drm_sched without doing something like duplicating all job tracking in
> the abstraction, or the above backreference + deferred cleanup mess, or
> something equally silly. So let's just fix the C side please ^^
Nope, as far as I can see this is just not correctly tearing down the
objects in the right order.
So you are trying to do something which is not supposed to work in the
first place.
Regards,
Christian.
>
> So far, drm_sched is the only DRM API that has had such a fundamental
> API safety issue that I had to make a change like this to the C to make
> the Rust abstraction possible/reasonable... drm_sched has also been by
> far the hardest DRM component API to understand from a safety point of
> view, with the most inconsistent documentation about what the
> ownership/freeing rules are, and what objects need to outlive what other
> objects (I had to just read the code to figure most of this out). That's
> also one nice outcome of writing Rust abstractions: it forces us to make
> all these rules and invariants explicit, instead of leaving them as
> unwritten assumptions (almost nobody consistently documents this in C
> APIs...).
>
> If I got it right, anyone using the Rust drm_sched abstraction doesn't
> have to worry about this any more because if they do something that
> would oops with it, their code won't compile. But I need this patch to
> be able to make that guarantee...
>
> ~~ Lina
^ permalink raw reply [flat|nested] 122+ messages in thread* Re: [PATCH RFC 11/18] drm/scheduler: Clean up jobs when the scheduler is torn down
2023-03-08 15:42 ` Christian König
@ 2023-03-08 17:32 ` Asahi Lina
2023-03-08 18:12 ` Christian König
2023-03-08 17:39 ` alyssa
1 sibling, 1 reply; 122+ messages in thread
From: Asahi Lina @ 2023-03-08 17:32 UTC (permalink / raw)
To: Christian König, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Daniel Vetter, Miguel Ojeda,
Alex Gaynor, Wedson Almeida Filho, Boqun Feng, Gary Guo,
Björn Roy Baron, Sumit Semwal, Luben Tuikov,
Jarkko Sakkinen, Dave Hansen
Cc: Alyssa Rosenzweig, Karol Herbst, Ella Stanforth, Faith Ekstrand,
Mary, linux-kernel, dri-devel, rust-for-linux, linux-media,
linaro-mm-sig, linux-sgx, asahi
On 09/03/2023 00.42, Christian König wrote:
> Am 08.03.23 um 16:18 schrieb Asahi Lina:
>> On 08/03/2023 19.03, Christian König wrote:
>>> Am 08.03.23 um 10:57 schrieb Maarten Lankhorst:
>>>> On 2023-03-07 15:25, Asahi Lina wrote:
>>>>> drm_sched_fini() currently leaves any pending jobs dangling, which
>>>>> causes segfaults and other badness when job completion fences are
>>>>> signaled after the scheduler is torn down.
>>>>>
>>>>> Explicitly detach all jobs from their completion callbacks and free
>>>>> them. This makes it possible to write a sensible safe abstraction for
>>>>> drm_sched, without having to externally duplicate the tracking of
>>>>> in-flight jobs.
>>>>>
>>>>> This shouldn't regress any existing drivers, since calling
>>>>> drm_sched_fini() with any pending jobs is broken and this change should
>>>>> be a no-op if there are no pending jobs.
>>>>>
>>>>> Signed-off-by: Asahi Lina <lina@asahilina.net>
>>>>> ---
>>>>> drivers/gpu/drm/scheduler/sched_main.c | 27
>>>>> +++++++++++++++++++++++++--
>>>>> 1 file changed, 25 insertions(+), 2 deletions(-)
>>>>>
>>>>> diff --git a/drivers/gpu/drm/scheduler/sched_main.c
>>>>> b/drivers/gpu/drm/scheduler/sched_main.c
>>>>> index 5c0add2c7546..0aab1e0aebdd 100644
>>>>> --- a/drivers/gpu/drm/scheduler/sched_main.c
>>>>> +++ b/drivers/gpu/drm/scheduler/sched_main.c
>>>>> @@ -1119,10 +1119,33 @@ EXPORT_SYMBOL(drm_sched_init);
>>>>> void drm_sched_fini(struct drm_gpu_scheduler *sched)
>>>>> {
>>>>> struct drm_sched_entity *s_entity;
>>>>> + struct drm_sched_job *s_job, *tmp;
>>>>> int i;
>>>>> - if (sched->thread)
>>>>> - kthread_stop(sched->thread);
>>>>> + if (!sched->thread)
>>>>> + return;
>>>>> +
>>>>> + /*
>>>>> + * Stop the scheduler, detaching all jobs from their hardware
>>>>> callbacks
>>>>> + * and cleaning up complete jobs.
>>>>> + */
>>>>> + drm_sched_stop(sched, NULL);
>>>>> +
>>>>> + /*
>>>>> + * Iterate through the pending job list and free all jobs.
>>>>> + * This assumes the driver has either guaranteed jobs are
>>>>> already stopped, or that
>>>>> + * otherwise it is responsible for keeping any necessary data
>>>>> structures for
>>>>> + * in-progress jobs alive even when the free_job() callback is
>>>>> called early (e.g. by
>>>>> + * putting them in its own queue or doing its own refcounting).
>>>>> + */
>>>>> + list_for_each_entry_safe(s_job, tmp, &sched->pending_list, list) {
>>>>> + spin_lock(&sched->job_list_lock);
>>>>> + list_del_init(&s_job->list);
>>>>> + spin_unlock(&sched->job_list_lock);
>>>>> + sched->ops->free_job(s_job);
>>>>> + }
>>>> I would stop the kthread first, then delete all jobs without spinlock
>>>> since nothing else can race against sched_fini?
>>>>
>>>> If you do need the spinlock, It would need to guard
>>>> list_for_each_entry too.
>>> Well this case here actually should not happen in the first place.
>> "This should not happen in the first place" is how you end up with C
>> APIs that have corner cases that lead to kernel oopses...
>>
>> The idea with Rust abstractions is that it needs to be actually
>> impossible to create memory safety problems for the user of the
>> abstraction, you can't impose arbitrary constraints like "you must wait
>> for all jobs to finish before destroying the scheduler"... it needs to
>> be intrinsically safe.
>>
>>> Jobs depend on their device, so as long as there are jobs there should
>>> also be a reference to the scheduler.
>> These schedulers are created dynamically per userspace queue. The memory
>> management and reference counting involved make it safe to destroy the
>> scheduler even when behind the scenes hardware jobs are still running,
>> as long as drm_sched itself doesn't crash on fences firing without a
>> scheduler (which is what this patch fixes).
>
> We have originally rejected that approach, but I still think it might
> work if done right.
>
>> This is the power of Rust: it forces you to architect your code in a way
>> that you don't have complex high-level dependencies that span the entire
>> driver and are difficult to prove hold. In my driver, you can kill a
>> process and that destroys the drm_sched, closes all GEM objects,
>> everything, even if the GPU is still running jobs from that process. The
>> worst that can happen is that the GPU faults as in-use userspace buffers
>> are unmapped out from under the running user job, but that's fine (GPU
>> faults are recoverable). The actual firmware resources, queues, etc. in
>> use are all kept alive until the commands finish executing (or fault,
>> which is just an abnormal completion), even if the userspace process
>> that owned them is long gone. I've tested this extensively by doing
>> things like large-resolution glmark runs in a loop that get `kill -9`'d
>> repeatedly, and it works very well! Tons of GPU faults but no firmware
>> crashes, no oopses, nothing. And the firmware *will* crash irrecoverably
>> if anything goes wrong with its shared memory structures, so that it
>> doesn't is pretty good evidence that all this works!
>
> Well testing is no prove at all of a correct design.
Well, I'm guessing you don't have a formal correctness proof for amdgpu
either... ^^
There's actually no way to prove my design is correct, since this is a
reverse engineered driver that talks to proprietary firmware and I don't
have the benefit of both open and internal docs like you AMD people
have, never mind access to firmware source code... all I can do is try
to understand how it should work based on how macOS does things and
running tests, and then design something that should work with it. I
spent months writing a prototype Python driver before even starting on
the real DRM driver (long story...), and I keep going back to it to test
little details of the firmware interface. There's over 3300 lines of
just firmware structure definitions, it's kind of crazy...
But even with all that... this driver has no right to be as stable as it
is, considering I wrote it in just a few months. It hasn't even been a
year since I started working on AGX at all! As I mentioned in the cover
letter, we've gotten zero reports of oopses in production. I tried
fuzzing the UAPI and all I managed to do was crash the firmware after a
lot of GPU faults (that was a subtle firmware data cache coherency
issue, now fixed), the driver itself was fine. I didn't have to debug
the OOM error codepaths when we first started running Xonotic on 8GB RAM
machines with no texture compression support on high quality texture
settings (bad combination...), it all just worked even though all those
error/cleanup paths had never been tested before at all. The only memory
leaks I managed to cause were due to circular references between VMs and
GEM objects (tricky to avoid, I did manage to miss one special case
object in the first driver release...), everything else just cleans
itself up by design. And it's not because I'm a genius or anything like
that... it's because Rust just makes getting all this right *so* much
easier than C.
So I can at least say I'm quite confident that, as long as my
understanding of the firmware structure lifetimes is correct and I
encode it in the Rust object model the driver uses to represent them,
things will work without crashing without relying on high-level
invariants like "you must wait for all job completions before tearing
down the top-level scheduler for a user queue" ^^
>>> What could be is that you have allocated a scheduler instance
>>> dynamically, but even then you should first tear down all entities and
>>> then the scheduler.
>> This is about creating a safe Rust abstraction, so we can't impose
>> requirements on users like that, the abstraction has to take care of it.
>> Unfortunately, the jobs cannot depend on the scheduler at the
>> abstraction level. I tried that (putting a reference counted reference
>> to the scheduler in the job abstraction), but it doesn't work because a
>> job completing can end up dropping the last reference to the scheduler,
>> and then you end up trying to stop and clean up the scheduler from a
>> callback called from the scheduler kthread itself, which deadlocks. We
>> could throw those cleanups into a workqueue or something, but that's
>> just adding bandages around the problem that the drm_sched interface
>> today is just not safe without this patch...
>
> Well that won't work like this. The scheduler has a pretty clear tear
> down procedure.
Well... I wouldn't call it "clear". I had to reverse engineer this from
reading drm_sched source code, the docs don't tell you. The entire
documentation of "drm_sched_fini()" is as follows:
"Tears down and cleans up the scheduler."
That's it.
This is why I had so much trouble writing this abstraction, and I spent
hours reading the drm_sched code to understand how it worked in order to
use the API correctly... and yet...
>
> And that procedure implies that all entities which might provide jobs
> are destroyed before the scheduler is destroyed.
Yes, I do this: the entity abstraction holds a reference to the
scheduler for this reason, so the scheduler can only be destroyed once
all entities are destroyed. But...
> Destroying the entities in turn cleans up the pending jobs inside of
> them.
Yes but... none of this cleans up jobs that are already submitted by the
scheduler and in its pending list, with registered completion callbacks,
which were already popped off of the entities.
*That* is the problem this patch fixes!
> We could add a warning when users of this API doesn't do this
> correctly, but cleaning up incorrect API use is clearly something we
> don't want here.
It is the job of the Rust abstractions to make incorrect API use that
leads to memory unsafety impossible. So even if you don't want that in
C, it's my job to do that for Rust... and right now, I just can't
because drm_sched doesn't provide an API that can be safely wrapped
without weird bits of babysitting functionality on top (like tracking
jobs outside or awkwardly making jobs hold a reference to the scheduler
and defer dropping it to another thread).
>> Right now, it is not possible to create a safe Rust abstraction for
>> drm_sched without doing something like duplicating all job tracking in
>> the abstraction, or the above backreference + deferred cleanup mess, or
>> something equally silly. So let's just fix the C side please ^^
>
> Nope, as far as I can see this is just not correctly tearing down the
> objects in the right order.
There's no API to clean up in-flight jobs in a drm_sched at all.
Destroying an entity won't do it. So there is no reasonable way to do
this at all...
> So you are trying to do something which is not supposed to work in the
> first place.
I need to make things that aren't supposed to work impossible to do in
the first place, or at least fail gracefully instead of just oopsing
like drm_sched does today...
If you're convinced there's a way to do this, can you tell me exactly
what code sequence I need to run to safely shut down a scheduler
assuming all entities are already destroyed? You can't ask me for a list
of pending jobs (the scheduler knows this, it doesn't make any sense to
duplicate that outside), and you can't ask me to just not do this until
all jobs complete execution (because then we either end up with the
messy deadlock situation I described if I take a reference, or more
duplicative in-flight job count tracking and blocking in the free path
of the Rust abstraction, which doesn't make any sense either).
~~ Lina
^ permalink raw reply [flat|nested] 122+ messages in thread* Re: [PATCH RFC 11/18] drm/scheduler: Clean up jobs when the scheduler is torn down
2023-03-08 17:32 ` Asahi Lina
@ 2023-03-08 18:12 ` Christian König
2023-03-08 19:37 ` Asahi Lina
0 siblings, 1 reply; 122+ messages in thread
From: Christian König @ 2023-03-08 18:12 UTC (permalink / raw)
To: Asahi Lina, Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
David Airlie, Daniel Vetter, Miguel Ojeda, Alex Gaynor,
Wedson Almeida Filho, Boqun Feng, Gary Guo, Björn Roy Baron,
Sumit Semwal, Luben Tuikov, Jarkko Sakkinen, Dave Hansen
Cc: Alyssa Rosenzweig, Karol Herbst, Ella Stanforth, Faith Ekstrand,
Mary, linux-kernel, dri-devel, rust-for-linux, linux-media,
linaro-mm-sig, linux-sgx, asahi
Am 08.03.23 um 18:32 schrieb Asahi Lina:
> [SNIP]
> Yes but... none of this cleans up jobs that are already submitted by the
> scheduler and in its pending list, with registered completion callbacks,
> which were already popped off of the entities.
>
> *That* is the problem this patch fixes!
Ah! Yes that makes more sense now.
>> We could add a warning when users of this API doesn't do this
>> correctly, but cleaning up incorrect API use is clearly something we
>> don't want here.
> It is the job of the Rust abstractions to make incorrect API use that
> leads to memory unsafety impossible. So even if you don't want that in
> C, it's my job to do that for Rust... and right now, I just can't
> because drm_sched doesn't provide an API that can be safely wrapped
> without weird bits of babysitting functionality on top (like tracking
> jobs outside or awkwardly making jobs hold a reference to the scheduler
> and defer dropping it to another thread).
Yeah, that was discussed before but rejected.
The argument was that upper layer needs to wait for the hw to become
idle before the scheduler can be destroyed anyway.
>>> Right now, it is not possible to create a safe Rust abstraction for
>>> drm_sched without doing something like duplicating all job tracking in
>>> the abstraction, or the above backreference + deferred cleanup mess, or
>>> something equally silly. So let's just fix the C side please ^^
>> Nope, as far as I can see this is just not correctly tearing down the
>> objects in the right order.
> There's no API to clean up in-flight jobs in a drm_sched at all.
> Destroying an entity won't do it. So there is no reasonable way to do
> this at all...
Yes, this was removed.
>> So you are trying to do something which is not supposed to work in the
>> first place.
> I need to make things that aren't supposed to work impossible to do in
> the first place, or at least fail gracefully instead of just oopsing
> like drm_sched does today...
>
> If you're convinced there's a way to do this, can you tell me exactly
> what code sequence I need to run to safely shut down a scheduler
> assuming all entities are already destroyed? You can't ask me for a list
> of pending jobs (the scheduler knows this, it doesn't make any sense to
> duplicate that outside), and you can't ask me to just not do this until
> all jobs complete execution (because then we either end up with the
> messy deadlock situation I described if I take a reference, or more
> duplicative in-flight job count tracking and blocking in the free path
> of the Rust abstraction, which doesn't make any sense either).
Good question. We don't have anybody upstream which uses the scheduler
lifetime like this.
Essentially the job list in the scheduler is something we wanted to
remove because it causes tons of race conditions during hw recovery.
When you tear down the firmware queue how do you handle already
submitted jobs there?
Regards,
Christian.
>
> ~~ Lina
^ permalink raw reply [flat|nested] 122+ messages in thread
* Re: [PATCH RFC 11/18] drm/scheduler: Clean up jobs when the scheduler is torn down
2023-03-08 18:12 ` Christian König
@ 2023-03-08 19:37 ` Asahi Lina
2023-03-09 8:42 ` Christian König
0 siblings, 1 reply; 122+ messages in thread
From: Asahi Lina @ 2023-03-08 19:37 UTC (permalink / raw)
To: Christian König, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Daniel Vetter, Miguel Ojeda,
Alex Gaynor, Wedson Almeida Filho, Boqun Feng, Gary Guo,
Björn Roy Baron, Sumit Semwal, Luben Tuikov,
Jarkko Sakkinen, Dave Hansen
Cc: Alyssa Rosenzweig, Karol Herbst, Ella Stanforth, Faith Ekstrand,
Mary, linux-kernel, dri-devel, rust-for-linux, linux-media,
linaro-mm-sig, linux-sgx, asahi
On 09/03/2023 03.12, Christian König wrote:
> Am 08.03.23 um 18:32 schrieb Asahi Lina:
>> [SNIP]
>> Yes but... none of this cleans up jobs that are already submitted by the
>> scheduler and in its pending list, with registered completion callbacks,
>> which were already popped off of the entities.
>>
>> *That* is the problem this patch fixes!
>
> Ah! Yes that makes more sense now.
>
>>> We could add a warning when users of this API doesn't do this
>>> correctly, but cleaning up incorrect API use is clearly something we
>>> don't want here.
>> It is the job of the Rust abstractions to make incorrect API use that
>> leads to memory unsafety impossible. So even if you don't want that in
>> C, it's my job to do that for Rust... and right now, I just can't
>> because drm_sched doesn't provide an API that can be safely wrapped
>> without weird bits of babysitting functionality on top (like tracking
>> jobs outside or awkwardly making jobs hold a reference to the scheduler
>> and defer dropping it to another thread).
>
> Yeah, that was discussed before but rejected.
>
> The argument was that upper layer needs to wait for the hw to become
> idle before the scheduler can be destroyed anyway.
Unfortunately, that's not a requirement you can encode in the Rust type
system easily as far as I know, and Rust safety rules mean we need to
make it safe even if the upper layer doesn't do this... (or else we have
to mark the entire drm_sched abstraction unsafe, but that would be a pity).
I know it's a different way of thinking, but it has pretty clear
benefits since with Rust you can actually guarantee that things are safe
overall by just auditing explicitly unsafe code. If we just mark all of
drm_sched unsafe, that means we now need to audit all details about how
the driver uses it for safety. It makes more sense to just make the
abstraction safe, which is much easier to audit.
>>>> Right now, it is not possible to create a safe Rust abstraction for
>>>> drm_sched without doing something like duplicating all job tracking in
>>>> the abstraction, or the above backreference + deferred cleanup mess, or
>>>> something equally silly. So let's just fix the C side please ^^
>>> Nope, as far as I can see this is just not correctly tearing down the
>>> objects in the right order.
>> There's no API to clean up in-flight jobs in a drm_sched at all.
>> Destroying an entity won't do it. So there is no reasonable way to do
>> this at all...
>
> Yes, this was removed.
>
>>> So you are trying to do something which is not supposed to work in the
>>> first place.
>> I need to make things that aren't supposed to work impossible to do in
>> the first place, or at least fail gracefully instead of just oopsing
>> like drm_sched does today...
>>
>> If you're convinced there's a way to do this, can you tell me exactly
>> what code sequence I need to run to safely shut down a scheduler
>> assuming all entities are already destroyed? You can't ask me for a list
>> of pending jobs (the scheduler knows this, it doesn't make any sense to
>> duplicate that outside), and you can't ask me to just not do this until
>> all jobs complete execution (because then we either end up with the
>> messy deadlock situation I described if I take a reference, or more
>> duplicative in-flight job count tracking and blocking in the free path
>> of the Rust abstraction, which doesn't make any sense either).
>
> Good question. We don't have anybody upstream which uses the scheduler
> lifetime like this.
>
> Essentially the job list in the scheduler is something we wanted to
> remove because it causes tons of race conditions during hw recovery.
>
> When you tear down the firmware queue how do you handle already
> submitted jobs there?
The firmware queue is itself reference counted and any firmware queue
that has acquired an event notification resource (that is, which is busy
with running or upcoming jobs) hands off a reference to itself into the
event subsystem, so it can get notified of job completions by the
firmware. Then once it becomes idle it unregisters itself, and at that
point if it has no owning userspace queue, that would be the last
reference and it gets dropped. So we don't tear down firmware queues
until they are idle.
(There is a subtle deadlock break in the event module to make this work
out, where we clone a reference to the queue and drop the event
subsystem lock before signaling it of completions, so it can call back
in and take the lock as it unregisters itself if needed. Then the actual
teardown happens when the signaling is complete and that reference clone
is the last one to get dropped.)
If a queue is idle at the firmware level but has upcoming jobs queued in
drm_sched, when those get deleted as part of an explicit drm_sched
teardown (free_job()) the queue notices it lost its upcoming jobs and
relinquishes the event resource if there are no running jobs. I'm not
even sure exactly what order this all happens in in practice (it depends
on structure field order in Rust!), but it doesn't really matter because
either way everything gets cleaned up one way or another.
I actually don't know of any way to actively abort jobs on the firmware,
so this is pretty much the only option I have. I've even seen
long-running compute jobs on macOS run to completion even if you kill
the submitting process, so there might be no way to do this at all.
Though in practice since we unmap everything from the VM anyway when the
userspace stuff gets torn down, almost any normal GPU work is going to
immediately fault at that point (macOS doesn't do this because macOS
effectively does implicit sync with BO tracking at the kernel level...).
By the way, I don't really use the hardware recovery stuff right now.
I'm not even sure if there is a sensible way I could use it, since as I
said we can't exactly abort jobs. I know there are ways to lock up the
firmware/GPU, but so far those have all been things the kernel driver
can prevent, and I'm not even sure if there is any way to recover from
that anyway. The firmware itself has its own timeouts and recovery for
"normal" problems. From the point of view of the driver and everything
above it, in-flight commands during a GPU fault or timeout are just
marked complete by the firmware, after a firmware recovery cycle where
the driver gets notified of the problem (that's when we mark the
commands failed so we can propagate the error). There is no
re-submission or anything, userspace just gets told of the problem but
the queue survives. In the future it might be possible to re-submit
innocent commands (it is possible for a GPU fault to break another
process running concurrently, and this is a problem macOS has too...),
which is still not perfect due to side effects but might work most of
the time, but that depends on the "command patching" stuff I mentioned,
and I'm still not even sure if it will be possible to do safely. There's
a lot of subtlety around what we can and can't do during a firmware
recovery cycle that I haven't even started to investigate yet (the
answer could be "nothing" even).
~~ Lina
^ permalink raw reply [flat|nested] 122+ messages in thread
* Re: [PATCH RFC 11/18] drm/scheduler: Clean up jobs when the scheduler is torn down
2023-03-08 19:37 ` Asahi Lina
@ 2023-03-09 8:42 ` Christian König
2023-03-09 9:43 ` Asahi Lina
0 siblings, 1 reply; 122+ messages in thread
From: Christian König @ 2023-03-09 8:42 UTC (permalink / raw)
To: Asahi Lina, Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
David Airlie, Daniel Vetter, Miguel Ojeda, Alex Gaynor,
Wedson Almeida Filho, Boqun Feng, Gary Guo, Björn Roy Baron,
Sumit Semwal, Luben Tuikov, Jarkko Sakkinen, Dave Hansen
Cc: Alyssa Rosenzweig, Karol Herbst, Ella Stanforth, Faith Ekstrand,
Mary, linux-kernel, dri-devel, rust-for-linux, linux-media,
linaro-mm-sig, linux-sgx, asahi
Am 08.03.23 um 20:37 schrieb Asahi Lina:
> On 09/03/2023 03.12, Christian König wrote:
>> Am 08.03.23 um 18:32 schrieb Asahi Lina:
>>> [SNIP]
>>> Yes but... none of this cleans up jobs that are already submitted by the
>>> scheduler and in its pending list, with registered completion callbacks,
>>> which were already popped off of the entities.
>>>
>>> *That* is the problem this patch fixes!
>> Ah! Yes that makes more sense now.
>>
>>>> We could add a warning when users of this API doesn't do this
>>>> correctly, but cleaning up incorrect API use is clearly something we
>>>> don't want here.
>>> It is the job of the Rust abstractions to make incorrect API use that
>>> leads to memory unsafety impossible. So even if you don't want that in
>>> C, it's my job to do that for Rust... and right now, I just can't
>>> because drm_sched doesn't provide an API that can be safely wrapped
>>> without weird bits of babysitting functionality on top (like tracking
>>> jobs outside or awkwardly making jobs hold a reference to the scheduler
>>> and defer dropping it to another thread).
>> Yeah, that was discussed before but rejected.
>>
>> The argument was that upper layer needs to wait for the hw to become
>> idle before the scheduler can be destroyed anyway.
> Unfortunately, that's not a requirement you can encode in the Rust type
> system easily as far as I know, and Rust safety rules mean we need to
> make it safe even if the upper layer doesn't do this... (or else we have
> to mark the entire drm_sched abstraction unsafe, but that would be a pity).
Yeah, that should really not be something we should do.
But you could make the scheduler depend on your fw context object, don't
you?
Detaching the scheduler from the underlying hw fences is certainly
possible, but we removed that functionality because some people people
tried to force push some Windows recovery module into Linux. We are in
the process of reverting that and cleaning things up once more, but that
will take a while.
Instead of detaching you could also block for the hw to become idle, but
if you do that synchronous on process termination you run into trouble
as well.
> I know it's a different way of thinking, but it has pretty clear
> benefits since with Rust you can actually guarantee that things are safe
> overall by just auditing explicitly unsafe code. If we just mark all of
> drm_sched unsafe, that means we now need to audit all details about how
> the driver uses it for safety. It makes more sense to just make the
> abstraction safe, which is much easier to audit.
I'm pretty familiar with that approach.
>
>>>>> Right now, it is not possible to create a safe Rust abstraction for
>>>>> drm_sched without doing something like duplicating all job tracking in
>>>>> the abstraction, or the above backreference + deferred cleanup mess, or
>>>>> something equally silly. So let's just fix the C side please ^^
>>>> Nope, as far as I can see this is just not correctly tearing down the
>>>> objects in the right order.
>>> There's no API to clean up in-flight jobs in a drm_sched at all.
>>> Destroying an entity won't do it. So there is no reasonable way to do
>>> this at all...
>> Yes, this was removed.
>>
>>>> So you are trying to do something which is not supposed to work in the
>>>> first place.
>>> I need to make things that aren't supposed to work impossible to do in
>>> the first place, or at least fail gracefully instead of just oopsing
>>> like drm_sched does today...
>>>
>>> If you're convinced there's a way to do this, can you tell me exactly
>>> what code sequence I need to run to safely shut down a scheduler
>>> assuming all entities are already destroyed? You can't ask me for a list
>>> of pending jobs (the scheduler knows this, it doesn't make any sense to
>>> duplicate that outside), and you can't ask me to just not do this until
>>> all jobs complete execution (because then we either end up with the
>>> messy deadlock situation I described if I take a reference, or more
>>> duplicative in-flight job count tracking and blocking in the free path
>>> of the Rust abstraction, which doesn't make any sense either).
>> Good question. We don't have anybody upstream which uses the scheduler
>> lifetime like this.
>>
>> Essentially the job list in the scheduler is something we wanted to
>> remove because it causes tons of race conditions during hw recovery.
>>
>> When you tear down the firmware queue how do you handle already
>> submitted jobs there?
> The firmware queue is itself reference counted and any firmware queue
> that has acquired an event notification resource (that is, which is busy
> with running or upcoming jobs) hands off a reference to itself into the
> event subsystem, so it can get notified of job completions by the
> firmware. Then once it becomes idle it unregisters itself, and at that
> point if it has no owning userspace queue, that would be the last
> reference and it gets dropped. So we don't tear down firmware queues
> until they are idle.
And could those fw queue not reference the scheduler?
>
> (There is a subtle deadlock break in the event module to make this work
> out, where we clone a reference to the queue and drop the event
> subsystem lock before signaling it of completions, so it can call back
> in and take the lock as it unregisters itself if needed. Then the actual
> teardown happens when the signaling is complete and that reference clone
> is the last one to get dropped.)
>
> If a queue is idle at the firmware level but has upcoming jobs queued in
> drm_sched, when those get deleted as part of an explicit drm_sched
> teardown (free_job()) the queue notices it lost its upcoming jobs and
> relinquishes the event resource if there are no running jobs. I'm not
> even sure exactly what order this all happens in in practice (it depends
> on structure field order in Rust!), but it doesn't really matter because
> either way everything gets cleaned up one way or another.
>
> I actually don't know of any way to actively abort jobs on the firmware,
> so this is pretty much the only option I have. I've even seen
> long-running compute jobs on macOS run to completion even if you kill
> the submitting process, so there might be no way to do this at all.
> Though in practice since we unmap everything from the VM anyway when the
> userspace stuff gets torn down, almost any normal GPU work is going to
> immediately fault at that point (macOS doesn't do this because macOS
> effectively does implicit sync with BO tracking at the kernel level...).
Oh, that is an interesting information. How does macOS do explicit sync
then or isn't that supported at all?
> By the way, I don't really use the hardware recovery stuff right now.
> I'm not even sure if there is a sensible way I could use it, since as I
> said we can't exactly abort jobs. I know there are ways to lock up the
> firmware/GPU, but so far those have all been things the kernel driver
> can prevent, and I'm not even sure if there is any way to recover from
> that anyway. The firmware itself has its own timeouts and recovery for
> "normal" problems. From the point of view of the driver and everything
> above it, in-flight commands during a GPU fault or timeout are just
> marked complete by the firmware, after a firmware recovery cycle where
> the driver gets notified of the problem (that's when we mark the
> commands failed so we can propagate the error).
Yeah, that's exactly what we are telling our fw people for years that we
need this as well.
> There is no re-submission or anything, userspace just gets told of the problem but
> the queue survives.
> In the future it might be possible to re-submit innocent commands
Long story short: Don't do this! This is what the Windows drivers have
been doing and it creates tons of problems.
Just signal the problem back to userspace and let the user space driver
decide what to do.
The background is that most graphics applications (games etc..) then
rather start on the next frame instead of submitting the current one
again while compute applications make sure that the abort and tell the
user that the calculations might be corrupted and need to be redone.
Regards,
Christian.
> (it is possible for a GPU fault to break another
> process running concurrently, and this is a problem macOS has too...),
> which is still not perfect due to side effects but might work most of
> the time, but that depends on the "command patching" stuff I mentioned,
> and I'm still not even sure if it will be possible to do safely. There's
> a lot of subtlety around what we can and can't do during a firmware
> recovery cycle that I haven't even started to investigate yet (the
> answer could be "nothing" even).
>
> ~~ Lina
^ permalink raw reply [flat|nested] 122+ messages in thread
* Re: [PATCH RFC 11/18] drm/scheduler: Clean up jobs when the scheduler is torn down
2023-03-09 8:42 ` Christian König
@ 2023-03-09 9:43 ` Asahi Lina
2023-03-09 11:47 ` Christian König
2023-03-09 19:59 ` Faith Ekstrand
0 siblings, 2 replies; 122+ messages in thread
From: Asahi Lina @ 2023-03-09 9:43 UTC (permalink / raw)
To: Christian König, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Daniel Vetter, Miguel Ojeda,
Alex Gaynor, Wedson Almeida Filho, Boqun Feng, Gary Guo,
Björn Roy Baron, Sumit Semwal, Luben Tuikov,
Jarkko Sakkinen, Dave Hansen
Cc: Alyssa Rosenzweig, Karol Herbst, Ella Stanforth, Faith Ekstrand,
Mary, linux-kernel, dri-devel, rust-for-linux, linux-media,
linaro-mm-sig, linux-sgx, asahi
On 09/03/2023 17.42, Christian König wrote:
> Am 08.03.23 um 20:37 schrieb Asahi Lina:
>> On 09/03/2023 03.12, Christian König wrote:
>>> Am 08.03.23 um 18:32 schrieb Asahi Lina:
>>>> [SNIP]
>>>> Yes but... none of this cleans up jobs that are already submitted by the
>>>> scheduler and in its pending list, with registered completion callbacks,
>>>> which were already popped off of the entities.
>>>>
>>>> *That* is the problem this patch fixes!
>>> Ah! Yes that makes more sense now.
>>>
>>>>> We could add a warning when users of this API doesn't do this
>>>>> correctly, but cleaning up incorrect API use is clearly something we
>>>>> don't want here.
>>>> It is the job of the Rust abstractions to make incorrect API use that
>>>> leads to memory unsafety impossible. So even if you don't want that in
>>>> C, it's my job to do that for Rust... and right now, I just can't
>>>> because drm_sched doesn't provide an API that can be safely wrapped
>>>> without weird bits of babysitting functionality on top (like tracking
>>>> jobs outside or awkwardly making jobs hold a reference to the scheduler
>>>> and defer dropping it to another thread).
>>> Yeah, that was discussed before but rejected.
>>>
>>> The argument was that upper layer needs to wait for the hw to become
>>> idle before the scheduler can be destroyed anyway.
>> Unfortunately, that's not a requirement you can encode in the Rust type
>> system easily as far as I know, and Rust safety rules mean we need to
>> make it safe even if the upper layer doesn't do this... (or else we have
>> to mark the entire drm_sched abstraction unsafe, but that would be a pity).
>
> Yeah, that should really not be something we should do.
>
> But you could make the scheduler depend on your fw context object, don't
> you?
Yes, and that would fix the problem for this driver, but it wouldn't
make the abstraction safe. The thing is we have to make it *impossible*
to misuse drm_sched in such a way that it crashes, at the Rust
abstraction level. If we start depending on the driver following rules
like that, that means the drm_sched abstraction has to be marked unsafe.
> Detaching the scheduler from the underlying hw fences is certainly
> possible, but we removed that functionality because some people people
> tried to force push some Windows recovery module into Linux. We are in
> the process of reverting that and cleaning things up once more, but that
> will take a while.
Okay, but I don't see why that should block the Rust abstractions... I
don't even need a new API to do that, all I need is to know that
drm_sched_fini() will do it so it won't crash when the hw fences
complete later, as this patch does.
> Instead of detaching you could also block for the hw to become idle, but
> if you do that synchronous on process termination you run into trouble
> as well.
Yes, but again this something that can only be done at the driver level
so it doesn't solve the safe abstraction problem...
>> The firmware queue is itself reference counted and any firmware queue
>> that has acquired an event notification resource (that is, which is busy
>> with running or upcoming jobs) hands off a reference to itself into the
>> event subsystem, so it can get notified of job completions by the
>> firmware. Then once it becomes idle it unregisters itself, and at that
>> point if it has no owning userspace queue, that would be the last
>> reference and it gets dropped. So we don't tear down firmware queues
>> until they are idle.
>
> And could those fw queue not reference the scheduler?
Yes but again, that rule can't be encoded in the abstraction... so that
makes it unsafe. The goal is to have a safe abstraction, which means
that all the rules that you need to follow to avoid memory safety issues
are checked by the Rust compiler.
>> I actually don't know of any way to actively abort jobs on the firmware,
>> so this is pretty much the only option I have. I've even seen
>> long-running compute jobs on macOS run to completion even if you kill
>> the submitting process, so there might be no way to do this at all.
>> Though in practice since we unmap everything from the VM anyway when the
>> userspace stuff gets torn down, almost any normal GPU work is going to
>> immediately fault at that point (macOS doesn't do this because macOS
>> effectively does implicit sync with BO tracking at the kernel level...).
>
> Oh, that is an interesting information. How does macOS do explicit sync
> then or isn't that supported at all?
They have the equivalent of sync objects at the UAPI level, but they
also have the implicit stuff and their UAPI seems to always pass a BO
list to the kernel as far as we could tell, even though it still works
without it. I think it's a weird hybrid of explicit+implicit sync. From
the Metal docs:
> By default, Metal tracks the write hazards and synchronizes the resources
> (see Resource Fundamentals) you create from an MTLDevice and directly bind
> to a pipeline. However, Metal doesn’t, by default, track resources you
> allocate from an MTLHeap (see Memory Heaps).
So it's both, and you can override it...
At the firmware level, I've never seen Metal use queue barriers yet like
I do (other than the vertex->fragment ones), so either they always do
CPU round trips for cross-subqueue sync (render<->compute) or we just
haven't figured out the magic combination to get it to do that yet.
Honestly, I suspect they just always do it on the CPU. macOS is pretty
ugly behind the scenes and it's pretty obvious a lot of their own driver
was rushed (the firmware seems to support quite a few features the
driver doesn't... maybe it even has a job abort mechanism, we just
haven't found it yet).
Of course, our goal is to do things better than macOS (and we already do
some things better!) but getting confident enough about firmware/HW
details to diverge from what macOS does is tricky and a slow process...
>> By the way, I don't really use the hardware recovery stuff right now.
>> I'm not even sure if there is a sensible way I could use it, since as I
>> said we can't exactly abort jobs. I know there are ways to lock up the
>> firmware/GPU, but so far those have all been things the kernel driver
>> can prevent, and I'm not even sure if there is any way to recover from
>> that anyway. The firmware itself has its own timeouts and recovery for
>> "normal" problems. From the point of view of the driver and everything
>> above it, in-flight commands during a GPU fault or timeout are just
>> marked complete by the firmware, after a firmware recovery cycle where
>> the driver gets notified of the problem (that's when we mark the
>> commands failed so we can propagate the error).
>
> Yeah, that's exactly what we are telling our fw people for years that we
> need this as well.
Yeah, the ugly bit is that the firmware does a full GPU recovery even on
simple page faults (which could be handled more gracefully) so even
stuff like that can possibly break concurrent GPU work.
On the other hand, macOS configures things so page faults are ignored
and silently return all-00 on reads for shader accesses, which is how
they implement sparse buffers/textures... and we'll probably have to do
that to improve reliability against app faults if nothing else. But
right now the driver enables explicit page faults for everything so we
can debug Mesa (it's a kernel module param, GPU global and I haven't
found a way to change it after initial load unfortunately, but it might
be possible).
I think there's also a way to do actual page fault handling (like swap
in pages and resume the GPU), but that's one of those firmware features
Apple's driver just never uses as far as I can tell. There's so much
unexplored territory...
>
>> There is no re-submission or anything, userspace just gets told of the problem but
>> the queue survives.
>
>> In the future it might be possible to re-submit innocent commands
>
> Long story short: Don't do this! This is what the Windows drivers have
> been doing and it creates tons of problems.
>
> Just signal the problem back to userspace and let the user space driver
> decide what to do.
>
> The background is that most graphics applications (games etc..) then
> rather start on the next frame instead of submitting the current one
> again while compute applications make sure that the abort and tell the
> user that the calculations might be corrupted and need to be redone.
Then we're good with what we're currently doing, since we already notify
userspace like that!
Actually I wanted to ask about error notifications. Right now we have an
out-of-band mechanism to provide detailed fault info to userspace which
works fine, but in principle it's optional. However, I also mark the hw
fences as errored when a fault happens (with an errno that describes
the overall situation), but that never makes it into the drm_sched job
complete fence. I looked at the drm_sched code and I didn't see any
error propagation. Is that supposed to work, or am I supposed to
directly mark the drm_sched side fence as complete, or did I
misunderstand all this? I get the feeling maybe existing drivers just
rely on the recovery/timeout/etc paths to mark jobs as errored (since
those do it explicitly) and never need error forwarding from the hw fence?
~~ Lina
^ permalink raw reply [flat|nested] 122+ messages in thread
* Re: [PATCH RFC 11/18] drm/scheduler: Clean up jobs when the scheduler is torn down
2023-03-09 9:43 ` Asahi Lina
@ 2023-03-09 11:47 ` Christian König
2023-03-09 13:48 ` Asahi Lina
2023-03-09 19:59 ` Faith Ekstrand
1 sibling, 1 reply; 122+ messages in thread
From: Christian König @ 2023-03-09 11:47 UTC (permalink / raw)
To: Asahi Lina, Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
David Airlie, Daniel Vetter, Miguel Ojeda, Alex Gaynor,
Wedson Almeida Filho, Boqun Feng, Gary Guo, Björn Roy Baron,
Sumit Semwal, Luben Tuikov, Jarkko Sakkinen, Dave Hansen
Cc: Alyssa Rosenzweig, Karol Herbst, Ella Stanforth, Faith Ekstrand,
Mary, linux-kernel, dri-devel, rust-for-linux, linux-media,
linaro-mm-sig, linux-sgx, asahi
Am 09.03.23 um 10:43 schrieb Asahi Lina:
> On 09/03/2023 17.42, Christian König wrote:
>> Am 08.03.23 um 20:37 schrieb Asahi Lina:
>>> On 09/03/2023 03.12, Christian König wrote:
>>>> Am 08.03.23 um 18:32 schrieb Asahi Lina:
>>>>> [SNIP]
>>>>> Yes but... none of this cleans up jobs that are already submitted by the
>>>>> scheduler and in its pending list, with registered completion callbacks,
>>>>> which were already popped off of the entities.
>>>>>
>>>>> *That* is the problem this patch fixes!
>>>> Ah! Yes that makes more sense now.
>>>>
>>>>>> We could add a warning when users of this API doesn't do this
>>>>>> correctly, but cleaning up incorrect API use is clearly something we
>>>>>> don't want here.
>>>>> It is the job of the Rust abstractions to make incorrect API use that
>>>>> leads to memory unsafety impossible. So even if you don't want that in
>>>>> C, it's my job to do that for Rust... and right now, I just can't
>>>>> because drm_sched doesn't provide an API that can be safely wrapped
>>>>> without weird bits of babysitting functionality on top (like tracking
>>>>> jobs outside or awkwardly making jobs hold a reference to the scheduler
>>>>> and defer dropping it to another thread).
>>>> Yeah, that was discussed before but rejected.
>>>>
>>>> The argument was that upper layer needs to wait for the hw to become
>>>> idle before the scheduler can be destroyed anyway.
>>> Unfortunately, that's not a requirement you can encode in the Rust type
>>> system easily as far as I know, and Rust safety rules mean we need to
>>> make it safe even if the upper layer doesn't do this... (or else we have
>>> to mark the entire drm_sched abstraction unsafe, but that would be a pity).
>> Yeah, that should really not be something we should do.
>>
>> But you could make the scheduler depend on your fw context object, don't
>> you?
> Yes, and that would fix the problem for this driver, but it wouldn't
> make the abstraction safe. The thing is we have to make it *impossible*
> to misuse drm_sched in such a way that it crashes, at the Rust
> abstraction level. If we start depending on the driver following rules
> like that, that means the drm_sched abstraction has to be marked unsafe.
>
>> Detaching the scheduler from the underlying hw fences is certainly
>> possible, but we removed that functionality because some people people
>> tried to force push some Windows recovery module into Linux. We are in
>> the process of reverting that and cleaning things up once more, but that
>> will take a while.
> Okay, but I don't see why that should block the Rust abstractions...
Because even with removing the fence callback this is inherently unsafe.
You not only need to remove the callback, but also make sure that no
parallel timeout handling is running.
This might not matter for you driver at the moment, but it's certainly
something you need to keep in mind when you really want save handling.
Apart from that I don't have much objections to this here as long as
Maartens comments are addressed as well.
Regards,
Christian.
> I
> don't even need a new API to do that, all I need is to know that
> drm_sched_fini() will do it so it won't crash when the hw fences
> complete later, as this patch does.
>
>> Instead of detaching you could also block for the hw to become idle, but
>> if you do that synchronous on process termination you run into trouble
>> as well.
> Yes, but again this something that can only be done at the driver level
> so it doesn't solve the safe abstraction problem...
>
>>> The firmware queue is itself reference counted and any firmware queue
>>> that has acquired an event notification resource (that is, which is busy
>>> with running or upcoming jobs) hands off a reference to itself into the
>>> event subsystem, so it can get notified of job completions by the
>>> firmware. Then once it becomes idle it unregisters itself, and at that
>>> point if it has no owning userspace queue, that would be the last
>>> reference and it gets dropped. So we don't tear down firmware queues
>>> until they are idle.
>> And could those fw queue not reference the scheduler?
> Yes but again, that rule can't be encoded in the abstraction... so that
> makes it unsafe. The goal is to have a safe abstraction, which means
> that all the rules that you need to follow to avoid memory safety issues
> are checked by the Rust compiler.
>
>>> I actually don't know of any way to actively abort jobs on the firmware,
>>> so this is pretty much the only option I have. I've even seen
>>> long-running compute jobs on macOS run to completion even if you kill
>>> the submitting process, so there might be no way to do this at all.
>>> Though in practice since we unmap everything from the VM anyway when the
>>> userspace stuff gets torn down, almost any normal GPU work is going to
>>> immediately fault at that point (macOS doesn't do this because macOS
>>> effectively does implicit sync with BO tracking at the kernel level...).
>> Oh, that is an interesting information. How does macOS do explicit sync
>> then or isn't that supported at all?
> They have the equivalent of sync objects at the UAPI level, but they
> also have the implicit stuff and their UAPI seems to always pass a BO
> list to the kernel as far as we could tell, even though it still works
> without it. I think it's a weird hybrid of explicit+implicit sync. From
> the Metal docs:
>
>> By default, Metal tracks the write hazards and synchronizes the resources
>> (see Resource Fundamentals) you create from an MTLDevice and directly bind
>> to a pipeline. However, Metal doesn’t, by default, track resources you
>> allocate from an MTLHeap (see Memory Heaps).
> So it's both, and you can override it...
>
> At the firmware level, I've never seen Metal use queue barriers yet like
> I do (other than the vertex->fragment ones), so either they always do
> CPU round trips for cross-subqueue sync (render<->compute) or we just
> haven't figured out the magic combination to get it to do that yet.
> Honestly, I suspect they just always do it on the CPU. macOS is pretty
> ugly behind the scenes and it's pretty obvious a lot of their own driver
> was rushed (the firmware seems to support quite a few features the
> driver doesn't... maybe it even has a job abort mechanism, we just
> haven't found it yet).
>
> Of course, our goal is to do things better than macOS (and we already do
> some things better!) but getting confident enough about firmware/HW
> details to diverge from what macOS does is tricky and a slow process...
>
>>> By the way, I don't really use the hardware recovery stuff right now.
>>> I'm not even sure if there is a sensible way I could use it, since as I
>>> said we can't exactly abort jobs. I know there are ways to lock up the
>>> firmware/GPU, but so far those have all been things the kernel driver
>>> can prevent, and I'm not even sure if there is any way to recover from
>>> that anyway. The firmware itself has its own timeouts and recovery for
>>> "normal" problems. From the point of view of the driver and everything
>>> above it, in-flight commands during a GPU fault or timeout are just
>>> marked complete by the firmware, after a firmware recovery cycle where
>>> the driver gets notified of the problem (that's when we mark the
>>> commands failed so we can propagate the error).
>> Yeah, that's exactly what we are telling our fw people for years that we
>> need this as well.
> Yeah, the ugly bit is that the firmware does a full GPU recovery even on
> simple page faults (which could be handled more gracefully) so even
> stuff like that can possibly break concurrent GPU work.
>
> On the other hand, macOS configures things so page faults are ignored
> and silently return all-00 on reads for shader accesses, which is how
> they implement sparse buffers/textures... and we'll probably have to do
> that to improve reliability against app faults if nothing else. But
> right now the driver enables explicit page faults for everything so we
> can debug Mesa (it's a kernel module param, GPU global and I haven't
> found a way to change it after initial load unfortunately, but it might
> be possible).
>
> I think there's also a way to do actual page fault handling (like swap
> in pages and resume the GPU), but that's one of those firmware features
> Apple's driver just never uses as far as I can tell. There's so much
> unexplored territory...
>
>>> There is no re-submission or anything, userspace just gets told of the problem but
>>> the queue survives.
>>> In the future it might be possible to re-submit innocent commands
>> Long story short: Don't do this! This is what the Windows drivers have
>> been doing and it creates tons of problems.
>>
>> Just signal the problem back to userspace and let the user space driver
>> decide what to do.
>>
>> The background is that most graphics applications (games etc..) then
>> rather start on the next frame instead of submitting the current one
>> again while compute applications make sure that the abort and tell the
>> user that the calculations might be corrupted and need to be redone.
> Then we're good with what we're currently doing, since we already notify
> userspace like that!
>
> Actually I wanted to ask about error notifications. Right now we have an
> out-of-band mechanism to provide detailed fault info to userspace which
> works fine, but in principle it's optional. However, I also mark the hw
> fences as errored when a fault happens (with an errno that describes
> the overall situation), but that never makes it into the drm_sched job
> complete fence. I looked at the drm_sched code and I didn't see any
> error propagation. Is that supposed to work, or am I supposed to
> directly mark the drm_sched side fence as complete, or did I
> misunderstand all this? I get the feeling maybe existing drivers just
> rely on the recovery/timeout/etc paths to mark jobs as errored (since
> those do it explicitly) and never need error forwarding from the hw fence?
>
> ~~ Lina
^ permalink raw reply [flat|nested] 122+ messages in thread
* Re: [PATCH RFC 11/18] drm/scheduler: Clean up jobs when the scheduler is torn down
2023-03-09 11:47 ` Christian König
@ 2023-03-09 13:48 ` Asahi Lina
0 siblings, 0 replies; 122+ messages in thread
From: Asahi Lina @ 2023-03-09 13:48 UTC (permalink / raw)
To: Christian König, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Daniel Vetter, Miguel Ojeda,
Alex Gaynor, Wedson Almeida Filho, Boqun Feng, Gary Guo,
Björn Roy Baron, Sumit Semwal, Luben Tuikov,
Jarkko Sakkinen, Dave Hansen
Cc: Alyssa Rosenzweig, Karol Herbst, Ella Stanforth, Faith Ekstrand,
Mary, linux-kernel, dri-devel, rust-for-linux, linux-media,
linaro-mm-sig, linux-sgx, asahi
On 09/03/2023 20.47, Christian König wrote:
> Am 09.03.23 um 10:43 schrieb Asahi Lina:
>> On 09/03/2023 17.42, Christian König wrote:
>>> Am 08.03.23 um 20:37 schrieb Asahi Lina:
>>>> On 09/03/2023 03.12, Christian König wrote:
>>>>> Am 08.03.23 um 18:32 schrieb Asahi Lina:
>>>>>> [SNIP]
>>>>>> Yes but... none of this cleans up jobs that are already submitted by the
>>>>>> scheduler and in its pending list, with registered completion callbacks,
>>>>>> which were already popped off of the entities.
>>>>>>
>>>>>> *That* is the problem this patch fixes!
>>>>> Ah! Yes that makes more sense now.
>>>>>
>>>>>>> We could add a warning when users of this API doesn't do this
>>>>>>> correctly, but cleaning up incorrect API use is clearly something we
>>>>>>> don't want here.
>>>>>> It is the job of the Rust abstractions to make incorrect API use that
>>>>>> leads to memory unsafety impossible. So even if you don't want that in
>>>>>> C, it's my job to do that for Rust... and right now, I just can't
>>>>>> because drm_sched doesn't provide an API that can be safely wrapped
>>>>>> without weird bits of babysitting functionality on top (like tracking
>>>>>> jobs outside or awkwardly making jobs hold a reference to the scheduler
>>>>>> and defer dropping it to another thread).
>>>>> Yeah, that was discussed before but rejected.
>>>>>
>>>>> The argument was that upper layer needs to wait for the hw to become
>>>>> idle before the scheduler can be destroyed anyway.
>>>> Unfortunately, that's not a requirement you can encode in the Rust type
>>>> system easily as far as I know, and Rust safety rules mean we need to
>>>> make it safe even if the upper layer doesn't do this... (or else we have
>>>> to mark the entire drm_sched abstraction unsafe, but that would be a pity).
>>> Yeah, that should really not be something we should do.
>>>
>>> But you could make the scheduler depend on your fw context object, don't
>>> you?
>> Yes, and that would fix the problem for this driver, but it wouldn't
>> make the abstraction safe. The thing is we have to make it *impossible*
>> to misuse drm_sched in such a way that it crashes, at the Rust
>> abstraction level. If we start depending on the driver following rules
>> like that, that means the drm_sched abstraction has to be marked unsafe.
>>
>>> Detaching the scheduler from the underlying hw fences is certainly
>>> possible, but we removed that functionality because some people people
>>> tried to force push some Windows recovery module into Linux. We are in
>>> the process of reverting that and cleaning things up once more, but that
>>> will take a while.
>> Okay, but I don't see why that should block the Rust abstractions...
>
> Because even with removing the fence callback this is inherently unsafe.
>
> You not only need to remove the callback, but also make sure that no
> parallel timeout handling is running.
If by that you mean that the timeout handling functions aren't being
called by the driver, then that's implied. If the scheduler is being
dropped, by definition there are no references left to call into the
scheduler directly from the Rust side. So we only need to worry about
what drm_sched itself does.
Right now the cleanup function tears down the timeout work at the end,
but it probably makes sense to do it at the start? Then if we do that
and stop the kthread, we can be really sure nothing else is accessing
the scheduler and we can clean up without taking any locks:
Roughly:
void drm_sched_fini(struct drm_gpu_scheduler *sched)
{
sched->ready = false; /* Should probably do this first? */
kthread_stop(sched->thread);
cancel_delayed_work_sync(&sched->work_tdr);
/* Clean up the pending_list here */
}
I'm also not sure what the rest of the drm_sched_fini() function is
doing right now. It's going through all entities and removing them, and
then wakes up entities stuck in drm_sched_entity_flush()... but didn't
we just agree that the API requires users to tear down entities before
tearing down the scheduler anyway?
~~ Lina
^ permalink raw reply [flat|nested] 122+ messages in thread
* Re: [PATCH RFC 11/18] drm/scheduler: Clean up jobs when the scheduler is torn down
2023-03-09 9:43 ` Asahi Lina
2023-03-09 11:47 ` Christian König
@ 2023-03-09 19:59 ` Faith Ekstrand
2023-03-10 9:58 ` Asahi Lina
1 sibling, 1 reply; 122+ messages in thread
From: Faith Ekstrand @ 2023-03-09 19:59 UTC (permalink / raw)
To: Asahi Lina, Christian König, Maarten Lankhorst,
Maxime Ripard, Thomas Zimmermann, David Airlie, Daniel Vetter,
Miguel Ojeda, Alex Gaynor, Wedson Almeida Filho, Boqun Feng,
Gary Guo, Björn Roy Baron, Sumit Semwal, Luben Tuikov,
Jarkko Sakkinen, Dave Hansen
Cc: Alyssa Rosenzweig, Karol Herbst, Ella Stanforth, Mary,
linux-kernel, dri-devel, rust-for-linux, linux-media,
linaro-mm-sig, linux-sgx, asahi
On Thu, 2023-03-09 at 18:43 +0900, Asahi Lina wrote:
> On 09/03/2023 17.42, Christian König wrote:
> > Am 08.03.23 um 20:37 schrieb Asahi Lina:
> > > On 09/03/2023 03.12, Christian König wrote:
> > > > Am 08.03.23 um 18:32 schrieb Asahi Lina:
> > > > > [SNIP]
> > > > > Yes but... none of this cleans up jobs that are already
> > > > > submitted by the
> > > > > scheduler and in its pending list, with registered completion
> > > > > callbacks,
> > > > > which were already popped off of the entities.
> > > > >
> > > > > *That* is the problem this patch fixes!
> > > > Ah! Yes that makes more sense now.
> > > >
> > > > > > We could add a warning when users of this API doesn't do
> > > > > > this
> > > > > > correctly, but cleaning up incorrect API use is clearly
> > > > > > something we
> > > > > > don't want here.
> > > > > It is the job of the Rust abstractions to make incorrect API
> > > > > use that
> > > > > leads to memory unsafety impossible. So even if you don't
> > > > > want that in
> > > > > C, it's my job to do that for Rust... and right now, I just
> > > > > can't
> > > > > because drm_sched doesn't provide an API that can be safely
> > > > > wrapped
> > > > > without weird bits of babysitting functionality on top (like
> > > > > tracking
> > > > > jobs outside or awkwardly making jobs hold a reference to the
> > > > > scheduler
> > > > > and defer dropping it to another thread).
> > > > Yeah, that was discussed before but rejected.
> > > >
> > > > The argument was that upper layer needs to wait for the hw to
> > > > become
> > > > idle before the scheduler can be destroyed anyway.
> > > Unfortunately, that's not a requirement you can encode in the
> > > Rust type
> > > system easily as far as I know, and Rust safety rules mean we
> > > need to
> > > make it safe even if the upper layer doesn't do this... (or else
> > > we have
> > > to mark the entire drm_sched abstraction unsafe, but that would
> > > be a pity).
> >
> > Yeah, that should really not be something we should do.
> >
> > But you could make the scheduler depend on your fw context object,
> > don't
> > you?
>
> Yes, and that would fix the problem for this driver, but it wouldn't
> make the abstraction safe. The thing is we have to make it
> *impossible*
> to misuse drm_sched in such a way that it crashes, at the Rust
> abstraction level. If we start depending on the driver following
> rules
> like that, that means the drm_sched abstraction has to be marked
> unsafe.
>
> > Detaching the scheduler from the underlying hw fences is certainly
> > possible, but we removed that functionality because some people
> > people
> > tried to force push some Windows recovery module into Linux. We are
> > in
> > the process of reverting that and cleaning things up once more, but
> > that
> > will take a while.
>
> Okay, but I don't see why that should block the Rust abstractions...
> I
> don't even need a new API to do that, all I need is to know that
> drm_sched_fini() will do it so it won't crash when the hw fences
> complete later, as this patch does.
>
> > Instead of detaching you could also block for the hw to become
> > idle, but
> > if you do that synchronous on process termination you run into
> > trouble
> > as well.
>
> Yes, but again this something that can only be done at the driver
> level
> so it doesn't solve the safe abstraction problem...
>
> > > The firmware queue is itself reference counted and any firmware
> > > queue
> > > that has acquired an event notification resource (that is, which
> > > is busy
> > > with running or upcoming jobs) hands off a reference to itself
> > > into the
> > > event subsystem, so it can get notified of job completions by the
> > > firmware. Then once it becomes idle it unregisters itself, and at
> > > that
> > > point if it has no owning userspace queue, that would be the last
> > > reference and it gets dropped. So we don't tear down firmware
> > > queues
> > > until they are idle.
> >
> > And could those fw queue not reference the scheduler?
>
> Yes but again, that rule can't be encoded in the abstraction... so
> that
> makes it unsafe. The goal is to have a safe abstraction, which means
> that all the rules that you need to follow to avoid memory safety
> issues
> are checked by the Rust compiler.
>
> > > I actually don't know of any way to actively abort jobs on the
> > > firmware,
> > > so this is pretty much the only option I have. I've even seen
> > > long-running compute jobs on macOS run to completion even if you
> > > kill
> > > the submitting process, so there might be no way to do this at
> > > all.
> > > Though in practice since we unmap everything from the VM anyway
> > > when the
> > > userspace stuff gets torn down, almost any normal GPU work is
> > > going to
> > > immediately fault at that point (macOS doesn't do this because
> > > macOS
> > > effectively does implicit sync with BO tracking at the kernel
> > > level...).
> >
> > Oh, that is an interesting information. How does macOS do explicit
> > sync
> > then or isn't that supported at all?
>
> They have the equivalent of sync objects at the UAPI level, but they
> also have the implicit stuff and their UAPI seems to always pass a BO
> list to the kernel as far as we could tell, even though it still
> works
> without it. I think it's a weird hybrid of explicit+implicit sync.
> From
> the Metal docs:
>
> > By default, Metal tracks the write hazards and synchronizes the
> > resources
> > (see Resource Fundamentals) you create from an MTLDevice and
> > directly bind
> > to a pipeline. However, Metal doesn’t, by default, track resources
> > you
> > allocate from an MTLHeap (see Memory Heaps).
>
> So it's both, and you can override it...
>
> At the firmware level, I've never seen Metal use queue barriers yet
> like
> I do (other than the vertex->fragment ones), so either they always do
> CPU round trips for cross-subqueue sync (render<->compute) or we just
> haven't figured out the magic combination to get it to do that yet.
> Honestly, I suspect they just always do it on the CPU. macOS is
> pretty
> ugly behind the scenes and it's pretty obvious a lot of their own
> driver
> was rushed (the firmware seems to support quite a few features the
> driver doesn't... maybe it even has a job abort mechanism, we just
> haven't found it yet).
>
> Of course, our goal is to do things better than macOS (and we already
> do
> some things better!) but getting confident enough about firmware/HW
> details to diverge from what macOS does is tricky and a slow
> process...
>
> > > By the way, I don't really use the hardware recovery stuff right
> > > now.
> > > I'm not even sure if there is a sensible way I could use it,
> > > since as I
> > > said we can't exactly abort jobs. I know there are ways to lock
> > > up the
> > > firmware/GPU, but so far those have all been things the kernel
> > > driver
> > > can prevent, and I'm not even sure if there is any way to recover
> > > from
> > > that anyway. The firmware itself has its own timeouts and
> > > recovery for
> > > "normal" problems. From the point of view of the driver and
> > > everything
> > > above it, in-flight commands during a GPU fault or timeout are
> > > just
> > > marked complete by the firmware, after a firmware recovery cycle
> > > where
> > > the driver gets notified of the problem (that's when we mark the
> > > commands failed so we can propagate the error).
> >
> > Yeah, that's exactly what we are telling our fw people for years
> > that we
> > need this as well.
>
> Yeah, the ugly bit is that the firmware does a full GPU recovery even
> on
> simple page faults (which could be handled more gracefully) so even
> stuff like that can possibly break concurrent GPU work.
>
> On the other hand, macOS configures things so page faults are ignored
> and silently return all-00 on reads for shader accesses, which is how
> they implement sparse buffers/textures... and we'll probably have to
> do
> that to improve reliability against app faults if nothing else. But
> right now the driver enables explicit page faults for everything so
> we
> can debug Mesa (it's a kernel module param, GPU global and I haven't
> found a way to change it after initial load unfortunately, but it
> might
> be possible).
>
> I think there's also a way to do actual page fault handling (like
> swap
> in pages and resume the GPU), but that's one of those firmware
> features
> Apple's driver just never uses as far as I can tell. There's so much
> unexplored territory...
>
> >
> > > There is no re-submission or anything, userspace just gets told
> > > of the problem but
> > > the queue survives.
> >
> > > In the future it might be possible to re-submit innocent commands
> >
> > Long story short: Don't do this! This is what the Windows drivers
> > have
> > been doing and it creates tons of problems.
Yeah, we tried to do a bit of that in the GL days. It was a bad idea.
> > Just signal the problem back to userspace and let the user space
> > driver
> > decide what to do.
> >
> > The background is that most graphics applications (games etc..)
> > then
> > rather start on the next frame instead of submitting the current
> > one
> > again while compute applications make sure that the abort and tell
> > the
> > user that the calculations might be corrupted and need to be
> > redone.
The guarantee that Vulkan makes is that, if you idle the GPU and you
haven't gotten a DEVICE_LOST yet, your data is good. If you get a
DEVICE_LOST, all bets are off. The problem is that, no matter how fast
the error propagation may be in the kernel or userspace driver, errors
can still show up in strange ways. An OOB buffer access could end up
modifying a shader binary which gets run 3 frames later and causes a
corruption. Once you've faulted, you really have no idea how far back
is good or what memory is corrupted. You have to assume that
everything mapped to the GPU VA space is potentially toast.
> Then we're good with what we're currently doing, since we already
> notify
> userspace like that!
>
> Actually I wanted to ask about error notifications. Right now we have
> an
> out-of-band mechanism to provide detailed fault info to userspace
> which
> works fine, but in principle it's optional.
This is fine, in principal. Because of the nature of errors, async is
fine as long as the error shows up eventually. Faster is better, for
sure, but error latency doesn't really matter in practice.
> However, I also mark the hw
> fences as errored when a fault happens (with an errno that describes
> the overall situation), but that never makes it into the drm_sched
> job
> complete fence. I looked at the drm_sched code and I didn't see any
> error propagation. Is that supposed to work, or am I supposed to
> directly mark the drm_sched side fence as complete, or did I
> misunderstand all this? I get the feeling maybe existing drivers just
> rely on the recovery/timeout/etc paths to mark jobs as errored (since
> those do it explicitly) and never need error forwarding from the hw
> fence?
The end behavior needs to be that all fences for all jobs submitted to
the queue get signaled. That's needed to satisfy the finite time
guarantees of dma_fence. Exactly how that happens (let the job run,
abort all the jobs, etc.) is an implementation detail for the driver to
decide. If you want, you can also set a bit on the context (or queue)
to mark it as dead and start returning EIO or similar from any ioctls
trying to submit more work if you wanted. Not required but you can.
~Faith
^ permalink raw reply [flat|nested] 122+ messages in thread
* Re: [PATCH RFC 11/18] drm/scheduler: Clean up jobs when the scheduler is torn down
2023-03-09 19:59 ` Faith Ekstrand
@ 2023-03-10 9:58 ` Asahi Lina
2023-03-13 20:11 ` Faith Ekstrand
0 siblings, 1 reply; 122+ messages in thread
From: Asahi Lina @ 2023-03-10 9:58 UTC (permalink / raw)
To: Faith Ekstrand, Christian König, Maarten Lankhorst,
Maxime Ripard, Thomas Zimmermann, David Airlie, Daniel Vetter,
Miguel Ojeda, Alex Gaynor, Wedson Almeida Filho, Boqun Feng,
Gary Guo, Björn Roy Baron, Sumit Semwal, Luben Tuikov,
Jarkko Sakkinen, Dave Hansen
Cc: Alyssa Rosenzweig, Karol Herbst, Ella Stanforth, Mary,
linux-kernel, dri-devel, rust-for-linux, linux-media,
linaro-mm-sig, linux-sgx, asahi
On 10/03/2023 04.59, Faith Ekstrand wrote:
> On Thu, 2023-03-09 at 18:43 +0900, Asahi Lina wrote:
>> On 09/03/2023 17.42, Christian König wrote:
>>> Long story short: Don't do this! This is what the Windows drivers
>>> have
>>> been doing and it creates tons of problems.
>
> Yeah, we tried to do a bit of that in the GL days. It was a bad idea.
I think I should clarify: I was proposing re-queueing innocent jobs from
innocent queues/VMs that were impacted by a fault. The reason is that we
may be able to tweak firmware state to force it to do that safely,
during the firmware recovery cycle, such that an aborted job restarts
and then subsequent jobs/commands continue as normal. We can't leave it
to userspace because if we do nothing, the affected job ends up
incomplete but then everything after it that is already queued still
runs, and that is definitely a recipe for a bigger mess if userspace
wants to seamlessly recover. The firmware recovery cycle is a
"stop-the-world" situation for the GPU (the firmware literally
busy-loops waiting for the driver to set a continue flag in memory...),
so that's the only real chance that the driver gets to make decisions
about what is going to happen next.
Of course, that only works if individual possibly concurrently running
commands are idempotent, but I think a lot of typical GPU work is? (E.g.
any render pass without side effects other than the render targets and
where the background shader does no loads, or even render passes that do
loads but where all draws are opaque, which are all things the current
Gallium driver is intimately familiar with since Crazy Tiler
Optimizations™ need that info to be provided anyway). So I was wondering
whether it'd make sense to have such an idempotency/restartable flag on
job submission, and then the driver would do its best to recover and
rerun it if it gets killed by an unrelated concurrent bad job.
Then again this all depends on an investigation into what we *can* do
during firmware recovery that hasn't happened at all yet. It might be
that it isn't safe to do anything really, or that doing things depends
on touching even deeper firmware state structs that we treat as opaque
right now and we really don't want to have to touch...
But maybe none of this is worth it in practice, it just sounded like it
could be useful maybe?
Now that I look at it, we have a lovely "what is this flag doing anyway"
bit already passed from Mesa through to the firmware we called
ASAHI_RENDER_SET_WHEN_RELOADING_Z_OR_S which, now that I look at it, is
actually getting set when any attachment (any color, Z, S) is not being
cleared for that pass (so it's loaded). That could very well be an "is
not idempotent" flag... and maybe that means the firmware does this for
us already? Sounds like something to test... I might have some 16Kx16K
GLmark runs to do concurrent with an evil faulting job now ^^ (and then
that also means we need to set it when shaders have side effects and
stuff, which right now we don't).
>>> Just signal the problem back to userspace and let the user space
>>> driver
>>> decide what to do.
>>>
>>> The background is that most graphics applications (games etc..)
>>> then
>>> rather start on the next frame instead of submitting the current
>>> one
>>> again while compute applications make sure that the abort and tell
>>> the
>>> user that the calculations might be corrupted and need to be
>>> redone.
>
> The guarantee that Vulkan makes is that, if you idle the GPU and you
> haven't gotten a DEVICE_LOST yet, your data is good. If you get a
> DEVICE_LOST, all bets are off. The problem is that, no matter how fast
> the error propagation may be in the kernel or userspace driver, errors
> can still show up in strange ways. An OOB buffer access could end up
> modifying a shader binary which gets run 3 frames later and causes a
> corruption. Once you've faulted, you really have no idea how far back
> is good or what memory is corrupted. You have to assume that
> everything mapped to the GPU VA space is potentially toast.
Yes of course, for the actually faulting VM all bets are off after a
fault (though we can try a bit harder at least... I have a READ_ONLY BO
flag now, I should set it on the shader pools!).
>> Actually I wanted to ask about error notifications. Right now we have
>> an
>> out-of-band mechanism to provide detailed fault info to userspace
>> which
>> works fine, but in principle it's optional.
>
> This is fine, in principal. Because of the nature of errors, async is
> fine as long as the error shows up eventually. Faster is better, for
> sure, but error latency doesn't really matter in practice.
>
>> However, I also mark the hw
>> fences as errored when a fault happens (with an errno that describes
>> the overall situation), but that never makes it into the drm_sched
>> job
>> complete fence. I looked at the drm_sched code and I didn't see any
>> error propagation. Is that supposed to work, or am I supposed to
>> directly mark the drm_sched side fence as complete, or did I
>> misunderstand all this? I get the feeling maybe existing drivers just
>> rely on the recovery/timeout/etc paths to mark jobs as errored (since
>> those do it explicitly) and never need error forwarding from the hw
>> fence?
>
> The end behavior needs to be that all fences for all jobs submitted to
> the queue get signaled. That's needed to satisfy the finite time
> guarantees of dma_fence. Exactly how that happens (let the job run,
> abort all the jobs, etc.) is an implementation detail for the driver to
> decide. If you want, you can also set a bit on the context (or queue)
> to mark it as dead and start returning EIO or similar from any ioctls
> trying to submit more work if you wanted. Not required but you can.
Fences have an error flag though, does that get reported to userspace
somehow? I thought it did, but maybe not, or maybe only drm_sched not
propagating it is the issue?
In other words, absent my fancy stats reporting BO system, what is the
normal way that an explicit sync driver signals to userspace that the
job associated with a syncobj has failed?
(If there is no way, then I'll probably want to change the stats BO
system to be configurable, so if you ask for no stats/time info, you
only get overall job status and faults, which has less overhead.)
~~ Lina
^ permalink raw reply [flat|nested] 122+ messages in thread
* Re: [PATCH RFC 11/18] drm/scheduler: Clean up jobs when the scheduler is torn down
2023-03-10 9:58 ` Asahi Lina
@ 2023-03-13 20:11 ` Faith Ekstrand
0 siblings, 0 replies; 122+ messages in thread
From: Faith Ekstrand @ 2023-03-13 20:11 UTC (permalink / raw)
To: Asahi Lina, Christian König, Maarten Lankhorst,
Maxime Ripard, Thomas Zimmermann, David Airlie, Daniel Vetter,
Miguel Ojeda, Alex Gaynor, Wedson Almeida Filho, Boqun Feng,
Gary Guo, Björn Roy Baron, Sumit Semwal, Luben Tuikov,
Jarkko Sakkinen, Dave Hansen
Cc: Alyssa Rosenzweig, Karol Herbst, Ella Stanforth, Mary,
linux-kernel, dri-devel, rust-for-linux, linux-media,
linaro-mm-sig, linux-sgx, asahi
On Fri, 2023-03-10 at 18:58 +0900, Asahi Lina wrote:
> On 10/03/2023 04.59, Faith Ekstrand wrote:
> > On Thu, 2023-03-09 at 18:43 +0900, Asahi Lina wrote:
> > > On 09/03/2023 17.42, Christian König wrote:
> > > > Long story short: Don't do this! This is what the Windows
> > > > drivers
> > > > have
> > > > been doing and it creates tons of problems.
> >
> > Yeah, we tried to do a bit of that in the GL days. It was a bad
> > idea.
>
> I think I should clarify: I was proposing re-queueing innocent jobs
> from
> innocent queues/VMs that were impacted by a fault. The reason is that
> we
> may be able to tweak firmware state to force it to do that safely,
> during the firmware recovery cycle, such that an aborted job restarts
> and then subsequent jobs/commands continue as normal. We can't leave
> it
> to userspace because if we do nothing, the affected job ends up
> incomplete but then everything after it that is already queued still
> runs, and that is definitely a recipe for a bigger mess if userspace
> wants to seamlessly recover. The firmware recovery cycle is a
> "stop-the-world" situation for the GPU (the firmware literally
> busy-loops waiting for the driver to set a continue flag in
> memory...),
> so that's the only real chance that the driver gets to make decisions
> about what is going to happen next.
Ok, that makes sense. Yes, if you have other jobs on other queues and
are able to recover everything that isn't in the faulting VM, that's a
good thing. I wasn't sure how hang/fault recovery worked on AGX. In
tat case, I don't think there's a dma_fence problem. As long as you
keep recovering and killing off any faulting contexts, eventually the
good contexts should make progress and those fences should signal.
Of course, the firmware recovery cycle may be complex and need (or at
least appear to) memory allocation or similar and that's where
everything gets hairy. Hopefully, though, if you've already got the
resources from the old context, you can re-use them after a bit of
clean-up work and still get deterministic and reliable recovery cycles.
> Of course, that only works if individual possibly concurrently
> running
> commands are idempotent, but I think a lot of typical GPU work is?
No, that's not a valid assumption. For a single 3D render pass which
doesn't do any image or SSBO access, it may be possible to re-run it.
However, that won't be true of compute work and isn't necessarily true
of back-to-back passes. Lots of modern apps do temporal stuff where one
frame depends on the previous and a re-run might screw that up. Also,
with Vulkan's memory aliasing, it's hard to tell just from which
resources are accessed whether or not a command buffer leaves its input
memory undamaged.
> (E.g.
> any render pass without side effects other than the render targets
> and
> where the background shader does no loads, or even render passes that
> do
> loads but where all draws are opaque, which are all things the
> current
> Gallium driver is intimately familiar with since Crazy Tiler
> Optimizations™ need that info to be provided anyway). So I was
> wondering
> whether it'd make sense to have such an idempotency/restartable flag
> on
> job submission, and then the driver would do its best to recover and
> rerun it if it gets killed by an unrelated concurrent bad job.
>
> Then again this all depends on an investigation into what we *can* do
> during firmware recovery that hasn't happened at all yet. It might be
> that it isn't safe to do anything really, or that doing things
> depends
> on touching even deeper firmware state structs that we treat as
> opaque
> right now and we really don't want to have to touch...
>
> But maybe none of this is worth it in practice, it just sounded like
> it
> could be useful maybe?
Maybe? It's not clear to me that such a flag would be useful or even
practical to provide from the Mesa side. Ideally, you'd be able to
figure out when a fault happens, what VM it happened in and exactly
what work was in-flight when it happened and only kill the one guilty
VM. However, it sounds like your understanding of the firmware is
currently rough enough that doing so may not be practical. In that
case, the best thing to do is to kill any VMs which were on the GPU at
the time and hope the individual apps are able to recover.
> Now that I look at it, we have a lovely "what is this flag doing
> anyway"
> bit already passed from Mesa through to the firmware we called
> ASAHI_RENDER_SET_WHEN_RELOADING_Z_OR_S which, now that I look at it,
> is
> actually getting set when any attachment (any color, Z, S) is not
> being
> cleared for that pass (so it's loaded). That could very well be an
> "is
> not idempotent" flag... and maybe that means the firmware does this
> for
> us already? Sounds like something to test... I might have some
> 16Kx16K
> GLmark runs to do concurrent with an evil faulting job now ^^ (and
> then
> that also means we need to set it when shaders have side effects and
> stuff, which right now we don't).
>
> > > > Just signal the problem back to userspace and let the user
> > > > space
> > > > driver
> > > > decide what to do.
> > > >
> > > > The background is that most graphics applications (games etc..)
> > > > then
> > > > rather start on the next frame instead of submitting the
> > > > current
> > > > one
> > > > again while compute applications make sure that the abort and
> > > > tell
> > > > the
> > > > user that the calculations might be corrupted and need to be
> > > > redone.
> >
> > The guarantee that Vulkan makes is that, if you idle the GPU and
> > you
> > haven't gotten a DEVICE_LOST yet, your data is good. If you get a
> > DEVICE_LOST, all bets are off. The problem is that, no matter how
> > fast
> > the error propagation may be in the kernel or userspace driver,
> > errors
> > can still show up in strange ways. An OOB buffer access could end
> > up
> > modifying a shader binary which gets run 3 frames later and causes
> > a
> > corruption. Once you've faulted, you really have no idea how far
> > back
> > is good or what memory is corrupted. You have to assume that
> > everything mapped to the GPU VA space is potentially toast.
>
> Yes of course, for the actually faulting VM all bets are off after a
> fault (though we can try a bit harder at least... I have a READ_ONLY
> BO
> flag now, I should set it on the shader pools!).
>
> > > Actually I wanted to ask about error notifications. Right now we
> > > have
> > > an
> > > out-of-band mechanism to provide detailed fault info to userspace
> > > which
> > > works fine, but in principle it's optional.
> >
> > This is fine, in principal. Because of the nature of errors, async
> > is
> > fine as long as the error shows up eventually. Faster is better,
> > for
> > sure, but error latency doesn't really matter in practice.
> >
> > > However, I also mark the hw
> > > fences as errored when a fault happens (with an errno that
> > > describes
> > > the overall situation), but that never makes it into the
> > > drm_sched
> > > job
> > > complete fence. I looked at the drm_sched code and I didn't see
> > > any
> > > error propagation. Is that supposed to work, or am I supposed to
> > > directly mark the drm_sched side fence as complete, or did I
> > > misunderstand all this? I get the feeling maybe existing drivers
> > > just
> > > rely on the recovery/timeout/etc paths to mark jobs as errored
> > > (since
> > > those do it explicitly) and never need error forwarding from the
> > > hw
> > > fence?
> >
> > The end behavior needs to be that all fences for all jobs submitted
> > to
> > the queue get signaled. That's needed to satisfy the finite time
> > guarantees of dma_fence. Exactly how that happens (let the job
> > run,
> > abort all the jobs, etc.) is an implementation detail for the
> > driver to
> > decide. If you want, you can also set a bit on the context (or
> > queue)
> > to mark it as dead and start returning EIO or similar from any
> > ioctls
> > trying to submit more work if you wanted. Not required but you
> > can.
>
> Fences have an error flag though, does that get reported to userspace
> somehow? I thought it did, but maybe not, or maybe only drm_sched not
> propagating it is the issue?
>
> In other words, absent my fancy stats reporting BO system, what is
> the
> normal way that an explicit sync driver signals to userspace that the
> job associated with a syncobj has failed?
One is via the return value from exec/submit. Often there's also a
query mechanism for more detailed information. It's not particularly
standard at the moment, I'm afraid. I could point you at i915 but I
wouldn't call that uAPI something to be emulated, in general.
> (If there is no way, then I'll probably want to change the stats BO
> system to be configurable, so if you ask for no stats/time info, you
> only get overall job status and faults, which has less overhead.)
There is an error but it doesn't automatically get propagated to
userspace. So, for instance, a SYNCOBJ_WAIT ioctl won't return an
error if it sees a fence error. It needs to get caught by the driver
and returned through a driver ioctl somehow.
~Faith
^ permalink raw reply [flat|nested] 122+ messages in thread
* Re: [PATCH RFC 11/18] drm/scheduler: Clean up jobs when the scheduler is torn down
2023-03-08 15:42 ` Christian König
2023-03-08 17:32 ` Asahi Lina
@ 2023-03-08 17:39 ` alyssa
2023-03-08 17:44 ` Asahi Lina
2023-03-08 18:13 ` Christian König
1 sibling, 2 replies; 122+ messages in thread
From: alyssa @ 2023-03-08 17:39 UTC (permalink / raw)
To: Asahi Lina, Christian König, Maarten Lankhorst,
Maxime Ripard, Thomas Zimmermann, David Airlie, Daniel Vetter,
Miguel Ojeda, Alex Gaynor, Wedson Almeida Filho, Boqun Feng,
Gary Guo, Björn Roy Baron, Sumit Semwal, Luben Tuikov,
Jarkko Sakkinen, Dave Hansen
Cc: Karol Herbst, Ella Stanforth, Faith Ekstrand, Mary, linux-kernel,
dri-devel, rust-for-linux, linux-media, linaro-mm-sig, linux-sgx,
asahi
> You can't ask me for a list
> of pending jobs (the scheduler knows this, it doesn't make any sense to
> duplicate that outside)
Silly question: could you add a new exported function to drm_sched to get the list of pending jobs, to be used by the Rust abstraction internally? IDK if that makes any sense.
^ permalink raw reply [flat|nested] 122+ messages in thread
* Re: [PATCH RFC 11/18] drm/scheduler: Clean up jobs when the scheduler is torn down
2023-03-08 17:39 ` alyssa
@ 2023-03-08 17:44 ` Asahi Lina
2023-03-08 18:13 ` Christian König
1 sibling, 0 replies; 122+ messages in thread
From: Asahi Lina @ 2023-03-08 17:44 UTC (permalink / raw)
To: alyssa, Christian König, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Daniel Vetter, Miguel Ojeda,
Alex Gaynor, Wedson Almeida Filho, Boqun Feng, Gary Guo,
Björn Roy Baron, Sumit Semwal, Luben Tuikov,
Jarkko Sakkinen, Dave Hansen
Cc: Karol Herbst, Ella Stanforth, Faith Ekstrand, Mary, linux-kernel,
dri-devel, rust-for-linux, linux-media, linaro-mm-sig, linux-sgx,
asahi
On 09/03/2023 02.39, alyssa@rosenzweig.io wrote:
>> You can't ask me for a list
>> of pending jobs (the scheduler knows this, it doesn't make any sense to
>> duplicate that outside)
>
> Silly question: could you add a new exported function to drm_sched to get the list of pending jobs, to be used by the Rust abstraction internally? IDK if that makes any sense.
The drm_sched struct is public, we could just go in there and do it
anyway... but then I need to figure out how to do
`list_for_each_entry_safe` in Rust and this all makes very little sense
when it's clearly the scheduler's job to provide some form of cleanup
function users can use to do it...
I mean, I guess I can do that if Christian is adamantly against
providing a safe C API, but it's clearly not the right solution and I
hope this is not the approach maintainers take with Rust abstractions,
because that's going to make our lives a lot harder for no good reason,
and it also means C users don't get any of the benefits of Rust
abstraction work if the APIs can't be improved at all along with it.
~~ Lina
^ permalink raw reply [flat|nested] 122+ messages in thread
* Re: [PATCH RFC 11/18] drm/scheduler: Clean up jobs when the scheduler is torn down
2023-03-08 17:39 ` alyssa
2023-03-08 17:44 ` Asahi Lina
@ 2023-03-08 18:13 ` Christian König
1 sibling, 0 replies; 122+ messages in thread
From: Christian König @ 2023-03-08 18:13 UTC (permalink / raw)
To: alyssa, Asahi Lina, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Daniel Vetter, Miguel Ojeda,
Alex Gaynor, Wedson Almeida Filho, Boqun Feng, Gary Guo,
Björn Roy Baron, Sumit Semwal, Luben Tuikov,
Jarkko Sakkinen, Dave Hansen
Cc: Karol Herbst, Ella Stanforth, Faith Ekstrand, Mary, linux-kernel,
dri-devel, rust-for-linux, linux-media, linaro-mm-sig, linux-sgx,
asahi
Am 08.03.23 um 18:39 schrieb alyssa@rosenzweig.io:
>> You can't ask me for a list
>> of pending jobs (the scheduler knows this, it doesn't make any sense to
>> duplicate that outside)
> Silly question: could you add a new exported function to drm_sched to get the list of pending jobs, to be used by the Rust abstraction internally? IDK if that makes any sense.
I was thinking about something similar as well. The problem is that you
could only use this function from the scheduler thread itself, e.g. from
one of its callback functions.
Christian.
^ permalink raw reply [flat|nested] 122+ messages in thread
* Re: [PATCH RFC 11/18] drm/scheduler: Clean up jobs when the scheduler is torn down
2023-03-07 14:25 ` [PATCH RFC 11/18] drm/scheduler: Clean up jobs when the scheduler is torn down Asahi Lina
2023-03-08 9:57 ` Maarten Lankhorst
@ 2023-04-05 13:52 ` Daniel Vetter
1 sibling, 0 replies; 122+ messages in thread
From: Daniel Vetter @ 2023-04-05 13:52 UTC (permalink / raw)
To: Asahi Lina
Cc: Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
David Airlie, Daniel Vetter, Miguel Ojeda, Alex Gaynor,
Wedson Almeida Filho, Boqun Feng, Gary Guo, Björn Roy Baron,
Sumit Semwal, Christian König, Luben Tuikov,
Jarkko Sakkinen, Dave Hansen, Alyssa Rosenzweig, Karol Herbst,
Ella Stanforth, Faith Ekstrand, Mary, linux-kernel, dri-devel,
rust-for-linux, linux-media, linaro-mm-sig, linux-sgx, asahi
On Tue, Mar 07, 2023 at 11:25:36PM +0900, Asahi Lina wrote:
> drm_sched_fini() currently leaves any pending jobs dangling, which
> causes segfaults and other badness when job completion fences are
> signaled after the scheduler is torn down.
>
> Explicitly detach all jobs from their completion callbacks and free
> them. This makes it possible to write a sensible safe abstraction for
> drm_sched, without having to externally duplicate the tracking of
> in-flight jobs.
>
> This shouldn't regress any existing drivers, since calling
> drm_sched_fini() with any pending jobs is broken and this change should
> be a no-op if there are no pending jobs.
>
> Signed-off-by: Asahi Lina <lina@asahilina.net>
> ---
> drivers/gpu/drm/scheduler/sched_main.c | 27 +++++++++++++++++++++++++--
> 1 file changed, 25 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/scheduler/sched_main.c b/drivers/gpu/drm/scheduler/sched_main.c
> index 5c0add2c7546..0aab1e0aebdd 100644
> --- a/drivers/gpu/drm/scheduler/sched_main.c
> +++ b/drivers/gpu/drm/scheduler/sched_main.c
> @@ -1119,10 +1119,33 @@ EXPORT_SYMBOL(drm_sched_init);
> void drm_sched_fini(struct drm_gpu_scheduler *sched)
> {
> struct drm_sched_entity *s_entity;
> + struct drm_sched_job *s_job, *tmp;
> int i;
>
> - if (sched->thread)
> - kthread_stop(sched->thread);
> + if (!sched->thread)
> + return;
> +
> + /*
> + * Stop the scheduler, detaching all jobs from their hardware callbacks
> + * and cleaning up complete jobs.
> + */
> + drm_sched_stop(sched, NULL);
> +
> + /*
> + * Iterate through the pending job list and free all jobs.
> + * This assumes the driver has either guaranteed jobs are already stopped, or that
> + * otherwise it is responsible for keeping any necessary data structures for
> + * in-progress jobs alive even when the free_job() callback is called early (e.g. by
> + * putting them in its own queue or doing its own refcounting).
> + */
This comment makes me wonder whether we shouldn't go one step further and
have a drm_sched_quiescent, which waits for any in-flight jobs to complete
and cancels everything else. Because even if rust guarantees that you
don't have any memory bugs, if you just leak things by sprinkling
reference-counted pointer wrappers everywhere you still have a semantic
bug.
Except now it's much harder to realize that because there's no Oops and
KASAN doesn't tell you about it either. I think it would be much better if
the scheduler code and rust abstraction provider drivers the correct
lifetimes and very strongly encourage them to only have borrowed
references and not additional refcounting of their own.
I think Christian mentioned that this would block in close() or context
destruction, which is no good at all. And with the 1:1
drm_scheduler:drm_sched_entity design for there's no other place. This is
way I've suggested in the Xe threads that we should make the current
drm_scheduler an implementation detail hidden from drivers, with a new
drm_scheduler which is always per-engine for all cases as the driver api
interface. And the internal scheduler attached to either that (for
current drivers) or drm_sched_entity (for fw scheduling drivers) as
needed. With that
- the sched_entity cleanup could take care of this code here for the fw
scheduler case
- the drm_sched_fini could take care of blocking appropriately before the
driver is unloaded for any lagging in-flight jobs, without blocking
userspace
- drivers should not end up with any need to reference-count either
per-ctx/drm_sched_entity or per-drm_sched_job data, ever
Because any comment that's along the lines of "drivers need to refcount"
is bad business, because it either means leaks (rust) or crashes (C). I
much prefer when drivers have to put in extra effort to get things wrong
because by default the lifetimes are Just Right(tm).
-Daniel
> + list_for_each_entry_safe(s_job, tmp, &sched->pending_list, list) {
> + spin_lock(&sched->job_list_lock);
> + list_del_init(&s_job->list);
> + spin_unlock(&sched->job_list_lock);
> + sched->ops->free_job(s_job);
> + }
> +
> + kthread_stop(sched->thread);
>
> for (i = DRM_SCHED_PRIORITY_COUNT - 1; i >= DRM_SCHED_PRIORITY_MIN; i--) {
> struct drm_sched_rq *rq = &sched->sched_rq[i];
>
> --
> 2.35.1
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
^ permalink raw reply [flat|nested] 122+ messages in thread
* [PATCH RFC 12/18] rust: drm: sched: Add GPU scheduler abstraction
2023-03-07 14:25 [PATCH RFC 00/18] Rust DRM subsystem abstractions (& preview AGX driver) Asahi Lina
` (10 preceding siblings ...)
2023-03-07 14:25 ` [PATCH RFC 11/18] drm/scheduler: Clean up jobs when the scheduler is torn down Asahi Lina
@ 2023-03-07 14:25 ` Asahi Lina
2023-04-05 15:43 ` Daniel Vetter
2023-03-07 14:25 ` [PATCH RFC 13/18] drm/gem: Add a flag to control whether objects can be exported Asahi Lina
` (6 subsequent siblings)
18 siblings, 1 reply; 122+ messages in thread
From: Asahi Lina @ 2023-03-07 14:25 UTC (permalink / raw)
To: Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
David Airlie, Daniel Vetter, Miguel Ojeda, Alex Gaynor,
Wedson Almeida Filho, Boqun Feng, Gary Guo, Björn Roy Baron,
Sumit Semwal, Christian König, Luben Tuikov,
Jarkko Sakkinen, Dave Hansen
Cc: Alyssa Rosenzweig, Karol Herbst, Ella Stanforth, Faith Ekstrand,
Mary, linux-kernel, dri-devel, rust-for-linux, linux-media,
linaro-mm-sig, linux-sgx, asahi, Asahi Lina
The GPU scheduler manages scheduling GPU jobs and dependencies between
them. This Rust abstraction allows Rust DRM drivers to use this
functionality.
Signed-off-by: Asahi Lina <lina@asahilina.net>
---
drivers/gpu/drm/Kconfig | 5 +
rust/bindings/bindings_helper.h | 1 +
rust/helpers.c | 6 +
rust/kernel/drm/mod.rs | 2 +
rust/kernel/drm/sched.rs | 358 ++++++++++++++++++++++++++++++++++++++++
5 files changed, 372 insertions(+)
diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index 70a983a17ac2..8b5ad6aee126 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -39,6 +39,11 @@ config RUST_DRM_GEM_SHMEM_HELPER
depends on RUST_DRM
select DRM_GEM_SHMEM_HELPER
+config RUST_DRM_SCHED
+ bool
+ depends on RUST_DRM
+ select DRM_SCHED
+
config DRM_MIPI_DBI
tristate
depends on DRM
diff --git a/rust/bindings/bindings_helper.h b/rust/bindings/bindings_helper.h
index b6696011f3a4..dc01be08676e 100644
--- a/rust/bindings/bindings_helper.h
+++ b/rust/bindings/bindings_helper.h
@@ -13,6 +13,7 @@
#include <drm/drm_gem_shmem_helper.h>
#include <drm/drm_ioctl.h>
#include <drm/drm_syncobj.h>
+#include <drm/gpu_scheduler.h>
#include <linux/delay.h>
#include <linux/device.h>
#include <linux/dma-fence.h>
diff --git a/rust/helpers.c b/rust/helpers.c
index 11965b1e2f4e..1b33ed602090 100644
--- a/rust/helpers.c
+++ b/rust/helpers.c
@@ -408,6 +408,12 @@ void rust_helper___spin_lock_init(spinlock_t *lock, const char *name,
}
EXPORT_SYMBOL_GPL(rust_helper___spin_lock_init);
+unsigned long rust_helper_msecs_to_jiffies(const unsigned int m)
+{
+ return msecs_to_jiffies(m);
+}
+EXPORT_SYMBOL_GPL(rust_helper_msecs_to_jiffies);
+
#ifdef CONFIG_DMA_SHARED_BUFFER
void rust_helper_dma_fence_get(struct dma_fence *fence)
diff --git a/rust/kernel/drm/mod.rs b/rust/kernel/drm/mod.rs
index dae98826edfd..3ddf7712aab3 100644
--- a/rust/kernel/drm/mod.rs
+++ b/rust/kernel/drm/mod.rs
@@ -8,4 +8,6 @@ pub mod file;
pub mod gem;
pub mod ioctl;
pub mod mm;
+#[cfg(CONFIG_RUST_DRM_SCHED)]
+pub mod sched;
pub mod syncobj;
diff --git a/rust/kernel/drm/sched.rs b/rust/kernel/drm/sched.rs
new file mode 100644
index 000000000000..a5275cc16179
--- /dev/null
+++ b/rust/kernel/drm/sched.rs
@@ -0,0 +1,358 @@
+// SPDX-License-Identifier: GPL-2.0 OR MIT
+
+//! DRM Scheduler
+//!
+//! C header: [`include/linux/drm/gpu_scheduler.h`](../../../../include/linux/drm/gpu_scheduler.h)
+
+use crate::{
+ bindings, device,
+ dma_fence::*,
+ error::{to_result, Result},
+ prelude::*,
+ sync::{Arc, UniqueArc},
+};
+use alloc::boxed::Box;
+use core::marker::PhantomData;
+use core::mem::MaybeUninit;
+use core::ops::{Deref, DerefMut};
+use core::ptr::addr_of_mut;
+
+/// Scheduler status after timeout recovery
+#[repr(u32)]
+pub enum Status {
+ /// Device recovered from the timeout and can execute jobs again
+ Nominal = bindings::drm_gpu_sched_stat_DRM_GPU_SCHED_STAT_NOMINAL,
+ /// Device is no longer available
+ NoDevice = bindings::drm_gpu_sched_stat_DRM_GPU_SCHED_STAT_ENODEV,
+}
+
+/// Scheduler priorities
+#[repr(i32)]
+pub enum Priority {
+ /// Low userspace priority
+ Min = bindings::drm_sched_priority_DRM_SCHED_PRIORITY_MIN,
+ /// Normal userspace priority
+ Normal = bindings::drm_sched_priority_DRM_SCHED_PRIORITY_NORMAL,
+ /// High userspace priority
+ High = bindings::drm_sched_priority_DRM_SCHED_PRIORITY_HIGH,
+ /// Kernel priority (highest)
+ Kernel = bindings::drm_sched_priority_DRM_SCHED_PRIORITY_KERNEL,
+}
+
+/// Trait to be implemented by driver job objects.
+pub trait JobImpl: Sized {
+ /// Called when the scheduler is considering scheduling this job next, to get another Fence
+ /// for this job to block on. Once it returns None, run() may be called.
+ fn prepare(_job: &mut Job<Self>) -> Option<Fence> {
+ None // Equivalent to NULL function pointer
+ }
+
+ /// Called before job execution to check whether the hardware is free enough to run the job.
+ /// This can be used to implement more complex hardware resource policies than the hw_submission
+ /// limit.
+ fn can_run(_job: &mut Job<Self>) -> bool {
+ true
+ }
+
+ /// Called to execute the job once all of the dependencies have been resolved. This may be
+ /// called multiple times, if timed_out() has happened and drm_sched_job_recovery() decides
+ /// to try it again.
+ fn run(job: &mut Job<Self>) -> Result<Option<Fence>>;
+
+ /// Called when a job has taken too long to execute, to trigger GPU recovery.
+ ///
+ /// This method is called in a workqueue context.
+ fn timed_out(job: &mut Job<Self>) -> Status;
+}
+
+unsafe extern "C" fn prepare_job_cb<T: JobImpl>(
+ sched_job: *mut bindings::drm_sched_job,
+ _s_entity: *mut bindings::drm_sched_entity,
+) -> *mut bindings::dma_fence {
+ // SAFETY: All of our jobs are Job<T>.
+ let p = crate::container_of!(sched_job, Job<T>, job) as *mut Job<T>;
+
+ match T::prepare(unsafe { &mut *p }) {
+ None => core::ptr::null_mut(),
+ Some(fence) => fence.into_raw(),
+ }
+}
+
+unsafe extern "C" fn run_job_cb<T: JobImpl>(
+ sched_job: *mut bindings::drm_sched_job,
+) -> *mut bindings::dma_fence {
+ // SAFETY: All of our jobs are Job<T>.
+ let p = crate::container_of!(sched_job, Job<T>, job) as *mut Job<T>;
+
+ match T::run(unsafe { &mut *p }) {
+ Err(e) => e.to_ptr(),
+ Ok(None) => core::ptr::null_mut(),
+ Ok(Some(fence)) => fence.into_raw(),
+ }
+}
+
+unsafe extern "C" fn can_run_job_cb<T: JobImpl>(sched_job: *mut bindings::drm_sched_job) -> bool {
+ // SAFETY: All of our jobs are Job<T>.
+ let p = crate::container_of!(sched_job, Job<T>, job) as *mut Job<T>;
+
+ T::can_run(unsafe { &mut *p })
+}
+
+unsafe extern "C" fn timedout_job_cb<T: JobImpl>(
+ sched_job: *mut bindings::drm_sched_job,
+) -> bindings::drm_gpu_sched_stat {
+ // SAFETY: All of our jobs are Job<T>.
+ let p = crate::container_of!(sched_job, Job<T>, job) as *mut Job<T>;
+
+ T::timed_out(unsafe { &mut *p }) as bindings::drm_gpu_sched_stat
+}
+
+unsafe extern "C" fn free_job_cb<T: JobImpl>(sched_job: *mut bindings::drm_sched_job) {
+ // SAFETY: All of our jobs are Job<T>.
+ let p = crate::container_of!(sched_job, Job<T>, job) as *mut Job<T>;
+
+ // Convert the job back to a Box and drop it
+ // SAFETY: All of our Job<T>s are created inside a box.
+ unsafe { Box::from_raw(p) };
+}
+
+/// A DRM scheduler job.
+pub struct Job<T: JobImpl> {
+ job: bindings::drm_sched_job,
+ inner: T,
+}
+
+impl<T: JobImpl> Deref for Job<T> {
+ type Target = T;
+
+ fn deref(&self) -> &Self::Target {
+ &self.inner
+ }
+}
+
+impl<T: JobImpl> DerefMut for Job<T> {
+ fn deref_mut(&mut self) -> &mut Self::Target {
+ &mut self.inner
+ }
+}
+
+impl<T: JobImpl> Drop for Job<T> {
+ fn drop(&mut self) {
+ // SAFETY: At this point the job has either been submitted and this is being called from
+ // `free_job_cb` above, or it hasn't and it is safe to call `drm_sched_job_cleanup`.
+ unsafe { bindings::drm_sched_job_cleanup(&mut self.job) };
+ }
+}
+
+/// A pending DRM scheduler job (not yet armed)
+pub struct PendingJob<'a, T: JobImpl>(Box<Job<T>>, PhantomData<&'a T>);
+
+impl<'a, T: JobImpl> PendingJob<'a, T> {
+ /// Add a fence as a dependency to the job
+ pub fn add_dependency(&mut self, fence: Fence) -> Result {
+ to_result(unsafe {
+ bindings::drm_sched_job_add_dependency(&mut self.0.job, fence.into_raw())
+ })
+ }
+
+ /// Arm the job to make it ready for execution
+ pub fn arm(mut self) -> ArmedJob<'a, T> {
+ unsafe { bindings::drm_sched_job_arm(&mut self.0.job) };
+ ArmedJob(self.0, PhantomData)
+ }
+}
+
+impl<'a, T: JobImpl> Deref for PendingJob<'a, T> {
+ type Target = Job<T>;
+
+ fn deref(&self) -> &Self::Target {
+ &self.0
+ }
+}
+
+impl<'a, T: JobImpl> DerefMut for PendingJob<'a, T> {
+ fn deref_mut(&mut self) -> &mut Self::Target {
+ &mut self.0
+ }
+}
+
+/// An armed DRM scheduler job (not yet submitted)
+pub struct ArmedJob<'a, T: JobImpl>(Box<Job<T>>, PhantomData<&'a T>);
+
+impl<'a, T: JobImpl> ArmedJob<'a, T> {
+ /// Returns the job fences
+ pub fn fences(&self) -> JobFences<'_> {
+ JobFences(unsafe { &mut *self.0.job.s_fence })
+ }
+
+ /// Push the job for execution into the scheduler
+ pub fn push(self) {
+ // After this point, the job is submitted and owned by the scheduler
+ let ptr = match self {
+ ArmedJob(job, _) => Box::<Job<T>>::into_raw(job),
+ };
+
+ // SAFETY: We are passing in ownership of a valid Box raw pointer.
+ unsafe { bindings::drm_sched_entity_push_job(addr_of_mut!((*ptr).job)) };
+ }
+}
+impl<'a, T: JobImpl> Deref for ArmedJob<'a, T> {
+ type Target = Job<T>;
+
+ fn deref(&self) -> &Self::Target {
+ &self.0
+ }
+}
+
+impl<'a, T: JobImpl> DerefMut for ArmedJob<'a, T> {
+ fn deref_mut(&mut self) -> &mut Self::Target {
+ &mut self.0
+ }
+}
+
+/// Reference to the bundle of fences attached to a DRM scheduler job
+pub struct JobFences<'a>(&'a mut bindings::drm_sched_fence);
+
+impl<'a> JobFences<'a> {
+ /// Returns a new reference to the job scheduled fence.
+ pub fn scheduled(&mut self) -> Fence {
+ unsafe { Fence::get_raw(&mut self.0.scheduled) }
+ }
+
+ /// Returns a new reference to the job finished fence.
+ pub fn finished(&mut self) -> Fence {
+ unsafe { Fence::get_raw(&mut self.0.finished) }
+ }
+}
+
+struct EntityInner<T: JobImpl> {
+ entity: bindings::drm_sched_entity,
+ // TODO: Allow users to share guilty flag between entities
+ sched: Arc<SchedulerInner<T>>,
+ guilty: bindings::atomic_t,
+ _p: PhantomData<T>,
+}
+
+impl<T: JobImpl> Drop for EntityInner<T> {
+ fn drop(&mut self) {
+ // SAFETY: The EntityInner is initialized. This will cancel/free all jobs.
+ unsafe { bindings::drm_sched_entity_destroy(&mut self.entity) };
+ }
+}
+
+// SAFETY: TODO
+unsafe impl<T: JobImpl> Sync for EntityInner<T> {}
+unsafe impl<T: JobImpl> Send for EntityInner<T> {}
+
+/// A DRM scheduler entity.
+pub struct Entity<T: JobImpl>(Pin<Box<EntityInner<T>>>);
+
+impl<T: JobImpl> Entity<T> {
+ /// Create a new scheduler entity.
+ pub fn new(sched: &Scheduler<T>, priority: Priority) -> Result<Self> {
+ let mut entity: Box<MaybeUninit<EntityInner<T>>> = Box::try_new_zeroed()?;
+
+ let mut sched_ptr = &sched.0.sched as *const _ as *mut _;
+
+ // SAFETY: The Box is allocated above and valid.
+ unsafe {
+ bindings::drm_sched_entity_init(
+ addr_of_mut!((*entity.as_mut_ptr()).entity),
+ priority as _,
+ &mut sched_ptr,
+ 1,
+ addr_of_mut!((*entity.as_mut_ptr()).guilty),
+ )
+ };
+
+ // SAFETY: The Box is allocated above and valid.
+ unsafe { addr_of_mut!((*entity.as_mut_ptr()).sched).write(sched.0.clone()) };
+
+ // SAFETY: entity is now initialized.
+ Ok(Self(Pin::from(unsafe { entity.assume_init() })))
+ }
+
+ /// Create a new job on this entity.
+ ///
+ /// The entity must outlive the pending job until it transitions into the submitted state,
+ /// after which the scheduler owns it.
+ pub fn new_job(&self, inner: T) -> Result<PendingJob<'_, T>> {
+ let mut job: Box<MaybeUninit<Job<T>>> = Box::try_new_zeroed()?;
+
+ // SAFETY: We hold a reference to the entity (which is a valid pointer),
+ // and the job object was just allocated above.
+ to_result(unsafe {
+ bindings::drm_sched_job_init(
+ addr_of_mut!((*job.as_mut_ptr()).job),
+ &self.0.as_ref().get_ref().entity as *const _ as *mut _,
+ core::ptr::null_mut(),
+ )
+ })?;
+
+ // SAFETY: The Box pointer is valid, and this initializes the inner member.
+ unsafe { addr_of_mut!((*job.as_mut_ptr()).inner).write(inner) };
+
+ // SAFETY: All fields of the Job<T> are now initialized.
+ Ok(PendingJob(unsafe { job.assume_init() }, PhantomData))
+ }
+}
+
+/// DRM scheduler inner data
+pub struct SchedulerInner<T: JobImpl> {
+ sched: bindings::drm_gpu_scheduler,
+ _p: PhantomData<T>,
+}
+
+impl<T: JobImpl> Drop for SchedulerInner<T> {
+ fn drop(&mut self) {
+ // SAFETY: The scheduler is valid. This assumes drm_sched_fini() will take care of
+ // freeing all in-progress jobs.
+ unsafe { bindings::drm_sched_fini(&mut self.sched) };
+ }
+}
+
+// SAFETY: TODO
+unsafe impl<T: JobImpl> Sync for SchedulerInner<T> {}
+unsafe impl<T: JobImpl> Send for SchedulerInner<T> {}
+
+/// A DRM Scheduler
+pub struct Scheduler<T: JobImpl>(Arc<SchedulerInner<T>>);
+
+impl<T: JobImpl> Scheduler<T> {
+ const OPS: bindings::drm_sched_backend_ops = bindings::drm_sched_backend_ops {
+ prepare_job: Some(prepare_job_cb::<T>),
+ can_run_job: Some(can_run_job_cb::<T>),
+ run_job: Some(run_job_cb::<T>),
+ timedout_job: Some(timedout_job_cb::<T>),
+ free_job: Some(free_job_cb::<T>),
+ };
+ /// Creates a new DRM Scheduler object
+ // TODO: Shared timeout workqueues & scores
+ pub fn new(
+ device: &impl device::RawDevice,
+ hw_submission: u32,
+ hang_limit: u32,
+ timeout_ms: usize,
+ name: &'static CStr,
+ ) -> Result<Scheduler<T>> {
+ let mut sched: UniqueArc<MaybeUninit<SchedulerInner<T>>> = UniqueArc::try_new_uninit()?;
+
+ // SAFETY: The drm_sched pointer is valid and pinned as it was just allocated above.
+ to_result(unsafe {
+ bindings::drm_sched_init(
+ addr_of_mut!((*sched.as_mut_ptr()).sched),
+ &Self::OPS,
+ hw_submission,
+ hang_limit,
+ bindings::msecs_to_jiffies(timeout_ms.try_into()?).try_into()?,
+ core::ptr::null_mut(),
+ core::ptr::null_mut(),
+ name.as_char_ptr(),
+ device.raw_device(),
+ )
+ })?;
+
+ // SAFETY: All fields of SchedulerInner are now initialized.
+ Ok(Scheduler(unsafe { sched.assume_init() }.into()))
+ }
+}
--
2.35.1
^ permalink raw reply related [flat|nested] 122+ messages in thread* Re: [PATCH RFC 12/18] rust: drm: sched: Add GPU scheduler abstraction
2023-03-07 14:25 ` [PATCH RFC 12/18] rust: drm: sched: Add GPU scheduler abstraction Asahi Lina
@ 2023-04-05 15:43 ` Daniel Vetter
2023-04-05 19:29 ` Daniel Vetter
0 siblings, 1 reply; 122+ messages in thread
From: Daniel Vetter @ 2023-04-05 15:43 UTC (permalink / raw)
To: Asahi Lina
Cc: Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
David Airlie, Daniel Vetter, Miguel Ojeda, Alex Gaynor,
Wedson Almeida Filho, Boqun Feng, Gary Guo, Björn Roy Baron,
Sumit Semwal, Christian König, Luben Tuikov,
Jarkko Sakkinen, Dave Hansen, Alyssa Rosenzweig, Karol Herbst,
Ella Stanforth, Faith Ekstrand, Mary, linux-kernel, dri-devel,
rust-for-linux, linux-media, linaro-mm-sig, linux-sgx, asahi
On Tue, Mar 07, 2023 at 11:25:37PM +0900, Asahi Lina wrote:
> The GPU scheduler manages scheduling GPU jobs and dependencies between
> them. This Rust abstraction allows Rust DRM drivers to use this
> functionality.
>
> Signed-off-by: Asahi Lina <lina@asahilina.net>
Overall (with my limited rust knowledge) I really like this, it nicely
encodes the state transitions of jobs and anything else I looked into.
Some thoughts/questions below.
> ---
> drivers/gpu/drm/Kconfig | 5 +
> rust/bindings/bindings_helper.h | 1 +
> rust/helpers.c | 6 +
> rust/kernel/drm/mod.rs | 2 +
> rust/kernel/drm/sched.rs | 358 ++++++++++++++++++++++++++++++++++++++++
> 5 files changed, 372 insertions(+)
>
> diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
> index 70a983a17ac2..8b5ad6aee126 100644
> --- a/drivers/gpu/drm/Kconfig
> +++ b/drivers/gpu/drm/Kconfig
> @@ -39,6 +39,11 @@ config RUST_DRM_GEM_SHMEM_HELPER
> depends on RUST_DRM
> select DRM_GEM_SHMEM_HELPER
>
> +config RUST_DRM_SCHED
> + bool
> + depends on RUST_DRM
> + select DRM_SCHED
> +
> config DRM_MIPI_DBI
> tristate
> depends on DRM
> diff --git a/rust/bindings/bindings_helper.h b/rust/bindings/bindings_helper.h
> index b6696011f3a4..dc01be08676e 100644
> --- a/rust/bindings/bindings_helper.h
> +++ b/rust/bindings/bindings_helper.h
> @@ -13,6 +13,7 @@
> #include <drm/drm_gem_shmem_helper.h>
> #include <drm/drm_ioctl.h>
> #include <drm/drm_syncobj.h>
> +#include <drm/gpu_scheduler.h>
> #include <linux/delay.h>
> #include <linux/device.h>
> #include <linux/dma-fence.h>
> diff --git a/rust/helpers.c b/rust/helpers.c
> index 11965b1e2f4e..1b33ed602090 100644
> --- a/rust/helpers.c
> +++ b/rust/helpers.c
> @@ -408,6 +408,12 @@ void rust_helper___spin_lock_init(spinlock_t *lock, const char *name,
> }
> EXPORT_SYMBOL_GPL(rust_helper___spin_lock_init);
>
> +unsigned long rust_helper_msecs_to_jiffies(const unsigned int m)
> +{
> + return msecs_to_jiffies(m);
> +}
> +EXPORT_SYMBOL_GPL(rust_helper_msecs_to_jiffies);
> +
> #ifdef CONFIG_DMA_SHARED_BUFFER
>
> void rust_helper_dma_fence_get(struct dma_fence *fence)
> diff --git a/rust/kernel/drm/mod.rs b/rust/kernel/drm/mod.rs
> index dae98826edfd..3ddf7712aab3 100644
> --- a/rust/kernel/drm/mod.rs
> +++ b/rust/kernel/drm/mod.rs
> @@ -8,4 +8,6 @@ pub mod file;
> pub mod gem;
> pub mod ioctl;
> pub mod mm;
> +#[cfg(CONFIG_RUST_DRM_SCHED)]
> +pub mod sched;
> pub mod syncobj;
> diff --git a/rust/kernel/drm/sched.rs b/rust/kernel/drm/sched.rs
> new file mode 100644
> index 000000000000..a5275cc16179
> --- /dev/null
> +++ b/rust/kernel/drm/sched.rs
> @@ -0,0 +1,358 @@
> +// SPDX-License-Identifier: GPL-2.0 OR MIT
> +
> +//! DRM Scheduler
> +//!
> +//! C header: [`include/linux/drm/gpu_scheduler.h`](../../../../include/linux/drm/gpu_scheduler.h)
> +
> +use crate::{
> + bindings, device,
> + dma_fence::*,
> + error::{to_result, Result},
> + prelude::*,
> + sync::{Arc, UniqueArc},
> +};
> +use alloc::boxed::Box;
> +use core::marker::PhantomData;
> +use core::mem::MaybeUninit;
> +use core::ops::{Deref, DerefMut};
> +use core::ptr::addr_of_mut;
> +
> +/// Scheduler status after timeout recovery
> +#[repr(u32)]
> +pub enum Status {
> + /// Device recovered from the timeout and can execute jobs again
> + Nominal = bindings::drm_gpu_sched_stat_DRM_GPU_SCHED_STAT_NOMINAL,
> + /// Device is no longer available
> + NoDevice = bindings::drm_gpu_sched_stat_DRM_GPU_SCHED_STAT_ENODEV,
> +}
> +
> +/// Scheduler priorities
> +#[repr(i32)]
> +pub enum Priority {
> + /// Low userspace priority
> + Min = bindings::drm_sched_priority_DRM_SCHED_PRIORITY_MIN,
> + /// Normal userspace priority
> + Normal = bindings::drm_sched_priority_DRM_SCHED_PRIORITY_NORMAL,
> + /// High userspace priority
> + High = bindings::drm_sched_priority_DRM_SCHED_PRIORITY_HIGH,
> + /// Kernel priority (highest)
> + Kernel = bindings::drm_sched_priority_DRM_SCHED_PRIORITY_KERNEL,
> +}
> +
> +/// Trait to be implemented by driver job objects.
> +pub trait JobImpl: Sized {
> + /// Called when the scheduler is considering scheduling this job next, to get another Fence
> + /// for this job to block on. Once it returns None, run() may be called.
> + fn prepare(_job: &mut Job<Self>) -> Option<Fence> {
So if I get this all right then Job<T> allows us to nicely parametrize the
job with the driver structure itself, but not really anything else. I do
wonder whether this needs a bit more with a type both for the job and
entity and the drm/sched code + rust wrapper guaranteeing that the
lifetimes of these make sense. With just the job parametrized drivers need
to make sure they refcount anything else hanging of that properly which
means if they get some detail wrong there might be an unintentional leak.
If we instead also give a parametrized entity where the driver can stuff
anything necessary and sched code guarantees that it'll clean up the any
mess on teardown and guarantee that the entity survives, I think a lot of
drivers could benefit from that and it would be easier for them to have
the right lifetimes for everything and no leaks.
> + None // Equivalent to NULL function pointer
> + }
> +
> + /// Called before job execution to check whether the hardware is free enough to run the job.
> + /// This can be used to implement more complex hardware resource policies than the hw_submission
> + /// limit.
> + fn can_run(_job: &mut Job<Self>) -> bool {
> + true
> + }
> +
> + /// Called to execute the job once all of the dependencies have been resolved. This may be
> + /// called multiple times, if timed_out() has happened and drm_sched_job_recovery() decides
> + /// to try it again.
> + fn run(job: &mut Job<Self>) -> Result<Option<Fence>>;
> +
> + /// Called when a job has taken too long to execute, to trigger GPU recovery.
> + ///
> + /// This method is called in a workqueue context.
> + fn timed_out(job: &mut Job<Self>) -> Status;
> +}
> +
> +unsafe extern "C" fn prepare_job_cb<T: JobImpl>(
> + sched_job: *mut bindings::drm_sched_job,
> + _s_entity: *mut bindings::drm_sched_entity,
> +) -> *mut bindings::dma_fence {
> + // SAFETY: All of our jobs are Job<T>.
> + let p = crate::container_of!(sched_job, Job<T>, job) as *mut Job<T>;
> +
> + match T::prepare(unsafe { &mut *p }) {
> + None => core::ptr::null_mut(),
> + Some(fence) => fence.into_raw(),
> + }
> +}
> +
> +unsafe extern "C" fn run_job_cb<T: JobImpl>(
> + sched_job: *mut bindings::drm_sched_job,
> +) -> *mut bindings::dma_fence {
> + // SAFETY: All of our jobs are Job<T>.
> + let p = crate::container_of!(sched_job, Job<T>, job) as *mut Job<T>;
> +
> + match T::run(unsafe { &mut *p }) {
> + Err(e) => e.to_ptr(),
> + Ok(None) => core::ptr::null_mut(),
> + Ok(Some(fence)) => fence.into_raw(),
> + }
> +}
> +
> +unsafe extern "C" fn can_run_job_cb<T: JobImpl>(sched_job: *mut bindings::drm_sched_job) -> bool {
> + // SAFETY: All of our jobs are Job<T>.
> + let p = crate::container_of!(sched_job, Job<T>, job) as *mut Job<T>;
> +
> + T::can_run(unsafe { &mut *p })
> +}
> +
> +unsafe extern "C" fn timedout_job_cb<T: JobImpl>(
> + sched_job: *mut bindings::drm_sched_job,
> +) -> bindings::drm_gpu_sched_stat {
> + // SAFETY: All of our jobs are Job<T>.
> + let p = crate::container_of!(sched_job, Job<T>, job) as *mut Job<T>;
> +
> + T::timed_out(unsafe { &mut *p }) as bindings::drm_gpu_sched_stat
> +}
> +
> +unsafe extern "C" fn free_job_cb<T: JobImpl>(sched_job: *mut bindings::drm_sched_job) {
> + // SAFETY: All of our jobs are Job<T>.
> + let p = crate::container_of!(sched_job, Job<T>, job) as *mut Job<T>;
> +
> + // Convert the job back to a Box and drop it
> + // SAFETY: All of our Job<T>s are created inside a box.
> + unsafe { Box::from_raw(p) };
> +}
> +
> +/// A DRM scheduler job.
> +pub struct Job<T: JobImpl> {
> + job: bindings::drm_sched_job,
> + inner: T,
> +}
> +
> +impl<T: JobImpl> Deref for Job<T> {
> + type Target = T;
> +
> + fn deref(&self) -> &Self::Target {
> + &self.inner
> + }
> +}
> +
> +impl<T: JobImpl> DerefMut for Job<T> {
> + fn deref_mut(&mut self) -> &mut Self::Target {
> + &mut self.inner
> + }
> +}
> +
> +impl<T: JobImpl> Drop for Job<T> {
> + fn drop(&mut self) {
> + // SAFETY: At this point the job has either been submitted and this is being called from
> + // `free_job_cb` above, or it hasn't and it is safe to call `drm_sched_job_cleanup`.
> + unsafe { bindings::drm_sched_job_cleanup(&mut self.job) };
> + }
> +}
> +
> +/// A pending DRM scheduler job (not yet armed)
> +pub struct PendingJob<'a, T: JobImpl>(Box<Job<T>>, PhantomData<&'a T>);
> +
> +impl<'a, T: JobImpl> PendingJob<'a, T> {
> + /// Add a fence as a dependency to the job
> + pub fn add_dependency(&mut self, fence: Fence) -> Result {
> + to_result(unsafe {
> + bindings::drm_sched_job_add_dependency(&mut self.0.job, fence.into_raw())
> + })
> + }
> +
> + /// Arm the job to make it ready for execution
> + pub fn arm(mut self) -> ArmedJob<'a, T> {
> + unsafe { bindings::drm_sched_job_arm(&mut self.0.job) };
> + ArmedJob(self.0, PhantomData)
> + }
> +}
> +
> +impl<'a, T: JobImpl> Deref for PendingJob<'a, T> {
> + type Target = Job<T>;
> +
> + fn deref(&self) -> &Self::Target {
> + &self.0
> + }
> +}
> +
> +impl<'a, T: JobImpl> DerefMut for PendingJob<'a, T> {
> + fn deref_mut(&mut self) -> &mut Self::Target {
> + &mut self.0
> + }
> +}
> +
> +/// An armed DRM scheduler job (not yet submitted)
> +pub struct ArmedJob<'a, T: JobImpl>(Box<Job<T>>, PhantomData<&'a T>);
> +
> +impl<'a, T: JobImpl> ArmedJob<'a, T> {
> + /// Returns the job fences
> + pub fn fences(&self) -> JobFences<'_> {
> + JobFences(unsafe { &mut *self.0.job.s_fence })
> + }
> +
> + /// Push the job for execution into the scheduler
> + pub fn push(self) {
> + // After this point, the job is submitted and owned by the scheduler
> + let ptr = match self {
> + ArmedJob(job, _) => Box::<Job<T>>::into_raw(job),
> + };
If I get this all right then this all makes sure that drivers can't use
the job after push and they don't forgot to call arm.
What I'm not seeing is how we force drivers to call push once they've
called arm? I haven't check what the code does, but from the docs it
sounds like if you don't call push then drop will get called. Which wreaks
the book-keeping on an armed job. Or is there someting that prevents
ArmedJob<T> from having the Drop trait and so the only way to not go boom
is by pushing it?
Googling for "rust undroppable" seems to indicate that this isn't a thing
rust can do?
> +
> + // SAFETY: We are passing in ownership of a valid Box raw pointer.
> + unsafe { bindings::drm_sched_entity_push_job(addr_of_mut!((*ptr).job)) };
> + }
> +}
> +impl<'a, T: JobImpl> Deref for ArmedJob<'a, T> {
> + type Target = Job<T>;
> +
> + fn deref(&self) -> &Self::Target {
> + &self.0
> + }
> +}
> +
> +impl<'a, T: JobImpl> DerefMut for ArmedJob<'a, T> {
> + fn deref_mut(&mut self) -> &mut Self::Target {
> + &mut self.0
> + }
> +}
> +
> +/// Reference to the bundle of fences attached to a DRM scheduler job
> +pub struct JobFences<'a>(&'a mut bindings::drm_sched_fence);
> +
> +impl<'a> JobFences<'a> {
> + /// Returns a new reference to the job scheduled fence.
> + pub fn scheduled(&mut self) -> Fence {
> + unsafe { Fence::get_raw(&mut self.0.scheduled) }
This feels a bit murky, because the safety of this relies on the safety of
the ArmedJob and the guarantee (promise?) that the driver will push it.
I'd just have two functions scheduled_fence and finished_fence in the
ArmedJob impl and one safety note explaining why we can wrap it in the
refcounted Fence.
> + }
> +
> + /// Returns a new reference to the job finished fence.
> + pub fn finished(&mut self) -> Fence {
> + unsafe { Fence::get_raw(&mut self.0.finished) }
> + }
> +}
> +
> +struct EntityInner<T: JobImpl> {
> + entity: bindings::drm_sched_entity,
> + // TODO: Allow users to share guilty flag between entities
> + sched: Arc<SchedulerInner<T>>,
> + guilty: bindings::atomic_t,
> + _p: PhantomData<T>,
> +}
> +
> +impl<T: JobImpl> Drop for EntityInner<T> {
> + fn drop(&mut self) {
> + // SAFETY: The EntityInner is initialized. This will cancel/free all jobs.
> + unsafe { bindings::drm_sched_entity_destroy(&mut self.entity) };
> + }
> +}
> +
> +// SAFETY: TODO
> +unsafe impl<T: JobImpl> Sync for EntityInner<T> {}
> +unsafe impl<T: JobImpl> Send for EntityInner<T> {}
> +
> +/// A DRM scheduler entity.
> +pub struct Entity<T: JobImpl>(Pin<Box<EntityInner<T>>>);
> +
> +impl<T: JobImpl> Entity<T> {
> + /// Create a new scheduler entity.
> + pub fn new(sched: &Scheduler<T>, priority: Priority) -> Result<Self> {
> + let mut entity: Box<MaybeUninit<EntityInner<T>>> = Box::try_new_zeroed()?;
> +
> + let mut sched_ptr = &sched.0.sched as *const _ as *mut _;
> +
> + // SAFETY: The Box is allocated above and valid.
> + unsafe {
> + bindings::drm_sched_entity_init(
> + addr_of_mut!((*entity.as_mut_ptr()).entity),
> + priority as _,
> + &mut sched_ptr,
> + 1,
> + addr_of_mut!((*entity.as_mut_ptr()).guilty),
> + )
> + };
> +
> + // SAFETY: The Box is allocated above and valid.
> + unsafe { addr_of_mut!((*entity.as_mut_ptr()).sched).write(sched.0.clone()) };
> +
> + // SAFETY: entity is now initialized.
> + Ok(Self(Pin::from(unsafe { entity.assume_init() })))
> + }
> +
> + /// Create a new job on this entity.
> + ///
> + /// The entity must outlive the pending job until it transitions into the submitted state,
> + /// after which the scheduler owns it.
> + pub fn new_job(&self, inner: T) -> Result<PendingJob<'_, T>> {
> + let mut job: Box<MaybeUninit<Job<T>>> = Box::try_new_zeroed()?;
> +
> + // SAFETY: We hold a reference to the entity (which is a valid pointer),
> + // and the job object was just allocated above.
> + to_result(unsafe {
> + bindings::drm_sched_job_init(
> + addr_of_mut!((*job.as_mut_ptr()).job),
> + &self.0.as_ref().get_ref().entity as *const _ as *mut _,
> + core::ptr::null_mut(),
> + )
> + })?;
> +
> + // SAFETY: The Box pointer is valid, and this initializes the inner member.
> + unsafe { addr_of_mut!((*job.as_mut_ptr()).inner).write(inner) };
> +
> + // SAFETY: All fields of the Job<T> are now initialized.
> + Ok(PendingJob(unsafe { job.assume_init() }, PhantomData))
> + }
> +}
> +
> +/// DRM scheduler inner data
> +pub struct SchedulerInner<T: JobImpl> {
> + sched: bindings::drm_gpu_scheduler,
> + _p: PhantomData<T>,
> +}
> +
> +impl<T: JobImpl> Drop for SchedulerInner<T> {
> + fn drop(&mut self) {
> + // SAFETY: The scheduler is valid. This assumes drm_sched_fini() will take care of
> + // freeing all in-progress jobs.
> + unsafe { bindings::drm_sched_fini(&mut self.sched) };
> + }
> +}
> +
> +// SAFETY: TODO
> +unsafe impl<T: JobImpl> Sync for SchedulerInner<T> {}
> +unsafe impl<T: JobImpl> Send for SchedulerInner<T> {}
> +
> +/// A DRM Scheduler
> +pub struct Scheduler<T: JobImpl>(Arc<SchedulerInner<T>>);
> +
> +impl<T: JobImpl> Scheduler<T> {
> + const OPS: bindings::drm_sched_backend_ops = bindings::drm_sched_backend_ops {
> + prepare_job: Some(prepare_job_cb::<T>),
> + can_run_job: Some(can_run_job_cb::<T>),
> + run_job: Some(run_job_cb::<T>),
> + timedout_job: Some(timedout_job_cb::<T>),
> + free_job: Some(free_job_cb::<T>),
Two general questions with no relevance here really, just about vtable
best practices:
So the trait has default impls for exactly the functions that are optional
here, but either way we always end up with non-NULL function pointers. I
guess there's no way to avoid that when you have a nice wrapping with
traits and all that like here?
Another unrelated thing: How const is const? The C code side generally
uses ops pointers for runtime time casting, so if the const is less const
that a naive C hacker would expect, it might result in some fun.
Cheers, Daniel
> + };
> + /// Creates a new DRM Scheduler object
> + // TODO: Shared timeout workqueues & scores
> + pub fn new(
> + device: &impl device::RawDevice,
> + hw_submission: u32,
> + hang_limit: u32,
> + timeout_ms: usize,
> + name: &'static CStr,
> + ) -> Result<Scheduler<T>> {
> + let mut sched: UniqueArc<MaybeUninit<SchedulerInner<T>>> = UniqueArc::try_new_uninit()?;
> +
> + // SAFETY: The drm_sched pointer is valid and pinned as it was just allocated above.
> + to_result(unsafe {
> + bindings::drm_sched_init(
> + addr_of_mut!((*sched.as_mut_ptr()).sched),
> + &Self::OPS,
> + hw_submission,
> + hang_limit,
> + bindings::msecs_to_jiffies(timeout_ms.try_into()?).try_into()?,
> + core::ptr::null_mut(),
> + core::ptr::null_mut(),
> + name.as_char_ptr(),
> + device.raw_device(),
> + )
> + })?;
> +
> + // SAFETY: All fields of SchedulerInner are now initialized.
> + Ok(Scheduler(unsafe { sched.assume_init() }.into()))
> + }
> +}
>
> --
> 2.35.1
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
^ permalink raw reply [flat|nested] 122+ messages in thread* Re: [PATCH RFC 12/18] rust: drm: sched: Add GPU scheduler abstraction
2023-04-05 15:43 ` Daniel Vetter
@ 2023-04-05 19:29 ` Daniel Vetter
2023-04-18 8:45 ` Daniel Vetter
0 siblings, 1 reply; 122+ messages in thread
From: Daniel Vetter @ 2023-04-05 19:29 UTC (permalink / raw)
To: Asahi Lina, Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
David Airlie, Miguel Ojeda, Alex Gaynor, Wedson Almeida Filho,
Boqun Feng, Gary Guo, Björn Roy Baron, Sumit Semwal,
Christian König, Luben Tuikov, Jarkko Sakkinen, Dave Hansen,
Alyssa Rosenzweig, Karol Herbst, Ella Stanforth, Faith Ekstrand,
Mary, linux-kernel, dri-devel, rust-for-linux, linux-media,
linaro-mm-sig, linux-sgx, asahi
On Wed, Apr 05, 2023 at 05:43:01PM +0200, Daniel Vetter wrote:
> On Tue, Mar 07, 2023 at 11:25:37PM +0900, Asahi Lina wrote:
> > +/// An armed DRM scheduler job (not yet submitted)
> > +pub struct ArmedJob<'a, T: JobImpl>(Box<Job<T>>, PhantomData<&'a T>);
> > +
> > +impl<'a, T: JobImpl> ArmedJob<'a, T> {
> > + /// Returns the job fences
> > + pub fn fences(&self) -> JobFences<'_> {
> > + JobFences(unsafe { &mut *self.0.job.s_fence })
> > + }
> > +
> > + /// Push the job for execution into the scheduler
> > + pub fn push(self) {
> > + // After this point, the job is submitted and owned by the scheduler
> > + let ptr = match self {
> > + ArmedJob(job, _) => Box::<Job<T>>::into_raw(job),
> > + };
>
> If I get this all right then this all makes sure that drivers can't use
> the job after push and they don't forgot to call arm.
>
> What I'm not seeing is how we force drivers to call push once they've
> called arm? I haven't check what the code does, but from the docs it
> sounds like if you don't call push then drop will get called. Which wreaks
> the book-keeping on an armed job. Or is there someting that prevents
> ArmedJob<T> from having the Drop trait and so the only way to not go boom
> is by pushing it?
>
> Googling for "rust undroppable" seems to indicate that this isn't a thing
> rust can do?
Another thing that I just realized: The driver must ensure that the
arm->push sequence on a given drm_sched_entity isn't interrupte by another
thread doing the same, i.e. you need to wrap it all in a lock, and it
always needs to be the same lock for a given entity.
I have no idea how to guarantee that, but I guess somehow we should?
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
^ permalink raw reply [flat|nested] 122+ messages in thread* Re: [PATCH RFC 12/18] rust: drm: sched: Add GPU scheduler abstraction
2023-04-05 19:29 ` Daniel Vetter
@ 2023-04-18 8:45 ` Daniel Vetter
0 siblings, 0 replies; 122+ messages in thread
From: Daniel Vetter @ 2023-04-18 8:45 UTC (permalink / raw)
To: Asahi Lina, Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
David Airlie, Miguel Ojeda, Alex Gaynor, Wedson Almeida Filho,
Boqun Feng, Gary Guo, Björn Roy Baron, Sumit Semwal,
Christian König, Luben Tuikov, Jarkko Sakkinen, Dave Hansen,
Alyssa Rosenzweig, Karol Herbst, Ella Stanforth, Faith Ekstrand,
Mary, linux-kernel, dri-devel, rust-for-linux, linux-media,
linaro-mm-sig, linux-sgx, asahi
On Wed, Apr 05, 2023 at 09:29:02PM +0200, Daniel Vetter wrote:
> On Wed, Apr 05, 2023 at 05:43:01PM +0200, Daniel Vetter wrote:
> > On Tue, Mar 07, 2023 at 11:25:37PM +0900, Asahi Lina wrote:
> > > +/// An armed DRM scheduler job (not yet submitted)
> > > +pub struct ArmedJob<'a, T: JobImpl>(Box<Job<T>>, PhantomData<&'a T>);
> > > +
> > > +impl<'a, T: JobImpl> ArmedJob<'a, T> {
> > > + /// Returns the job fences
> > > + pub fn fences(&self) -> JobFences<'_> {
> > > + JobFences(unsafe { &mut *self.0.job.s_fence })
> > > + }
> > > +
> > > + /// Push the job for execution into the scheduler
> > > + pub fn push(self) {
> > > + // After this point, the job is submitted and owned by the scheduler
> > > + let ptr = match self {
> > > + ArmedJob(job, _) => Box::<Job<T>>::into_raw(job),
> > > + };
> >
> > If I get this all right then this all makes sure that drivers can't use
> > the job after push and they don't forgot to call arm.
> >
> > What I'm not seeing is how we force drivers to call push once they've
> > called arm? I haven't check what the code does, but from the docs it
> > sounds like if you don't call push then drop will get called. Which wreaks
> > the book-keeping on an armed job. Or is there someting that prevents
> > ArmedJob<T> from having the Drop trait and so the only way to not go boom
> > is by pushing it?
> >
> > Googling for "rust undroppable" seems to indicate that this isn't a thing
> > rust can do?
>
> Another thing that I just realized: The driver must ensure that the
> arm->push sequence on a given drm_sched_entity isn't interrupte by another
> thread doing the same, i.e. you need to wrap it all in a lock, and it
> always needs to be the same lock for a given entity.
>
> I have no idea how to guarantee that, but I guess somehow we should?
Ok I was wrong here, pushing the job is optional, but the locking rules
are still the same.
I think we can solve this in rust with:
- passing &mut Entity to a new submit_job function. that way locking rules
are left to the driver, which I think is best.
- the submit_job also takes a closure, and passes the armed job as a &mut
ArmedJob to it. That way we guarantee that the armed job never survives
longer than the mutex guard (or whatever trick the driver is using) for
the Entity
- that closure probably should have Result return type which submit_job
just passes on, because some drivers (when you support userptr that is)
need to be able to bail out. since the ArmedJob is borred it shouldn't
be able to escape through the return value
- only ArmedJob has push_job
I think with that we fully uphold the drm_sched arm/push_job contract on
the rust side?
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
^ permalink raw reply [flat|nested] 122+ messages in thread
* [PATCH RFC 13/18] drm/gem: Add a flag to control whether objects can be exported
2023-03-07 14:25 [PATCH RFC 00/18] Rust DRM subsystem abstractions (& preview AGX driver) Asahi Lina
` (11 preceding siblings ...)
2023-03-07 14:25 ` [PATCH RFC 12/18] rust: drm: sched: Add GPU scheduler abstraction Asahi Lina
@ 2023-03-07 14:25 ` Asahi Lina
2023-04-05 14:55 ` Daniel Vetter
2023-03-07 14:25 ` [PATCH RFC 14/18] rust: drm: gem: Add set_exportable() method Asahi Lina
` (5 subsequent siblings)
18 siblings, 1 reply; 122+ messages in thread
From: Asahi Lina @ 2023-03-07 14:25 UTC (permalink / raw)
To: Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
David Airlie, Daniel Vetter, Miguel Ojeda, Alex Gaynor,
Wedson Almeida Filho, Boqun Feng, Gary Guo, Björn Roy Baron,
Sumit Semwal, Christian König, Luben Tuikov,
Jarkko Sakkinen, Dave Hansen
Cc: Alyssa Rosenzweig, Karol Herbst, Ella Stanforth, Faith Ekstrand,
Mary, linux-kernel, dri-devel, rust-for-linux, linux-media,
linaro-mm-sig, linux-sgx, asahi, Asahi Lina
Drivers may want to support driver-private objects, which cannot be
shared. This allows them to share a single lock and enables other
optimizations.
Add an `exportable` field to drm_gem_object, which blocks PRIME export
if set to false. It is initialized to true in
drm_gem_private_object_init.
Signed-off-by: Asahi Lina <lina@asahilina.net>
---
drivers/gpu/drm/drm_gem.c | 1 +
drivers/gpu/drm/drm_prime.c | 5 +++++
include/drm/drm_gem.h | 8 ++++++++
3 files changed, 14 insertions(+)
diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
index 7a3cb08dc942..152ad9295a8d 100644
--- a/drivers/gpu/drm/drm_gem.c
+++ b/drivers/gpu/drm/drm_gem.c
@@ -166,6 +166,7 @@ void drm_gem_private_object_init(struct drm_device *dev,
drm_vma_node_reset(&obj->vma_node);
INIT_LIST_HEAD(&obj->lru_node);
+ obj->exportable = true;
}
EXPORT_SYMBOL(drm_gem_private_object_init);
diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
index f924b8b4ab6b..9d2dd982580e 100644
--- a/drivers/gpu/drm/drm_prime.c
+++ b/drivers/gpu/drm/drm_prime.c
@@ -391,6 +391,11 @@ static struct dma_buf *export_and_register_object(struct drm_device *dev,
return dmabuf;
}
+ if (!obj->exportable) {
+ dmabuf = ERR_PTR(-EINVAL);
+ return dmabuf;
+ }
+
if (obj->funcs && obj->funcs->export)
dmabuf = obj->funcs->export(obj, flags);
else
diff --git a/include/drm/drm_gem.h b/include/drm/drm_gem.h
index 772a4adf5287..852dec3cf763 100644
--- a/include/drm/drm_gem.h
+++ b/include/drm/drm_gem.h
@@ -361,6 +361,14 @@ struct drm_gem_object {
* The current LRU list that the GEM object is on.
*/
struct drm_gem_lru *lru;
+
+ /**
+ * @exportable:
+ *
+ * Whether this GEM object can be exported via the drm_gem_object_funcs->export
+ * callback. Defaults to true.
+ */
+ bool exportable;
};
/**
--
2.35.1
^ permalink raw reply related [flat|nested] 122+ messages in thread* Re: [PATCH RFC 13/18] drm/gem: Add a flag to control whether objects can be exported
2023-03-07 14:25 ` [PATCH RFC 13/18] drm/gem: Add a flag to control whether objects can be exported Asahi Lina
@ 2023-04-05 14:55 ` Daniel Vetter
0 siblings, 0 replies; 122+ messages in thread
From: Daniel Vetter @ 2023-04-05 14:55 UTC (permalink / raw)
To: Asahi Lina
Cc: Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
David Airlie, Daniel Vetter, Miguel Ojeda, Alex Gaynor,
Wedson Almeida Filho, Boqun Feng, Gary Guo, Björn Roy Baron,
Sumit Semwal, Christian König, Luben Tuikov,
Jarkko Sakkinen, Dave Hansen, Alyssa Rosenzweig, Karol Herbst,
Ella Stanforth, Faith Ekstrand, Mary, linux-kernel, dri-devel,
rust-for-linux, linux-media, linaro-mm-sig, linux-sgx, asahi
On Tue, Mar 07, 2023 at 11:25:38PM +0900, Asahi Lina wrote:
> Drivers may want to support driver-private objects, which cannot be
> shared. This allows them to share a single lock and enables other
> optimizations.
>
> Add an `exportable` field to drm_gem_object, which blocks PRIME export
> if set to false. It is initialized to true in
> drm_gem_private_object_init.
>
> Signed-off-by: Asahi Lina <lina@asahilina.net>
Two comments on this:
- for kernel objects which userspace never access itself the usual
approach is to simply not install a gem handle on that drm_file. If
userspace doesn't even have a handle they also can't export it. I think
that should take care of the kernel object case you have in the asahi
driver.
- for the vm-private object case you need some more checks anyway, since
you can't even use such objects on a different vm within the same
drm_file. Maybe the gpuva helpers can eventually cover this, but in
general these driver cases are handled by simply overwriting the
->export case, you can check there for vm_id.is_none() and if that's not
the case, hand the actual exporting to the helper function.
Whether this is done in the rust wrappers and you keep the
set_exportable or just in asahi code is kinda meh, but personally for
consistency I'd put that into asahi code. Imo it's much clearer when you
explicitly list (by coding them into your export impl) the reasons why a
buffer isn't exportable, instead of forcing people to chase
set_exportable calls throughout the codebase. But also a bit matters of
taste :-)
Either way (unless a missed a case) this should imo be handled in asahi
code and not in C or the rust glue.
-Daniel
> ---
> drivers/gpu/drm/drm_gem.c | 1 +
> drivers/gpu/drm/drm_prime.c | 5 +++++
> include/drm/drm_gem.h | 8 ++++++++
> 3 files changed, 14 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
> index 7a3cb08dc942..152ad9295a8d 100644
> --- a/drivers/gpu/drm/drm_gem.c
> +++ b/drivers/gpu/drm/drm_gem.c
> @@ -166,6 +166,7 @@ void drm_gem_private_object_init(struct drm_device *dev,
>
> drm_vma_node_reset(&obj->vma_node);
> INIT_LIST_HEAD(&obj->lru_node);
> + obj->exportable = true;
> }
> EXPORT_SYMBOL(drm_gem_private_object_init);
>
> diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
> index f924b8b4ab6b..9d2dd982580e 100644
> --- a/drivers/gpu/drm/drm_prime.c
> +++ b/drivers/gpu/drm/drm_prime.c
> @@ -391,6 +391,11 @@ static struct dma_buf *export_and_register_object(struct drm_device *dev,
> return dmabuf;
> }
>
> + if (!obj->exportable) {
> + dmabuf = ERR_PTR(-EINVAL);
> + return dmabuf;
> + }
> +
> if (obj->funcs && obj->funcs->export)
> dmabuf = obj->funcs->export(obj, flags);
> else
> diff --git a/include/drm/drm_gem.h b/include/drm/drm_gem.h
> index 772a4adf5287..852dec3cf763 100644
> --- a/include/drm/drm_gem.h
> +++ b/include/drm/drm_gem.h
> @@ -361,6 +361,14 @@ struct drm_gem_object {
> * The current LRU list that the GEM object is on.
> */
> struct drm_gem_lru *lru;
> +
> + /**
> + * @exportable:
> + *
> + * Whether this GEM object can be exported via the drm_gem_object_funcs->export
> + * callback. Defaults to true.
> + */
> + bool exportable;
> };
>
> /**
>
> --
> 2.35.1
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
^ permalink raw reply [flat|nested] 122+ messages in thread
* [PATCH RFC 14/18] rust: drm: gem: Add set_exportable() method
2023-03-07 14:25 [PATCH RFC 00/18] Rust DRM subsystem abstractions (& preview AGX driver) Asahi Lina
` (12 preceding siblings ...)
2023-03-07 14:25 ` [PATCH RFC 13/18] drm/gem: Add a flag to control whether objects can be exported Asahi Lina
@ 2023-03-07 14:25 ` Asahi Lina
2023-03-07 14:25 ` [PATCH RFC 15/18] drm/asahi: Add the Asahi driver UAPI [DO NOT MERGE] Asahi Lina
` (4 subsequent siblings)
18 siblings, 0 replies; 122+ messages in thread
From: Asahi Lina @ 2023-03-07 14:25 UTC (permalink / raw)
To: Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
David Airlie, Daniel Vetter, Miguel Ojeda, Alex Gaynor,
Wedson Almeida Filho, Boqun Feng, Gary Guo, Björn Roy Baron,
Sumit Semwal, Christian König, Luben Tuikov,
Jarkko Sakkinen, Dave Hansen
Cc: Alyssa Rosenzweig, Karol Herbst, Ella Stanforth, Faith Ekstrand,
Mary, linux-kernel, dri-devel, rust-for-linux, linux-media,
linaro-mm-sig, linux-sgx, asahi, Asahi Lina
This allows drivers to control whether a given GEM object is allowed to
be exported via PRIME to other drivers.
---
rust/kernel/drm/gem/mod.rs | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/rust/kernel/drm/gem/mod.rs b/rust/kernel/drm/gem/mod.rs
index e66bdef35c2e..196252a25b5a 100644
--- a/rust/kernel/drm/gem/mod.rs
+++ b/rust/kernel/drm/gem/mod.rs
@@ -135,6 +135,13 @@ pub trait BaseObject: IntoGEMObject {
self.gem_ref().size
}
+ /// Sets the exportable flag, which controls whether the object can be exported via PRIME.
+ fn set_exportable(&mut self, exportable: bool) {
+ // SAFETY: gem_obj() is valid per the type invariant, and this is safe to write if we
+ // are the only holder (mutable ref).
+ unsafe { (*self.gem_obj()).exportable = exportable };
+ }
+
/// Creates a new reference to the object.
fn reference(&self) -> ObjectRef<Self> {
// SAFETY: Having a reference to an Object implies holding a GEM reference
--
2.35.1
^ permalink raw reply related [flat|nested] 122+ messages in thread* [PATCH RFC 15/18] drm/asahi: Add the Asahi driver UAPI [DO NOT MERGE]
2023-03-07 14:25 [PATCH RFC 00/18] Rust DRM subsystem abstractions (& preview AGX driver) Asahi Lina
` (13 preceding siblings ...)
2023-03-07 14:25 ` [PATCH RFC 14/18] rust: drm: gem: Add set_exportable() method Asahi Lina
@ 2023-03-07 14:25 ` Asahi Lina
2023-03-07 15:28 ` Karol Herbst
2023-03-07 14:25 ` [PATCH RFC 16/18] rust: bindings: Bind the Asahi DRM UAPI Asahi Lina
` (3 subsequent siblings)
18 siblings, 1 reply; 122+ messages in thread
From: Asahi Lina @ 2023-03-07 14:25 UTC (permalink / raw)
To: Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
David Airlie, Daniel Vetter, Miguel Ojeda, Alex Gaynor,
Wedson Almeida Filho, Boqun Feng, Gary Guo, Björn Roy Baron,
Sumit Semwal, Christian König, Luben Tuikov,
Jarkko Sakkinen, Dave Hansen
Cc: Alyssa Rosenzweig, Karol Herbst, Ella Stanforth, Faith Ekstrand,
Mary, linux-kernel, dri-devel, rust-for-linux, linux-media,
linaro-mm-sig, linux-sgx, asahi, Asahi Lina
Adds the Asahi GPU driver UAPI. Note: this API is not yet stable and
therefore not ready for merging!
Signed-off-by: Asahi Lina <lina@asahilina.net>
---
include/uapi/drm/asahi_drm.h | 556 +++++++++++++++++++++++++++++++++++++++++++
1 file changed, 556 insertions(+)
diff --git a/include/uapi/drm/asahi_drm.h b/include/uapi/drm/asahi_drm.h
new file mode 100644
index 000000000000..7b15b486d03d
--- /dev/null
+++ b/include/uapi/drm/asahi_drm.h
@@ -0,0 +1,556 @@
+/* SPDX-License-Identifier: MIT */
+/*
+ * Copyright (C) The Asahi Linux Contributors
+ *
+ * Heavily inspired by xe_drm.h.
+ */
+#ifndef _ASAHI_DRM_H_
+#define _ASAHI_DRM_H_
+
+#include "drm.h"
+
+#if defined(__cplusplus)
+extern "C" {
+#endif
+
+#define DRM_ASAHI_UNSTABLE_UABI_VERSION 10006
+
+#define DRM_ASAHI_GET_PARAMS 0x00
+#define DRM_ASAHI_VM_CREATE 0x01
+#define DRM_ASAHI_VM_DESTROY 0x02
+#define DRM_ASAHI_GEM_CREATE 0x03
+#define DRM_ASAHI_GEM_MMAP_OFFSET 0x04
+#define DRM_ASAHI_GEM_BIND 0x05
+#define DRM_ASAHI_QUEUE_CREATE 0x06
+#define DRM_ASAHI_QUEUE_DESTROY 0x07
+#define DRM_ASAHI_SUBMIT 0x08
+#define DRM_ASAHI_GET_TIME 0x09
+
+#define DRM_ASAHI_MAX_CLUSTERS 32
+
+struct drm_asahi_params_global {
+ __u32 unstable_uabi_version;
+ __u32 pad0;
+
+ __u64 feat_compat;
+ __u64 feat_incompat;
+
+ __u32 gpu_generation;
+ __u32 gpu_variant;
+ __u32 gpu_revision;
+ __u32 chip_id;
+
+ __u32 num_dies;
+ __u32 num_clusters_total;
+ __u32 num_cores_per_cluster;
+ __u32 num_frags_per_cluster;
+ __u32 num_gps_per_cluster;
+ __u32 num_cores_total_active;
+ __u64 core_masks[DRM_ASAHI_MAX_CLUSTERS];
+
+ __u32 vm_page_size;
+ __u32 pad1;
+ __u64 vm_user_start;
+ __u64 vm_user_end;
+ __u64 vm_shader_start;
+ __u64 vm_shader_end;
+
+ __u32 max_syncs_per_submission;
+ __u32 max_commands_per_submission;
+ __u32 max_commands_in_flight;
+ __u32 max_attachments;
+
+ __u32 timer_frequency_hz;
+ __u32 min_frequency_khz;
+ __u32 max_frequency_khz;
+ __u32 max_power_mw;
+
+ __u32 result_render_size;
+ __u32 result_compute_size;
+};
+
+/*
+enum drm_asahi_feat_compat {
+};
+*/
+
+enum drm_asahi_feat_incompat {
+ DRM_ASAHI_FEAT_MANDATORY_ZS_COMPRESSION = (1UL) << 0,
+};
+
+struct drm_asahi_get_params {
+ /** @extensions: Pointer to the first extension struct, if any */
+ __u64 extensions;
+
+ /** @param: Parameter group to fetch (MBZ) */
+ __u32 param_group;
+
+ /** @pad: MBZ */
+ __u32 pad;
+
+ /** @value: User pointer to write parameter struct */
+ __u64 pointer;
+
+ /** @value: Size of user buffer, max size supported on return */
+ __u64 size;
+};
+
+struct drm_asahi_vm_create {
+ /** @extensions: Pointer to the first extension struct, if any */
+ __u64 extensions;
+
+ /** @value: Returned VM ID */
+ __u32 vm_id;
+
+ /** @pad: MBZ */
+ __u32 pad;
+};
+
+struct drm_asahi_vm_destroy {
+ /** @extensions: Pointer to the first extension struct, if any */
+ __u64 extensions;
+
+ /** @value: VM ID to be destroyed */
+ __u32 vm_id;
+
+ /** @pad: MBZ */
+ __u32 pad;
+};
+
+#define ASAHI_GEM_WRITEBACK (1L << 0)
+#define ASAHI_GEM_VM_PRIVATE (1L << 1)
+
+struct drm_asahi_gem_create {
+ /** @extensions: Pointer to the first extension struct, if any */
+ __u64 extensions;
+
+ /** @size: Size of the BO */
+ __u64 size;
+
+ /** @flags: BO creation flags */
+ __u32 flags;
+
+ /** @handle: VM ID to assign to the BO, if ASAHI_GEM_VM_PRIVATE is set. */
+ __u32 vm_id;
+
+ /** @handle: Returned GEM handle for the BO */
+ __u32 handle;
+};
+
+struct drm_asahi_gem_mmap_offset {
+ /** @extensions: Pointer to the first extension struct, if any */
+ __u64 extensions;
+
+ /** @handle: Handle for the object being mapped. */
+ __u32 handle;
+
+ /** @flags: Must be zero */
+ __u32 flags;
+
+ /** @offset: The fake offset to use for subsequent mmap call */
+ __u64 offset;
+};
+
+enum drm_asahi_bind_op {
+ ASAHI_BIND_OP_BIND = 0,
+ ASAHI_BIND_OP_UNBIND = 1,
+ ASAHI_BIND_OP_UNBIND_ALL = 2,
+};
+
+#define ASAHI_BIND_READ (1L << 0)
+#define ASAHI_BIND_WRITE (1L << 1)
+
+struct drm_asahi_gem_bind {
+ /** @extensions: Pointer to the first extension struct, if any */
+ __u64 extensions;
+
+ /** @obj: Bind operation */
+ __u32 op;
+
+ /** @flags: One or more of ASAHI_BIND_* */
+ __u32 flags;
+
+ /** @obj: GEM object to bind */
+ __u32 handle;
+
+ /** @vm_id: The ID of the VM to bind to */
+ __u32 vm_id;
+
+ /** @offset: Offset into the object */
+ __u64 offset;
+
+ /** @range: Number of bytes from the object to bind to addr */
+ __u64 range;
+
+ /** @addr: Address to bind to */
+ __u64 addr;
+};
+
+enum drm_asahi_cmd_type {
+ DRM_ASAHI_CMD_RENDER = 0,
+ DRM_ASAHI_CMD_BLIT = 1,
+ DRM_ASAHI_CMD_COMPUTE = 2,
+};
+
+/* Note: this is an enum so that it can be resolved by Rust bindgen. */
+enum drm_asahi_queue_cap {
+ DRM_ASAHI_QUEUE_CAP_RENDER = (1UL << DRM_ASAHI_CMD_RENDER),
+ DRM_ASAHI_QUEUE_CAP_BLIT = (1UL << DRM_ASAHI_CMD_BLIT),
+ DRM_ASAHI_QUEUE_CAP_COMPUTE = (1UL << DRM_ASAHI_CMD_COMPUTE),
+};
+
+struct drm_asahi_queue_create {
+ /** @extensions: Pointer to the first extension struct, if any */
+ __u64 extensions;
+
+ /** @flags: MBZ */
+ __u32 flags;
+
+ /** @vm_id: The ID of the VM this queue is bound to */
+ __u32 vm_id;
+
+ /** @type: Bitmask of DRM_ASAHI_QUEUE_CAP_* */
+ __u32 queue_caps;
+
+ /** @priority: Queue priority, 0-3 */
+ __u32 priority;
+
+ /** @queue_id: The returned queue ID */
+ __u32 queue_id;
+};
+
+struct drm_asahi_queue_destroy {
+ /** @extensions: Pointer to the first extension struct, if any */
+ __u64 extensions;
+
+ /** @queue_id: The queue ID to be destroyed */
+ __u32 queue_id;
+};
+
+enum drm_asahi_sync_type {
+ DRM_ASAHI_SYNC_SYNCOBJ = 0,
+ DRM_ASAHI_SYNC_TIMELINE_SYNCOBJ = 1,
+};
+
+struct drm_asahi_sync {
+ /** @extensions: Pointer to the first extension struct, if any */
+ __u64 extensions;
+
+ /** @sync_type: One of drm_asahi_sync_type */
+ __u32 sync_type;
+
+ /** @handle: The sync object handle */
+ __u32 handle;
+
+ /** @timeline_value: Timeline value for timeline sync objects */
+ __u64 timeline_value;
+};
+
+enum drm_asahi_subqueue {
+ DRM_ASAHI_SUBQUEUE_RENDER = 0, /* Also blit */
+ DRM_ASAHI_SUBQUEUE_COMPUTE = 1,
+ DRM_ASAHI_SUBQUEUE_COUNT = 2,
+};
+
+#define DRM_ASAHI_BARRIER_NONE ~(0U)
+
+struct drm_asahi_command {
+ /** @extensions: Pointer to the first extension struct, if any */
+ __u64 extensions;
+
+ /** @type: One of drm_asahi_cmd_type */
+ __u32 cmd_type;
+
+ /** @flags: Flags for command submission */
+ __u32 flags;
+
+ /** @cmdbuf: Pointer to the appropriate command buffer structure */
+ __u64 cmd_buffer;
+
+ /** @cmdbuf: Size of the command buffer structure */
+ __u64 cmd_buffer_size;
+
+ /** @cmdbuf: Offset into the result BO to return information about this command */
+ __u64 result_offset;
+
+ /** @cmdbuf: Size of the result data structure */
+ __u64 result_size;
+
+ /** @barriers: Array of command indices per subqueue to wait on */
+ __u32 barriers[DRM_ASAHI_SUBQUEUE_COUNT];
+};
+
+struct drm_asahi_submit {
+ /** @extensions: Pointer to the first extension struct, if any */
+ __u64 extensions;
+
+ /** @in_syncs: An optional array of drm_asahi_sync to wait on before starting this job. */
+ __u64 in_syncs;
+
+ /** @in_syncs: An optional array of drm_asahi_sync objects to signal upon completion. */
+ __u64 out_syncs;
+
+ /** @commands: Pointer to the drm_asahi_command array of commands to submit. */
+ __u64 commands;
+
+ /** @flags: Flags for command submission (MBZ) */
+ __u32 flags;
+
+ /** @queue_id: The queue ID to be submitted to */
+ __u32 queue_id;
+
+ /** @result_handle: An optional BO handle to place result data in */
+ __u32 result_handle;
+
+ /** @in_sync_count: Number of sync objects to wait on before starting this job. */
+ __u32 in_sync_count;
+
+ /** @in_sync_count: Number of sync objects to signal upon completion of this job. */
+ __u32 out_sync_count;
+
+ /** @pad: Number of commands to be submitted */
+ __u32 command_count;
+};
+
+/* FIXME: This doesn't make any sense, figure out exactly what the attachment flags are */
+#define ASAHI_ATTACHMENT_C 0
+#define ASAHI_ATTACHMENT_Z 1
+#define ASAHI_ATTACHMENT_S 2
+
+struct drm_asahi_attachment {
+ __u32 type;
+ __u32 size;
+ __u64 pointer;
+};
+
+#define ASAHI_RENDER_NO_CLEAR_PIPELINE_TEXTURES (1UL << 0)
+#define ASAHI_RENDER_SET_WHEN_RELOADING_Z_OR_S (1UL << 1)
+#define ASAHI_RENDER_MEMORYLESS_RTS_USED (1UL << 2) /* Not yet implemented */
+#define ASAHI_RENDER_PROCESS_EMPTY_TILES (1UL << 3)
+#define ASAHI_RENDER_NO_VERTEX_CLUSTERING (1UL << 4)
+
+struct drm_asahi_cmd_render {
+ /** @extensions: Pointer to the first extension struct, if any */
+ __u64 extensions;
+
+ __u64 flags;
+
+ __u64 encoder_ptr;
+
+ __u64 attachments;
+ __u32 attachment_count;
+ __u32 pad;
+
+ __u64 depth_buffer_1;
+ __u64 depth_buffer_2;
+ __u64 depth_buffer_3;
+ __u64 depth_meta_buffer_1;
+ __u64 depth_meta_buffer_2;
+ __u64 depth_meta_buffer_3;
+
+ __u64 stencil_buffer_1;
+ __u64 stencil_buffer_2;
+ __u64 stencil_buffer_3;
+ __u64 stencil_meta_buffer_1;
+ __u64 stencil_meta_buffer_2;
+ __u64 stencil_meta_buffer_3;
+
+ __u64 scissor_array;
+ __u64 depth_bias_array;
+ __u64 visibility_result_buffer;
+
+ __u64 zls_ctrl;
+ __u64 ppp_multisamplectl;
+ __u32 ppp_ctrl;
+
+ __u32 fb_width;
+ __u32 fb_height;
+
+ __u32 utile_width;
+ __u32 utile_height;
+
+ __u32 samples;
+ __u32 layers;
+
+ __u32 encoder_id;
+ __u32 cmd_ta_id;
+ __u32 cmd_3d_id;
+
+ __u32 iogpu_unk_49;
+ __u32 iogpu_unk_212;
+ __u32 iogpu_unk_214;
+
+ __u32 merge_upper_x;
+ __u32 merge_upper_y;
+
+ __u32 load_pipeline;
+ __u32 load_pipeline_bind;
+
+ __u32 store_pipeline;
+ __u32 store_pipeline_bind;
+
+ __u32 partial_reload_pipeline;
+ __u32 partial_reload_pipeline_bind;
+
+ __u32 partial_store_pipeline;
+ __u32 partial_store_pipeline_bind;
+
+ __u32 depth_dimensions;
+ __u32 isp_bgobjdepth;
+ __u32 isp_bgobjvals;
+};
+
+struct drm_asahi_cmd_compute {
+ __u64 flags;
+
+ __u64 encoder_ptr;
+ __u64 encoder_end;
+
+ __u64 attachments;
+ __u32 attachment_count;
+ __u32 pad;
+
+ __u64 buffer_descriptor;
+
+ __u32 buffer_descriptor_size; /* ? */
+ __u32 ctx_switch_prog;
+
+ __u32 encoder_id;
+ __u32 cmd_id;
+
+ __u32 iogpu_unk_40;
+ __u32 iogpu_unk_44;
+};
+
+enum drm_asahi_status {
+ DRM_ASAHI_STATUS_PENDING = 0,
+ DRM_ASAHI_STATUS_COMPLETE,
+ DRM_ASAHI_STATUS_UNKNOWN_ERROR,
+ DRM_ASAHI_STATUS_TIMEOUT,
+ DRM_ASAHI_STATUS_FAULT,
+ DRM_ASAHI_STATUS_KILLED,
+ DRM_ASAHI_STATUS_NO_DEVICE,
+};
+
+enum drm_asahi_fault {
+ DRM_ASAHI_FAULT_NONE = 0,
+ DRM_ASAHI_FAULT_UNKNOWN,
+ DRM_ASAHI_FAULT_UNMAPPED,
+ DRM_ASAHI_FAULT_AF_FAULT,
+ DRM_ASAHI_FAULT_WRITE_ONLY,
+ DRM_ASAHI_FAULT_READ_ONLY,
+ DRM_ASAHI_FAULT_NO_ACCESS,
+};
+
+struct drm_asahi_result_info {
+ /** @status: One of enum drm_asahi_status */
+ __u32 status;
+
+ /** @reason: One of drm_asahi_fault_type */
+ __u32 fault_type;
+
+ /** @unit: Unit number, hardware dependent */
+ __u32 unit;
+
+ /** @sideband: Sideband information, hardware dependent */
+ __u32 sideband;
+
+ /** @level: Page table level at which the fault occurred, hardware dependent */
+ __u8 level;
+
+ /** @read: Fault was a read */
+ __u8 is_read;
+
+ /** @pad: MBZ */
+ __u16 pad;
+
+ /** @unk_5: Extra bits, hardware dependent */
+ __u32 extra;
+
+ /** @address: Fault address, cache line aligned */
+ __u64 address;
+};
+
+#define DRM_ASAHI_RESULT_RENDER_TVB_GROW_OVF (1UL << 0)
+#define DRM_ASAHI_RESULT_RENDER_TVB_GROW_MIN (1UL << 1)
+#define DRM_ASAHI_RESULT_RENDER_TVB_OVERFLOWED (1UL << 2)
+
+struct drm_asahi_result_render {
+ /** @address: Common result information */
+ struct drm_asahi_result_info info;
+
+ /** @flags: Zero or more of of DRM_ASAHI_RESULT_RENDER_* */
+ __u64 flags;
+
+ /** @vertex_ts_start: Timestamp of the start of vertex processing */
+ __u64 vertex_ts_start;
+
+ /** @vertex_ts_end: Timestamp of the end of vertex processing */
+ __u64 vertex_ts_end;
+
+ /** @fragment_ts_start: Timestamp of the start of fragment processing */
+ __u64 fragment_ts_start;
+
+ /** @fragment_ts_end: Timestamp of the end of fragment processing */
+ __u64 fragment_ts_end;
+
+ /** @tvb_size_bytes: TVB size at the start of this render */
+ __u64 tvb_size_bytes;
+
+ /** @tvb_usage_bytes: Total TVB usage in bytes for this render */
+ __u64 tvb_usage_bytes;
+
+ /** @num_tvb_overflows: Number of TVB overflows that occurred for this render */
+ __u32 num_tvb_overflows;
+};
+
+struct drm_asahi_result_compute {
+ /** @address: Common result information */
+ struct drm_asahi_result_info info;
+
+ /** @flags: Zero or more of of DRM_ASAHI_RESULT_COMPUTE_* */
+ __u64 flags;
+
+ /** @ts_start: Timestamp of the start of this compute command */
+ __u64 ts_start;
+
+ /** @vertex_ts_end: Timestamp of the end of this compute command */
+ __u64 ts_end;
+};
+
+struct drm_asahi_get_time {
+ /** @extensions: Pointer to the first extension struct, if any */
+ __u64 extensions;
+
+ /** @flags: MBZ. */
+ __u64 flags;
+
+ /** @tv_sec: On return, seconds part of a point in time */
+ __s64 tv_sec;
+
+ /** @tv_nsec: On return, nanoseconds part of a point in time */
+ __s64 tv_nsec;
+
+ /** @gpu_timestamp: On return, the GPU timestamp at that point in time */
+ __u64 gpu_timestamp;
+};
+
+/* Note: this is an enum so that it can be resolved by Rust bindgen. */
+enum {
+ DRM_IOCTL_ASAHI_GET_PARAMS = DRM_IOWR(DRM_COMMAND_BASE + DRM_ASAHI_GET_PARAMS, struct drm_asahi_get_params),
+ DRM_IOCTL_ASAHI_VM_CREATE = DRM_IOWR(DRM_COMMAND_BASE + DRM_ASAHI_VM_CREATE, struct drm_asahi_vm_create),
+ DRM_IOCTL_ASAHI_VM_DESTROY = DRM_IOW(DRM_COMMAND_BASE + DRM_ASAHI_VM_DESTROY, struct drm_asahi_vm_destroy),
+ DRM_IOCTL_ASAHI_GEM_CREATE = DRM_IOWR(DRM_COMMAND_BASE + DRM_ASAHI_GEM_CREATE, struct drm_asahi_gem_create),
+ DRM_IOCTL_ASAHI_GEM_MMAP_OFFSET = DRM_IOWR(DRM_COMMAND_BASE + DRM_ASAHI_GEM_MMAP_OFFSET, struct drm_asahi_gem_mmap_offset),
+ DRM_IOCTL_ASAHI_GEM_BIND = DRM_IOW(DRM_COMMAND_BASE + DRM_ASAHI_GEM_BIND, struct drm_asahi_gem_bind),
+ DRM_IOCTL_ASAHI_QUEUE_CREATE = DRM_IOWR(DRM_COMMAND_BASE + DRM_ASAHI_QUEUE_CREATE, struct drm_asahi_queue_create),
+ DRM_IOCTL_ASAHI_QUEUE_DESTROY = DRM_IOW(DRM_COMMAND_BASE + DRM_ASAHI_QUEUE_DESTROY, struct drm_asahi_queue_destroy),
+ DRM_IOCTL_ASAHI_SUBMIT = DRM_IOW(DRM_COMMAND_BASE + DRM_ASAHI_SUBMIT, struct drm_asahi_submit),
+ DRM_IOCTL_ASAHI_GET_TIME = DRM_IOWR(DRM_COMMAND_BASE + DRM_ASAHI_GET_TIME, struct drm_asahi_get_time),
+};
+
+#if defined(__cplusplus)
+}
+#endif
+
+#endif /* _ASAHI_DRM_H_ */
--
2.35.1
^ permalink raw reply related [flat|nested] 122+ messages in thread* Re: [PATCH RFC 15/18] drm/asahi: Add the Asahi driver UAPI [DO NOT MERGE]
2023-03-07 14:25 ` [PATCH RFC 15/18] drm/asahi: Add the Asahi driver UAPI [DO NOT MERGE] Asahi Lina
@ 2023-03-07 15:28 ` Karol Herbst
0 siblings, 0 replies; 122+ messages in thread
From: Karol Herbst @ 2023-03-07 15:28 UTC (permalink / raw)
To: Asahi Lina
Cc: Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
David Airlie, Daniel Vetter, Miguel Ojeda, Alex Gaynor,
Wedson Almeida Filho, Boqun Feng, Gary Guo, Björn Roy Baron,
Sumit Semwal, Christian König, Luben Tuikov,
Jarkko Sakkinen, Dave Hansen, Alyssa Rosenzweig, Ella Stanforth,
Faith Ekstrand, Mary, linux-kernel, dri-devel, rust-for-linux,
linux-media, linaro-mm-sig, linux-sgx, asahi
On Tue, Mar 7, 2023 at 3:28 PM Asahi Lina <lina@asahilina.net> wrote:
>
> Adds the Asahi GPU driver UAPI. Note: this API is not yet stable and
> therefore not ready for merging!
>
> Signed-off-by: Asahi Lina <lina@asahilina.net>
> ---
> include/uapi/drm/asahi_drm.h | 556 +++++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 556 insertions(+)
>
> diff --git a/include/uapi/drm/asahi_drm.h b/include/uapi/drm/asahi_drm.h
> new file mode 100644
> index 000000000000..7b15b486d03d
> --- /dev/null
> +++ b/include/uapi/drm/asahi_drm.h
> @@ -0,0 +1,556 @@
> +/* SPDX-License-Identifier: MIT */
> +/*
> + * Copyright (C) The Asahi Linux Contributors
> + *
> + * Heavily inspired by xe_drm.h.
> + */
> +#ifndef _ASAHI_DRM_H_
> +#define _ASAHI_DRM_H_
> +
> +#include "drm.h"
> +
> +#if defined(__cplusplus)
> +extern "C" {
> +#endif
> +
> +#define DRM_ASAHI_UNSTABLE_UABI_VERSION 10006
> +
> +#define DRM_ASAHI_GET_PARAMS 0x00
> +#define DRM_ASAHI_VM_CREATE 0x01
> +#define DRM_ASAHI_VM_DESTROY 0x02
> +#define DRM_ASAHI_GEM_CREATE 0x03
> +#define DRM_ASAHI_GEM_MMAP_OFFSET 0x04
> +#define DRM_ASAHI_GEM_BIND 0x05
> +#define DRM_ASAHI_QUEUE_CREATE 0x06
> +#define DRM_ASAHI_QUEUE_DESTROY 0x07
> +#define DRM_ASAHI_SUBMIT 0x08
> +#define DRM_ASAHI_GET_TIME 0x09
> +
> +#define DRM_ASAHI_MAX_CLUSTERS 32
> +
> +struct drm_asahi_params_global {
> + __u32 unstable_uabi_version;
> + __u32 pad0;
> +
> + __u64 feat_compat;
> + __u64 feat_incompat;
> +
> + __u32 gpu_generation;
> + __u32 gpu_variant;
> + __u32 gpu_revision;
> + __u32 chip_id;
> +
> + __u32 num_dies;
> + __u32 num_clusters_total;
> + __u32 num_cores_per_cluster;
> + __u32 num_frags_per_cluster;
> + __u32 num_gps_per_cluster;
> + __u32 num_cores_total_active;
> + __u64 core_masks[DRM_ASAHI_MAX_CLUSTERS];
> +
> + __u32 vm_page_size;
> + __u32 pad1;
> + __u64 vm_user_start;
> + __u64 vm_user_end;
> + __u64 vm_shader_start;
> + __u64 vm_shader_end;
> +
> + __u32 max_syncs_per_submission;
> + __u32 max_commands_per_submission;
> + __u32 max_commands_in_flight;
> + __u32 max_attachments;
> +
> + __u32 timer_frequency_hz;
> + __u32 min_frequency_khz;
> + __u32 max_frequency_khz;
> + __u32 max_power_mw;
> +
> + __u32 result_render_size;
> + __u32 result_compute_size;
> +};
> +
> +/*
> +enum drm_asahi_feat_compat {
> +};
> +*/
> +
> +enum drm_asahi_feat_incompat {
> + DRM_ASAHI_FEAT_MANDATORY_ZS_COMPRESSION = (1UL) << 0,
> +};
> +
> +struct drm_asahi_get_params {
> + /** @extensions: Pointer to the first extension struct, if any */
> + __u64 extensions;
> +
> + /** @param: Parameter group to fetch (MBZ) */
> + __u32 param_group;
> +
> + /** @pad: MBZ */
> + __u32 pad;
> +
> + /** @value: User pointer to write parameter struct */
> + __u64 pointer;
> +
> + /** @value: Size of user buffer, max size supported on return */
> + __u64 size;
> +};
> +
> +struct drm_asahi_vm_create {
> + /** @extensions: Pointer to the first extension struct, if any */
> + __u64 extensions;
> +
> + /** @value: Returned VM ID */
> + __u32 vm_id;
> +
> + /** @pad: MBZ */
> + __u32 pad;
> +};
> +
> +struct drm_asahi_vm_destroy {
> + /** @extensions: Pointer to the first extension struct, if any */
> + __u64 extensions;
> +
> + /** @value: VM ID to be destroyed */
> + __u32 vm_id;
> +
> + /** @pad: MBZ */
> + __u32 pad;
> +};
> +
> +#define ASAHI_GEM_WRITEBACK (1L << 0)
> +#define ASAHI_GEM_VM_PRIVATE (1L << 1)
> +
> +struct drm_asahi_gem_create {
> + /** @extensions: Pointer to the first extension struct, if any */
> + __u64 extensions;
> +
> + /** @size: Size of the BO */
> + __u64 size;
> +
> + /** @flags: BO creation flags */
> + __u32 flags;
> +
> + /** @handle: VM ID to assign to the BO, if ASAHI_GEM_VM_PRIVATE is set. */
> + __u32 vm_id;
> +
> + /** @handle: Returned GEM handle for the BO */
> + __u32 handle;
> +};
> +
> +struct drm_asahi_gem_mmap_offset {
> + /** @extensions: Pointer to the first extension struct, if any */
> + __u64 extensions;
> +
> + /** @handle: Handle for the object being mapped. */
> + __u32 handle;
> +
> + /** @flags: Must be zero */
> + __u32 flags;
> +
> + /** @offset: The fake offset to use for subsequent mmap call */
> + __u64 offset;
> +};
> +
> +enum drm_asahi_bind_op {
> + ASAHI_BIND_OP_BIND = 0,
> + ASAHI_BIND_OP_UNBIND = 1,
> + ASAHI_BIND_OP_UNBIND_ALL = 2,
> +};
> +
> +#define ASAHI_BIND_READ (1L << 0)
> +#define ASAHI_BIND_WRITE (1L << 1)
> +
> +struct drm_asahi_gem_bind {
> + /** @extensions: Pointer to the first extension struct, if any */
> + __u64 extensions;
> +
> + /** @obj: Bind operation */
> + __u32 op;
> +
> + /** @flags: One or more of ASAHI_BIND_* */
> + __u32 flags;
> +
> + /** @obj: GEM object to bind */
> + __u32 handle;
> +
> + /** @vm_id: The ID of the VM to bind to */
> + __u32 vm_id;
> +
> + /** @offset: Offset into the object */
> + __u64 offset;
> +
> + /** @range: Number of bytes from the object to bind to addr */
> + __u64 range;
> +
> + /** @addr: Address to bind to */
> + __u64 addr;
> +};
> +
> +enum drm_asahi_cmd_type {
> + DRM_ASAHI_CMD_RENDER = 0,
> + DRM_ASAHI_CMD_BLIT = 1,
> + DRM_ASAHI_CMD_COMPUTE = 2,
> +};
> +
> +/* Note: this is an enum so that it can be resolved by Rust bindgen. */
> +enum drm_asahi_queue_cap {
> + DRM_ASAHI_QUEUE_CAP_RENDER = (1UL << DRM_ASAHI_CMD_RENDER),
> + DRM_ASAHI_QUEUE_CAP_BLIT = (1UL << DRM_ASAHI_CMD_BLIT),
> + DRM_ASAHI_QUEUE_CAP_COMPUTE = (1UL << DRM_ASAHI_CMD_COMPUTE),
> +};
> +
> +struct drm_asahi_queue_create {
> + /** @extensions: Pointer to the first extension struct, if any */
> + __u64 extensions;
> +
> + /** @flags: MBZ */
> + __u32 flags;
> +
> + /** @vm_id: The ID of the VM this queue is bound to */
> + __u32 vm_id;
> +
> + /** @type: Bitmask of DRM_ASAHI_QUEUE_CAP_* */
> + __u32 queue_caps;
> +
> + /** @priority: Queue priority, 0-3 */
> + __u32 priority;
> +
> + /** @queue_id: The returned queue ID */
> + __u32 queue_id;
> +};
> +
> +struct drm_asahi_queue_destroy {
> + /** @extensions: Pointer to the first extension struct, if any */
> + __u64 extensions;
> +
> + /** @queue_id: The queue ID to be destroyed */
> + __u32 queue_id;
> +};
> +
> +enum drm_asahi_sync_type {
> + DRM_ASAHI_SYNC_SYNCOBJ = 0,
> + DRM_ASAHI_SYNC_TIMELINE_SYNCOBJ = 1,
> +};
> +
> +struct drm_asahi_sync {
> + /** @extensions: Pointer to the first extension struct, if any */
> + __u64 extensions;
> +
> + /** @sync_type: One of drm_asahi_sync_type */
> + __u32 sync_type;
> +
> + /** @handle: The sync object handle */
> + __u32 handle;
> +
> + /** @timeline_value: Timeline value for timeline sync objects */
> + __u64 timeline_value;
> +};
> +
> +enum drm_asahi_subqueue {
> + DRM_ASAHI_SUBQUEUE_RENDER = 0, /* Also blit */
> + DRM_ASAHI_SUBQUEUE_COMPUTE = 1,
> + DRM_ASAHI_SUBQUEUE_COUNT = 2,
> +};
> +
> +#define DRM_ASAHI_BARRIER_NONE ~(0U)
> +
> +struct drm_asahi_command {
> + /** @extensions: Pointer to the first extension struct, if any */
> + __u64 extensions;
> +
> + /** @type: One of drm_asahi_cmd_type */
> + __u32 cmd_type;
> +
> + /** @flags: Flags for command submission */
> + __u32 flags;
> +
> + /** @cmdbuf: Pointer to the appropriate command buffer structure */
> + __u64 cmd_buffer;
> +
> + /** @cmdbuf: Size of the command buffer structure */
> + __u64 cmd_buffer_size;
> +
> + /** @cmdbuf: Offset into the result BO to return information about this command */
> + __u64 result_offset;
> +
> + /** @cmdbuf: Size of the result data structure */
> + __u64 result_size;
> +
> + /** @barriers: Array of command indices per subqueue to wait on */
> + __u32 barriers[DRM_ASAHI_SUBQUEUE_COUNT];
> +};
> +
> +struct drm_asahi_submit {
> + /** @extensions: Pointer to the first extension struct, if any */
> + __u64 extensions;
> +
> + /** @in_syncs: An optional array of drm_asahi_sync to wait on before starting this job. */
> + __u64 in_syncs;
> +
> + /** @in_syncs: An optional array of drm_asahi_sync objects to signal upon completion. */
> + __u64 out_syncs;
> +
> + /** @commands: Pointer to the drm_asahi_command array of commands to submit. */
> + __u64 commands;
> +
> + /** @flags: Flags for command submission (MBZ) */
> + __u32 flags;
> +
> + /** @queue_id: The queue ID to be submitted to */
> + __u32 queue_id;
> +
> + /** @result_handle: An optional BO handle to place result data in */
> + __u32 result_handle;
> +
> + /** @in_sync_count: Number of sync objects to wait on before starting this job. */
> + __u32 in_sync_count;
> +
> + /** @in_sync_count: Number of sync objects to signal upon completion of this job. */
> + __u32 out_sync_count;
> +
> + /** @pad: Number of commands to be submitted */
> + __u32 command_count;
> +};
> +
> +/* FIXME: This doesn't make any sense, figure out exactly what the attachment flags are */
> +#define ASAHI_ATTACHMENT_C 0
> +#define ASAHI_ATTACHMENT_Z 1
> +#define ASAHI_ATTACHMENT_S 2
> +
> +struct drm_asahi_attachment {
> + __u32 type;
> + __u32 size;
> + __u64 pointer;
> +};
> +
> +#define ASAHI_RENDER_NO_CLEAR_PIPELINE_TEXTURES (1UL << 0)
> +#define ASAHI_RENDER_SET_WHEN_RELOADING_Z_OR_S (1UL << 1)
> +#define ASAHI_RENDER_MEMORYLESS_RTS_USED (1UL << 2) /* Not yet implemented */
> +#define ASAHI_RENDER_PROCESS_EMPTY_TILES (1UL << 3)
> +#define ASAHI_RENDER_NO_VERTEX_CLUSTERING (1UL << 4)
> +
> +struct drm_asahi_cmd_render {
> + /** @extensions: Pointer to the first extension struct, if any */
> + __u64 extensions;
> +
> + __u64 flags;
> +
> + __u64 encoder_ptr;
> +
> + __u64 attachments;
> + __u32 attachment_count;
> + __u32 pad;
> +
> + __u64 depth_buffer_1;
> + __u64 depth_buffer_2;
> + __u64 depth_buffer_3;
> + __u64 depth_meta_buffer_1;
> + __u64 depth_meta_buffer_2;
> + __u64 depth_meta_buffer_3;
> +
> + __u64 stencil_buffer_1;
> + __u64 stencil_buffer_2;
> + __u64 stencil_buffer_3;
> + __u64 stencil_meta_buffer_1;
> + __u64 stencil_meta_buffer_2;
> + __u64 stencil_meta_buffer_3;
> +
> + __u64 scissor_array;
> + __u64 depth_bias_array;
> + __u64 visibility_result_buffer;
> +
> + __u64 zls_ctrl;
> + __u64 ppp_multisamplectl;
> + __u32 ppp_ctrl;
> +
> + __u32 fb_width;
> + __u32 fb_height;
> +
> + __u32 utile_width;
> + __u32 utile_height;
> +
> + __u32 samples;
> + __u32 layers;
> +
> + __u32 encoder_id;
> + __u32 cmd_ta_id;
> + __u32 cmd_3d_id;
> +
> + __u32 iogpu_unk_49;
> + __u32 iogpu_unk_212;
> + __u32 iogpu_unk_214;
> +
> + __u32 merge_upper_x;
> + __u32 merge_upper_y;
> +
> + __u32 load_pipeline;
> + __u32 load_pipeline_bind;
> +
> + __u32 store_pipeline;
> + __u32 store_pipeline_bind;
> +
> + __u32 partial_reload_pipeline;
> + __u32 partial_reload_pipeline_bind;
> +
> + __u32 partial_store_pipeline;
> + __u32 partial_store_pipeline_bind;
> +
> + __u32 depth_dimensions;
> + __u32 isp_bgobjdepth;
> + __u32 isp_bgobjvals;
> +};
> +
> +struct drm_asahi_cmd_compute {
> + __u64 flags;
> +
> + __u64 encoder_ptr;
> + __u64 encoder_end;
> +
> + __u64 attachments;
> + __u32 attachment_count;
> + __u32 pad;
> +
> + __u64 buffer_descriptor;
> +
> + __u32 buffer_descriptor_size; /* ? */
> + __u32 ctx_switch_prog;
> +
> + __u32 encoder_id;
> + __u32 cmd_id;
> +
> + __u32 iogpu_unk_40;
> + __u32 iogpu_unk_44;
> +};
> +
> +enum drm_asahi_status {
> + DRM_ASAHI_STATUS_PENDING = 0,
> + DRM_ASAHI_STATUS_COMPLETE,
> + DRM_ASAHI_STATUS_UNKNOWN_ERROR,
> + DRM_ASAHI_STATUS_TIMEOUT,
> + DRM_ASAHI_STATUS_FAULT,
> + DRM_ASAHI_STATUS_KILLED,
> + DRM_ASAHI_STATUS_NO_DEVICE,
> +};
> +
> +enum drm_asahi_fault {
> + DRM_ASAHI_FAULT_NONE = 0,
> + DRM_ASAHI_FAULT_UNKNOWN,
> + DRM_ASAHI_FAULT_UNMAPPED,
> + DRM_ASAHI_FAULT_AF_FAULT,
> + DRM_ASAHI_FAULT_WRITE_ONLY,
> + DRM_ASAHI_FAULT_READ_ONLY,
> + DRM_ASAHI_FAULT_NO_ACCESS,
> +};
> +
> +struct drm_asahi_result_info {
> + /** @status: One of enum drm_asahi_status */
> + __u32 status;
> +
> + /** @reason: One of drm_asahi_fault_type */
> + __u32 fault_type;
> +
> + /** @unit: Unit number, hardware dependent */
> + __u32 unit;
> +
> + /** @sideband: Sideband information, hardware dependent */
> + __u32 sideband;
> +
> + /** @level: Page table level at which the fault occurred, hardware dependent */
> + __u8 level;
> +
> + /** @read: Fault was a read */
> + __u8 is_read;
> +
> + /** @pad: MBZ */
> + __u16 pad;
> +
> + /** @unk_5: Extra bits, hardware dependent */
> + __u32 extra;
> +
> + /** @address: Fault address, cache line aligned */
> + __u64 address;
> +};
> +
> +#define DRM_ASAHI_RESULT_RENDER_TVB_GROW_OVF (1UL << 0)
> +#define DRM_ASAHI_RESULT_RENDER_TVB_GROW_MIN (1UL << 1)
> +#define DRM_ASAHI_RESULT_RENDER_TVB_OVERFLOWED (1UL << 2)
> +
> +struct drm_asahi_result_render {
> + /** @address: Common result information */
> + struct drm_asahi_result_info info;
> +
> + /** @flags: Zero or more of of DRM_ASAHI_RESULT_RENDER_* */
> + __u64 flags;
> +
> + /** @vertex_ts_start: Timestamp of the start of vertex processing */
> + __u64 vertex_ts_start;
> +
> + /** @vertex_ts_end: Timestamp of the end of vertex processing */
> + __u64 vertex_ts_end;
> +
> + /** @fragment_ts_start: Timestamp of the start of fragment processing */
> + __u64 fragment_ts_start;
> +
> + /** @fragment_ts_end: Timestamp of the end of fragment processing */
> + __u64 fragment_ts_end;
> +
> + /** @tvb_size_bytes: TVB size at the start of this render */
> + __u64 tvb_size_bytes;
> +
> + /** @tvb_usage_bytes: Total TVB usage in bytes for this render */
> + __u64 tvb_usage_bytes;
> +
> + /** @num_tvb_overflows: Number of TVB overflows that occurred for this render */
> + __u32 num_tvb_overflows;
> +};
> +
> +struct drm_asahi_result_compute {
> + /** @address: Common result information */
> + struct drm_asahi_result_info info;
> +
> + /** @flags: Zero or more of of DRM_ASAHI_RESULT_COMPUTE_* */
> + __u64 flags;
> +
> + /** @ts_start: Timestamp of the start of this compute command */
> + __u64 ts_start;
> +
> + /** @vertex_ts_end: Timestamp of the end of this compute command */
> + __u64 ts_end;
> +};
> +
> +struct drm_asahi_get_time {
> + /** @extensions: Pointer to the first extension struct, if any */
> + __u64 extensions;
> +
> + /** @flags: MBZ. */
> + __u64 flags;
> +
> + /** @tv_sec: On return, seconds part of a point in time */
> + __s64 tv_sec;
> +
> + /** @tv_nsec: On return, nanoseconds part of a point in time */
> + __s64 tv_nsec;
> +
> + /** @gpu_timestamp: On return, the GPU timestamp at that point in time */
> + __u64 gpu_timestamp;
> +};
> +
> +/* Note: this is an enum so that it can be resolved by Rust bindgen. */
> +enum {
> + DRM_IOCTL_ASAHI_GET_PARAMS = DRM_IOWR(DRM_COMMAND_BASE + DRM_ASAHI_GET_PARAMS, struct drm_asahi_get_params),
> + DRM_IOCTL_ASAHI_VM_CREATE = DRM_IOWR(DRM_COMMAND_BASE + DRM_ASAHI_VM_CREATE, struct drm_asahi_vm_create),
> + DRM_IOCTL_ASAHI_VM_DESTROY = DRM_IOW(DRM_COMMAND_BASE + DRM_ASAHI_VM_DESTROY, struct drm_asahi_vm_destroy),
> + DRM_IOCTL_ASAHI_GEM_CREATE = DRM_IOWR(DRM_COMMAND_BASE + DRM_ASAHI_GEM_CREATE, struct drm_asahi_gem_create),
> + DRM_IOCTL_ASAHI_GEM_MMAP_OFFSET = DRM_IOWR(DRM_COMMAND_BASE + DRM_ASAHI_GEM_MMAP_OFFSET, struct drm_asahi_gem_mmap_offset),
> + DRM_IOCTL_ASAHI_GEM_BIND = DRM_IOW(DRM_COMMAND_BASE + DRM_ASAHI_GEM_BIND, struct drm_asahi_gem_bind),
> + DRM_IOCTL_ASAHI_QUEUE_CREATE = DRM_IOWR(DRM_COMMAND_BASE + DRM_ASAHI_QUEUE_CREATE, struct drm_asahi_queue_create),
> + DRM_IOCTL_ASAHI_QUEUE_DESTROY = DRM_IOW(DRM_COMMAND_BASE + DRM_ASAHI_QUEUE_DESTROY, struct drm_asahi_queue_destroy),
> + DRM_IOCTL_ASAHI_SUBMIT = DRM_IOW(DRM_COMMAND_BASE + DRM_ASAHI_SUBMIT, struct drm_asahi_submit),
> + DRM_IOCTL_ASAHI_GET_TIME = DRM_IOWR(DRM_COMMAND_BASE + DRM_ASAHI_GET_TIME, struct drm_asahi_get_time),
> +};
heh.. I had the same issue in mesa and wasn't thinking of doing this instead
> +
> +#if defined(__cplusplus)
> +}
> +#endif
> +
> +#endif /* _ASAHI_DRM_H_ */
>
> --
> 2.35.1
>
^ permalink raw reply [flat|nested] 122+ messages in thread
* [PATCH RFC 16/18] rust: bindings: Bind the Asahi DRM UAPI
2023-03-07 14:25 [PATCH RFC 00/18] Rust DRM subsystem abstractions (& preview AGX driver) Asahi Lina
` (14 preceding siblings ...)
2023-03-07 14:25 ` [PATCH RFC 15/18] drm/asahi: Add the Asahi driver UAPI [DO NOT MERGE] Asahi Lina
@ 2023-03-07 14:25 ` Asahi Lina
2023-03-07 14:25 ` [PATCH RFC 17/18] rust: macros: Add versions macro Asahi Lina
` (2 subsequent siblings)
18 siblings, 0 replies; 122+ messages in thread
From: Asahi Lina @ 2023-03-07 14:25 UTC (permalink / raw)
To: Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
David Airlie, Daniel Vetter, Miguel Ojeda, Alex Gaynor,
Wedson Almeida Filho, Boqun Feng, Gary Guo, Björn Roy Baron,
Sumit Semwal, Christian König, Luben Tuikov,
Jarkko Sakkinen, Dave Hansen
Cc: Alyssa Rosenzweig, Karol Herbst, Ella Stanforth, Faith Ekstrand,
Mary, linux-kernel, dri-devel, rust-for-linux, linux-media,
linaro-mm-sig, linux-sgx, asahi, Asahi Lina
Add the Asahi UAPI to bindings_helper.h so Rust code can use it.
Signed-off-by: Asahi Lina <lina@asahilina.net>
---
rust/bindings/bindings_helper.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/rust/bindings/bindings_helper.h b/rust/bindings/bindings_helper.h
index dc01be08676e..e21c87e6d317 100644
--- a/rust/bindings/bindings_helper.h
+++ b/rust/bindings/bindings_helper.h
@@ -35,6 +35,7 @@
#include <linux/sysctl.h>
#include <linux/timekeeping.h>
#include <linux/xarray.h>
+#include <uapi/drm/asahi_drm.h>
#include <uapi/drm/drm.h>
/* `bindgen` gets confused at certain things. */
--
2.35.1
^ permalink raw reply related [flat|nested] 122+ messages in thread* [PATCH RFC 17/18] rust: macros: Add versions macro
2023-03-07 14:25 [PATCH RFC 00/18] Rust DRM subsystem abstractions (& preview AGX driver) Asahi Lina
` (15 preceding siblings ...)
2023-03-07 14:25 ` [PATCH RFC 16/18] rust: bindings: Bind the Asahi DRM UAPI Asahi Lina
@ 2023-03-07 14:25 ` Asahi Lina
2023-03-07 16:17 ` [PATCH RFC 00/18] Rust DRM subsystem abstractions (& preview AGX driver) Asahi Lina
[not found] ` <20230307-rust-drm-v1-18-917ff5bc80a8@asahilina.net>
18 siblings, 0 replies; 122+ messages in thread
From: Asahi Lina @ 2023-03-07 14:25 UTC (permalink / raw)
To: Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
David Airlie, Daniel Vetter, Miguel Ojeda, Alex Gaynor,
Wedson Almeida Filho, Boqun Feng, Gary Guo, Björn Roy Baron,
Sumit Semwal, Christian König, Luben Tuikov,
Jarkko Sakkinen, Dave Hansen
Cc: Alyssa Rosenzweig, Karol Herbst, Ella Stanforth, Faith Ekstrand,
Mary, linux-kernel, dri-devel, rust-for-linux, linux-media,
linaro-mm-sig, linux-sgx, asahi, Asahi Lina
This macro allows Rust code to build multiple versions of the same code,
conditionally including certain fields or code segments.
The asahi driver uses this to support multiple GPU types and firmware
revisions in the same codebase, without duplicating everything.
Signed-off-by: Asahi Lina <lina@asahilina.net>
---
rust/macros/lib.rs | 7 ++
rust/macros/versions.rs | 267 ++++++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 274 insertions(+)
diff --git a/rust/macros/lib.rs b/rust/macros/lib.rs
index c1d385e345b9..3ab9bae4ab52 100644
--- a/rust/macros/lib.rs
+++ b/rust/macros/lib.rs
@@ -5,6 +5,7 @@
mod concat_idents;
mod helpers;
mod module;
+mod versions;
mod vtable;
use proc_macro::TokenStream;
@@ -73,6 +74,12 @@ pub fn module(ts: TokenStream) -> TokenStream {
module::module(ts)
}
+/// Declares multiple variants of a structure or impl code
+#[proc_macro_attribute]
+pub fn versions(attr: TokenStream, item: TokenStream) -> TokenStream {
+ versions::versions(attr, item)
+}
+
/// Declares or implements a vtable trait.
///
/// Linux's use of pure vtables is very close to Rust traits, but they differ
diff --git a/rust/macros/versions.rs b/rust/macros/versions.rs
new file mode 100644
index 000000000000..3bcd5f557289
--- /dev/null
+++ b/rust/macros/versions.rs
@@ -0,0 +1,267 @@
+use proc_macro::{token_stream, Group, Ident, Punct, Spacing, Span, TokenStream, TokenTree};
+
+use crate::helpers::{expect_group, expect_punct};
+
+fn drop_until_punct(it: &mut impl Iterator<Item = TokenTree>, delimiter: &str) {
+ let mut depth: isize = 0;
+ for token in it.by_ref() {
+ if let TokenTree::Punct(punct) = token {
+ match punct.as_char() {
+ '<' => {
+ depth += 1;
+ }
+ '>' => {
+ depth -= 1;
+ }
+ _ => {
+ if depth == 0 && delimiter.contains(&punct.to_string()) {
+ break;
+ }
+ }
+ }
+ }
+ }
+}
+
+struct VersionConfig {
+ fields: &'static [&'static str],
+ enums: &'static [&'static [&'static str]],
+ versions: &'static [&'static [&'static str]],
+}
+
+static AGX_VERSIONS: VersionConfig = VersionConfig {
+ fields: &["G", "V"],
+ enums: &[&["G13", "G14"], &["V12_3", "V12_4", "V13_0B4", "V13_2"]],
+ versions: &[
+ &["G13", "V12_3"],
+ &["G14", "V12_4"],
+ &["G13", "V13_2"],
+ &["G14", "V13_2"],
+ ],
+};
+
+fn check_version(config: &VersionConfig, ver: &[usize], it: &mut token_stream::IntoIter) -> bool {
+ let first = it.next().unwrap();
+ let val: bool = match &first {
+ TokenTree::Group(group) => check_version(config, ver, &mut group.stream().into_iter()),
+ TokenTree::Ident(ident) => {
+ let key = config
+ .fields
+ .iter()
+ .position(|&r| r == ident.to_string())
+ .unwrap_or_else(|| panic!("Unknown field {}", ident));
+ let mut operator = expect_punct(it).to_string();
+ let mut rhs_token = it.next().unwrap();
+ if let TokenTree::Punct(punct) = &rhs_token {
+ operator.extend(std::iter::once(punct.as_char()));
+ rhs_token = it.next().unwrap();
+ }
+ let rhs_name = if let TokenTree::Ident(ident) = &rhs_token {
+ ident.to_string()
+ } else {
+ panic!("Unexpected token {}", ident)
+ };
+
+ let rhs = config.enums[key]
+ .iter()
+ .position(|&r| r == rhs_name)
+ .unwrap_or_else(|| panic!("Unknown value for {}:{}", ident, rhs_name));
+ let lhs = ver[key];
+
+ match operator.as_str() {
+ "==" => lhs == rhs,
+ "!=" => lhs != rhs,
+ ">" => lhs > rhs,
+ ">=" => lhs >= rhs,
+ "<" => lhs < rhs,
+ "<=" => lhs <= rhs,
+ _ => panic!("Unknown operator {}", operator),
+ }
+ }
+ _ => {
+ panic!("Unknown token {}", first)
+ }
+ };
+
+ let boolop = it.next();
+ match boolop {
+ Some(TokenTree::Punct(punct)) => {
+ let right = expect_punct(it).to_string();
+ if right != punct.to_string() {
+ panic!("Unexpected op {}{}", punct, right);
+ }
+ match punct.as_char() {
+ '&' => val && check_version(config, ver, it),
+ '|' => val || check_version(config, ver, it),
+ _ => panic!("Unexpected op {}{}", right, right),
+ }
+ }
+ Some(a) => panic!("Unexpected op {}", a),
+ None => val,
+ }
+}
+
+fn filter_versions(
+ config: &VersionConfig,
+ tag: &str,
+ ver: &[usize],
+ mut it: &mut token_stream::IntoIter,
+ is_struct: bool,
+) -> Vec<TokenTree> {
+ let mut out = Vec::<TokenTree>::new();
+
+ while let Some(token) = it.next() {
+ let mut tail: Option<TokenTree> = None;
+ match &token {
+ TokenTree::Punct(punct) if punct.to_string() == "#" => {
+ let group = expect_group(it);
+ let mut grp_it = group.stream().into_iter();
+ let attr = grp_it.next().unwrap();
+ match attr {
+ TokenTree::Ident(ident) if ident.to_string() == "ver" => {
+ if check_version(config, ver, &mut grp_it) {
+ } else if is_struct {
+ drop_until_punct(&mut it, ",");
+ } else {
+ let first = it.next().unwrap();
+ match &first {
+ TokenTree::Group(_) => (),
+ _ => {
+ drop_until_punct(&mut it, ",;");
+ }
+ }
+ }
+ }
+ _ => {
+ out.push(token.clone());
+ out.push(TokenTree::Group(group.clone()));
+ }
+ }
+ continue;
+ }
+ TokenTree::Punct(punct) if punct.to_string() == ":" => {
+ let next = it.next();
+ match next {
+ Some(TokenTree::Punct(punct)) if punct.to_string() == ":" => {
+ let next = it.next();
+ match next {
+ Some(TokenTree::Ident(idtag)) if idtag.to_string() == "ver" => {
+ let ident = match out.pop() {
+ Some(TokenTree::Ident(ident)) => ident,
+ a => panic!("$ver not following ident: {:?}", a),
+ };
+ let name = ident.to_string() + tag;
+ let new_ident = Ident::new(name.as_str(), ident.span());
+ out.push(TokenTree::Ident(new_ident));
+ continue;
+ }
+ Some(a) => {
+ out.push(token.clone());
+ out.push(token.clone());
+ tail = Some(a);
+ }
+ None => {
+ out.push(token.clone());
+ out.push(token.clone());
+ }
+ }
+ }
+ Some(a) => {
+ out.push(token.clone());
+ tail = Some(a);
+ }
+ None => {
+ out.push(token.clone());
+ continue;
+ }
+ }
+ }
+ _ => {
+ tail = Some(token);
+ }
+ }
+ match &tail {
+ Some(TokenTree::Group(group)) => {
+ let new_body =
+ filter_versions(config, tag, ver, &mut group.stream().into_iter(), is_struct);
+ let mut stream = TokenStream::new();
+ stream.extend(new_body);
+ let mut filtered_group = Group::new(group.delimiter(), stream);
+ filtered_group.set_span(group.span());
+ out.push(TokenTree::Group(filtered_group));
+ }
+ Some(token) => {
+ out.push(token.clone());
+ }
+ None => {}
+ }
+ }
+
+ out
+}
+
+pub(crate) fn versions(attr: TokenStream, item: TokenStream) -> TokenStream {
+ let config = match attr.to_string().as_str() {
+ "AGX" => &AGX_VERSIONS,
+ _ => panic!("Unknown version group {}", attr),
+ };
+
+ let mut it = item.into_iter();
+ let mut out = TokenStream::new();
+ let mut body: Vec<TokenTree> = Vec::new();
+ let mut is_struct = false;
+
+ while let Some(token) = it.next() {
+ match token {
+ TokenTree::Punct(punct) if punct.to_string() == "#" => {
+ body.push(TokenTree::Punct(punct));
+ body.push(it.next().unwrap());
+ }
+ TokenTree::Ident(ident)
+ if ["struct", "enum", "union", "const", "type"]
+ .contains(&ident.to_string().as_str()) =>
+ {
+ is_struct = ident.to_string() != "const";
+ body.push(TokenTree::Ident(ident));
+ body.push(it.next().unwrap());
+ // This isn't valid syntax in a struct definition, so add it for the user
+ body.push(TokenTree::Punct(Punct::new(':', Spacing::Joint)));
+ body.push(TokenTree::Punct(Punct::new(':', Spacing::Alone)));
+ body.push(TokenTree::Ident(Ident::new("ver", Span::call_site())));
+ break;
+ }
+ TokenTree::Ident(ident) if ident.to_string() == "impl" => {
+ body.push(TokenTree::Ident(ident));
+ break;
+ }
+ TokenTree::Ident(ident) if ident.to_string() == "fn" => {
+ body.push(TokenTree::Ident(ident));
+ break;
+ }
+ _ => {
+ body.push(token);
+ }
+ }
+ }
+
+ body.extend(it);
+
+ for ver in config.versions {
+ let tag = ver.join("");
+ let mut ver_num = Vec::<usize>::new();
+ for (i, comp) in ver.iter().enumerate() {
+ let idx = config.enums[i].iter().position(|&r| r == *comp).unwrap();
+ ver_num.push(idx);
+ }
+ let tt = TokenStream::from_iter(body.clone().into_iter());
+ out.extend(filter_versions(
+ config,
+ &tag,
+ &ver_num,
+ &mut tt.into_iter(),
+ is_struct,
+ ));
+ }
+
+ out
+}
--
2.35.1
^ permalink raw reply related [flat|nested] 122+ messages in thread* Re: [PATCH RFC 00/18] Rust DRM subsystem abstractions (& preview AGX driver)
2023-03-07 14:25 [PATCH RFC 00/18] Rust DRM subsystem abstractions (& preview AGX driver) Asahi Lina
` (16 preceding siblings ...)
2023-03-07 14:25 ` [PATCH RFC 17/18] rust: macros: Add versions macro Asahi Lina
@ 2023-03-07 16:17 ` Asahi Lina
[not found] ` <20230307-rust-drm-v1-18-917ff5bc80a8@asahilina.net>
18 siblings, 0 replies; 122+ messages in thread
From: Asahi Lina @ 2023-03-07 16:17 UTC (permalink / raw)
To: Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
David Airlie, Daniel Vetter, Miguel Ojeda, Alex Gaynor,
Wedson Almeida Filho, Boqun Feng, Gary Guo, Björn Roy Baron,
Sumit Semwal, Christian König, Luben Tuikov,
Jarkko Sakkinen, Dave Hansen
Cc: Alyssa Rosenzweig, Karol Herbst, Ella Stanforth, Faith Ekstrand,
Mary, linux-kernel, dri-devel, rust-for-linux, linux-media,
linaro-mm-sig, linux-sgx, asahi
That was supposed to have Markdown-style section headings, but I forgot
that b4 considers a leading # as a comment... sorry for the abrupt topic
changes...
The intended headings are below.
On 07/03/2023 23.25, Asahi Lina wrote:
> Hi everyone!
>
> This is my first take on the Rust abstractions for the DRM
> subsystem. It includes the abstractions themselves, some minor
> prerequisite changes to the C side, as well as the drm-asahi GPU driver
> (for reference on how the abstractions are used, but not necessarily
> intended to land together).
>
> These patches apply on top of the tree at [1], which is based on
> 6.3-rc1 with a large number of Rust abstraction/support commits added on
> top. Most of these are not prerequisites for the DRM abstractions
> themselves, but rather only of the driver.
>
> * #1-12 introduce the abstractions, module by module, with minor C
> changes before the dependent abstraction.
> * Patch 10 is a little addition to drm_sched that I ended up needing,
> but I can pull it out of the abstraction into its own patch if
> needed.
> * #13-14 add a minor feature to drm/gem and its abstraction used
> by the driver.
> * #15-16 introduce the (unstable) asahi UAPI. This is obviously not
> ready for merge yet, but comments are welcome!
> * #17 adds a Rust helper macro to handle GPU core/firmware differences.
> This probably belongs in the driver at this point, but right now it
> has to live in rust/macros since there is no mechanism for per-driver
> proc macros.
> * #18 adds the driver proper, in one big commit, for reference purposes.
## Background
> I've been working since mid last year on an Apple AGX GPU driver for
> Linux, using the (at the time) out-of-tree Rust support. As part of this
> effort, I've been writing safe Rust abstractions for portions of the DRM
> subsystem.
>
> Now that Rust itself is upstream, I'd like to get all the abstractions
> upstreamed so we can eventually get the driver upstreamed!
>
> These abstractions have been used by the driver since our release in
> December [2], in a simpler synchronous-submission form:
>
> * drm::ioctl
> * drm::device
> * drm::drv
> * drm::file
> * drm::{gem, gem::shmem}
> * drm::mm
>
> This series adds these too, which are used by the explicit sync refactor
> of the driver (the version in this series):
>
> * drm::syncobj
> * drm::sched
> * dma_fence
>
> The major dependencies for the DRM abstractions themselves are:
>
> * [3] rust: error: Add missing wrappers to convert to/from kernel error codes
> * [4] rust: Miscellaneous macro improvements
> * [5] rust: Add a Sealed trait
> * [6] rust: device: Add a minimal RawDevice trait
> * [7] rust: Enable the new_uninit feature for kernel and driver crates
> * [8] rust: ioctl: Add ioctl number manipulation functions
> * [9] rust: sync: Arc: Any downcasting and assume_init()
> * rust: Add `container_of` and `offset_of` macros
> * kernel::sync::mutex and dependencies
>
> Most of these (the ones with links) have already been submitted, and I
> expect all of them to land for 6.4 (the mutex one will likely be last,
> since there is some refactoring that will happen over the current state
> to make it more ergonomic to use). The mutex dep is only necessary for
> drm::mm and dma_fence, and transitively drm::syncobj and drm::sched.
## State
> Things work! We've had most of the abstractions in production edge
> kernels with the driver, and the new explicit sync stuff has passed
> quite a few torture tests (this is how we found the drm_sched issue,
> patch 11).
>
> The abstractions are intended to be safe (safety review very welcome!).
> While writing them, I tried to avoid making any changes to the C side
> unless absolutely necessary. I understand that it will probably make
> sense to adjust the C side to make some things easier, but I wanted to
> start from this as a baseline.
>
> Known issues:
>
> - The existing Rust integration does not currently allow building
> abstractions as modules, so the Rust abstractions are only available
> for DRM components that are built in. I added some extra Kconfig
> symbols to deal with this, so a driver built as a module can depende
> on having those built in. This should go away in the future (but may
> not be ready in time for submission... I understand this probably
> shouldn't be a blocker though?).
>
> - DRM relies heavily on the "subclassing" pattern for driver objects,
> and this doesn't map well to Rust. I tried several approaches for
> various bits, so we can see how they work out. In particular, whether
> wrapper types should pretend to be smart pointers and Deref to their
> inner driver-specific types, and whether they should be marked as
> method receivers (Yuck, internal rustc implementation hacks! But
> Arc<T> already does the same thing and it makes usage in
> driver-implemented callbacks as `self` possible) are things I'd love
> to discuss ^^.
>
> - Only what I need for my driver is implemented (plus a small amount of
> obvious extras where better API completeness makes sense). I think the
> general idea with Rust abstractions is that we add things as they
> become necessary.
>
> - The plain GEM vs. GEM-shmem duality ended up with quite a hairy type
> hierarchy. I'd love to figure out how to make this simpler...
>
> - drm::mm ends up requiring a built-in mutex in the abstraction, instead
> of delegating that to the user with the usual Rust mutability rules.
> This is because nodes can be dropped at any time, and those operations
> need to be synchronized. We could try to avoid forbidding those drops
> or mark the node type !Send, but that would make it a lot less
> ergonomic to use...
>
> I'm looking for feedback on the abstractions of all kinds, so we can
> move towards an upstreamable version. Optimistically, I'd love to get
> this upstream for 6.5, and the driver for 6.6.
>
> Please feel free to ask any questions about the Rust bits, since I know
> a lot of this is new to many of the C folks!
## About the drm-asahi driver
> This is a fairly complete driver for Apple AGX G13 and G14 series GPUs.
>
> The driver today supports the Apple M1, M1 Pro, M1 Max, M1 Ultra, and M2
> SoCs, across two firmware revisions each. It has an explicit sync UAPI
> heavily inspired by the upcoming Intel Xe UAPI, designed with Vulkan
> support in mind. On the Mesa side we currently have a Gallium driver
> that is mostly already upstream (missing the UAPI bits mostly) and
> passes the dEQP GLES2/EGL tests, with most of GLES3.0 passing in
> downstream work-in-progress branches. This is a reverse engineered
> community driver (we have no hardware documentation of any kind, other
> than some hints from aspects shared with PowerVR).
>
> While developing the driver, I tried to make use of Rust's safety and
> lifetime features to provide not just CPU-side safety, but also
> partial firmware-ABI safety. Thanks to this, it has turned out to be
> a very stable driver even though GPU firmware crashes are fatal (no
> restart capability, need to reboot!) and the FW/driver interface is a
> huge mess of unsafe shared memory structures with complex pointer
> chains. There are over 70 ABI types and 3000+ lines of firmware ABI type
> definitions that vary between firmware builds and GPU cores...
>
> In a simpler blocking-submission form, it has been shipping in Asahi
> Linux edge kernels since December [2], with lots of users and zero (!)
> reported oopses (and only a couple reports of GPU firmware crashes,
> though that issue should now be fixed). It has survived OOM scenarios
> (Rust makes error cleanup easy!), UAPI-level fuzzing, countless broken
> Mesa builds, uptimes of 40+ days, and more.
>
> The explicit sync refactor significantly increases performance (and
> potential problems), but this version has survived a lot of torture
> with dEQP/piglit tests and some manual corner case testing.
>
> In other words, Rust works! ^^
>
> There are some design notes on the driver and further links at [10].
## Links
> [1] https://github.com/AsahiLinux/linux.git drm-rfc-base-20230307
> [2] https://asahilinux.org/2022/12/gpu-drivers-now-in-asahi-linux/
> [3] https://lore.kernel.org/rust-for-linux/20230224-rust-error-v1-0-f8f9a9a87303@asahilina.net/T/
> [4] https://lore.kernel.org/rust-for-linux/20230224-rust-macros-v1-0-b39fae46e102@asahilina.net/T/
> [5] https://lore.kernel.org/rust-for-linux/20230224-rust-iopt-rtkit-v1-0-49ced3391295@asahilina.net/T/#m515bad2cff7f5a46f55897e6b73c6c2f1fb2c638
> [6] https://lore.kernel.org/rust-for-linux/20230224-rust-iopt-rtkit-v1-0-49ced3391295@asahilina.net/T/#m4c64e390c43b3ff1b8470fc8b37eaf87f6e12c94
> [7] https://lore.kernel.org/rust-for-linux/CQV7ZNT6LMXI.1XG4YXSH8I7JK@vincent-arch/T/
> [8] https://lore.kernel.org/rust-for-linux/61f734d6-1497-755f-3632-3f261b890846@asahilina.net/T/
> [9] https://lore.kernel.org/rust-for-linux/20230224-rust-arc-v1-0-568eea613a41@asahilina.net/T/
> [10] https://github.com/AsahiLinux/docs/wiki/SW:AGX-driver-notes
~~ Lina
^ permalink raw reply [flat|nested] 122+ messages in thread[parent not found: <20230307-rust-drm-v1-18-917ff5bc80a8@asahilina.net>]
* Re: [PATCH RFC 18/18] drm/asahi: Add the Asahi driver for Apple AGX GPUs
[not found] ` <20230307-rust-drm-v1-18-917ff5bc80a8@asahilina.net>
@ 2023-04-05 14:44 ` Daniel Vetter
2023-04-06 5:02 ` Asahi Lina
[not found] ` <ZC2HtBOaoUAzVCVH@phenom.ffwll.local>
1 sibling, 1 reply; 122+ messages in thread
From: Daniel Vetter @ 2023-04-05 14:44 UTC (permalink / raw)
To: Asahi Lina
Cc: Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
David Airlie, Daniel Vetter, Miguel Ojeda, Alex Gaynor,
Wedson Almeida Filho, Boqun Feng, Gary Guo, Björn Roy Baron,
Sumit Semwal, Christian König, Luben Tuikov,
Jarkko Sakkinen, Dave Hansen, Alyssa Rosenzweig, Karol Herbst,
Ella Stanforth, Faith Ekstrand, Mary, linux-kernel, dri-devel,
rust-for-linux, linux-media, linaro-mm-sig, linux-sgx, asahi
On Tue, Mar 07, 2023 at 11:25:43PM +0900, Asahi Lina wrote:
> +/// Look up a GEM object handle for a `File` and return an `ObjectRef` for it.
> +pub(crate) fn lookup_handle(file: &DrmFile, handle: u32) -> Result<ObjectRef> {
> + Ok(ObjectRef::new(shmem::Object::lookup_handle(file, handle)?))
> +}
So maybe my expectations for rust typing is a bit too much, but I kinda
expected this to be fully generic:
- trait Driver (drm_driver) knows the driver's object type
- a generic create_handle function could ensure that for drm_file (which
is always for a specific drm_device and hence Driver) can ensure at the
type level that you only put the right objects into the drm_file
- a generic lookup_handle function on the drm_file knows the Driver trait
and so can give you back the right type right away.
Why the wrapping, what do I miss?
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
^ permalink raw reply [flat|nested] 122+ messages in thread* Re: [PATCH RFC 18/18] drm/asahi: Add the Asahi driver for Apple AGX GPUs
2023-04-05 14:44 ` [PATCH RFC 18/18] drm/asahi: Add the Asahi driver for Apple AGX GPUs Daniel Vetter
@ 2023-04-06 5:02 ` Asahi Lina
2023-04-06 5:09 ` Asahi Lina
2023-04-06 11:25 ` [Linaro-mm-sig] " Daniel Vetter
0 siblings, 2 replies; 122+ messages in thread
From: Asahi Lina @ 2023-04-06 5:02 UTC (permalink / raw)
To: David Airlie
Cc: Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
Miguel Ojeda, Alex Gaynor, Wedson Almeida Filho, Boqun Feng,
Gary Guo, Björn Roy Baron, Sumit Semwal,
Christian König, Luben Tuikov, Jarkko Sakkinen, Dave Hansen,
Alyssa Rosenzweig, Karol Herbst, Ella Stanforth, Faith Ekstrand,
Mary, linux-kernel, dri-devel, rust-for-linux, linux-media,
linaro-mm-sig, linux-sgx, asahi
On 05/04/2023 23.44, Daniel Vetter wrote:
> On Tue, Mar 07, 2023 at 11:25:43PM +0900, Asahi Lina wrote:
>> +/// Look up a GEM object handle for a `File` and return an `ObjectRef` for it.
>> +pub(crate) fn lookup_handle(file: &DrmFile, handle: u32) -> Result<ObjectRef> {
>> + Ok(ObjectRef::new(shmem::Object::lookup_handle(file, handle)?))
>> +}
>
> So maybe my expectations for rust typing is a bit too much, but I kinda
> expected this to be fully generic:
>
> - trait Driver (drm_driver) knows the driver's object type
> - a generic create_handle function could ensure that for drm_file (which
> is always for a specific drm_device and hence Driver) can ensure at the
> type level that you only put the right objects into the drm_file
> - a generic lookup_handle function on the drm_file knows the Driver trait
> and so can give you back the right type right away.
>
> Why the wrapping, what do I miss?
Sigh, so this is one of the many ways I'm trying to work around the
"Rust doesn't do subclasses" problem (so we can figure out what the best
one is ^^).
The generic shmem::Object::lookup_handle() call *is* fully generic and
will get you back a driver-specific object. But since Rust doesn't do
subclassing, what you get back isn't a driver-specific type T, but
rather a (reference to a) shmem::Object<T>. T represents the inner
driver-specific data/functionality (only), and the outer
shmem::Object<T> includes the actual drm_gem_shmem_object plus a T. This
is backwards from C, where you expect the opposite situation where T
contains a shmem object, but that just doesn't work with Rust because
there's no way to build a safe API around that model as far as I know.
Now the problem is from the higher layers I want object operations that
interact with the shmem::Object<T> (that is, they call generic GEM
functions on the object). Options so far:
1. Add an outer wrapper and put that functionality there.
2. Just have the functions on T as helpers, so you need to call
T::foo(obj) instead of obj.foo().
3. Use the undocumented method receiver trait thing to make
shmem::Object<T> a valid `self` type, plus add auto-Deref to
shmem::Object. Then obj.foo() works.
#1 is what I use here. #2 is how the driver-specific File ioctl
callbacks are implemented, and also sched::Job<T>. #3 is used for fence
callbacks (FenceObject<T>). None of them are great, and I'd love to hear
what people think of the various options...
There are other unexplored options, like in this GEM case it could be
covered with a driver-internal auxiliary trait impl'd on
shmem::Object<T> buuut that doesn't work when you actually need
callbacks on T itself to circle back to shmem::Object<T>, as is the case
with File/Job/FenceObject.
~~ Lina
^ permalink raw reply [flat|nested] 122+ messages in thread* Re: [PATCH RFC 18/18] drm/asahi: Add the Asahi driver for Apple AGX GPUs
2023-04-06 5:02 ` Asahi Lina
@ 2023-04-06 5:09 ` Asahi Lina
2023-04-06 11:25 ` [Linaro-mm-sig] " Daniel Vetter
1 sibling, 0 replies; 122+ messages in thread
From: Asahi Lina @ 2023-04-06 5:09 UTC (permalink / raw)
To: Daniel Vetter
Cc: Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
Miguel Ojeda, Alex Gaynor, Wedson Almeida Filho, Boqun Feng,
Gary Guo, Björn Roy Baron, Sumit Semwal,
Christian König, Luben Tuikov, Jarkko Sakkinen, Dave Hansen,
Alyssa Rosenzweig, Karol Herbst, Ella Stanforth, Faith Ekstrand,
Mary, linux-kernel, dri-devel, rust-for-linux, linux-media,
linaro-mm-sig, linux-sgx, asahi, David Airlie
Same as the prior email, this was supposed to go to Daniel...
On 06/04/2023 14.02, Asahi Lina wrote:
> On 05/04/2023 23.44, Daniel Vetter wrote:
>> On Tue, Mar 07, 2023 at 11:25:43PM +0900, Asahi Lina wrote:
>>> +/// Look up a GEM object handle for a `File` and return an `ObjectRef` for it.
>>> +pub(crate) fn lookup_handle(file: &DrmFile, handle: u32) -> Result<ObjectRef> {
>>> + Ok(ObjectRef::new(shmem::Object::lookup_handle(file, handle)?))
>>> +}
>>
>> So maybe my expectations for rust typing is a bit too much, but I kinda
>> expected this to be fully generic:
>>
>> - trait Driver (drm_driver) knows the driver's object type
>> - a generic create_handle function could ensure that for drm_file (which
>> is always for a specific drm_device and hence Driver) can ensure at the
>> type level that you only put the right objects into the drm_file
>> - a generic lookup_handle function on the drm_file knows the Driver trait
>> and so can give you back the right type right away.
>>
>> Why the wrapping, what do I miss?
>
> Sigh, so this is one of the many ways I'm trying to work around the
> "Rust doesn't do subclasses" problem (so we can figure out what the best
> one is ^^).
>
> The generic shmem::Object::lookup_handle() call *is* fully generic and
> will get you back a driver-specific object. But since Rust doesn't do
> subclassing, what you get back isn't a driver-specific type T, but
> rather a (reference to a) shmem::Object<T>. T represents the inner
> driver-specific data/functionality (only), and the outer
> shmem::Object<T> includes the actual drm_gem_shmem_object plus a T. This
> is backwards from C, where you expect the opposite situation where T
> contains a shmem object, but that just doesn't work with Rust because
> there's no way to build a safe API around that model as far as I know.
>
> Now the problem is from the higher layers I want object operations that
> interact with the shmem::Object<T> (that is, they call generic GEM
> functions on the object). Options so far:
>
> 1. Add an outer wrapper and put that functionality there.
> 2. Just have the functions on T as helpers, so you need to call
> T::foo(obj) instead of obj.foo().
> 3. Use the undocumented method receiver trait thing to make
> shmem::Object<T> a valid `self` type, plus add auto-Deref to
> shmem::Object. Then obj.foo() works.
>
> #1 is what I use here. #2 is how the driver-specific File ioctl
> callbacks are implemented, and also sched::Job<T>. #3 is used for fence
> callbacks (FenceObject<T>). None of them are great, and I'd love to hear
> what people think of the various options...
>
> There are other unexplored options, like in this GEM case it could be
> covered with a driver-internal auxiliary trait impl'd on
> shmem::Object<T> buuut that doesn't work when you actually need
> callbacks on T itself to circle back to shmem::Object<T>, as is the case
> with File/Job/FenceObject.
>
> ~~ Lina
>
~~ Lina
^ permalink raw reply [flat|nested] 122+ messages in thread* Re: [Linaro-mm-sig] Re: [PATCH RFC 18/18] drm/asahi: Add the Asahi driver for Apple AGX GPUs
2023-04-06 5:02 ` Asahi Lina
2023-04-06 5:09 ` Asahi Lina
@ 2023-04-06 11:25 ` Daniel Vetter
2023-04-06 13:32 ` Asahi Lina
1 sibling, 1 reply; 122+ messages in thread
From: Daniel Vetter @ 2023-04-06 11:25 UTC (permalink / raw)
To: Asahi Lina
Cc: David Airlie, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, Miguel Ojeda, Alex Gaynor,
Wedson Almeida Filho, Boqun Feng, Gary Guo, Björn Roy Baron,
Sumit Semwal, Christian König, Luben Tuikov,
Jarkko Sakkinen, Dave Hansen, Alyssa Rosenzweig, Karol Herbst,
Ella Stanforth, Faith Ekstrand, Mary, linux-kernel, dri-devel,
rust-for-linux, linux-media, linaro-mm-sig, linux-sgx, asahi
On Thu, Apr 06, 2023 at 02:02:55PM +0900, Asahi Lina wrote:
> On 05/04/2023 23.44, Daniel Vetter wrote:
> > On Tue, Mar 07, 2023 at 11:25:43PM +0900, Asahi Lina wrote:
> > > +/// Look up a GEM object handle for a `File` and return an `ObjectRef` for it.
> > > +pub(crate) fn lookup_handle(file: &DrmFile, handle: u32) -> Result<ObjectRef> {
> > > + Ok(ObjectRef::new(shmem::Object::lookup_handle(file, handle)?))
> > > +}
> >
> > So maybe my expectations for rust typing is a bit too much, but I kinda
> > expected this to be fully generic:
> >
> > - trait Driver (drm_driver) knows the driver's object type
> > - a generic create_handle function could ensure that for drm_file (which
> > is always for a specific drm_device and hence Driver) can ensure at the
> > type level that you only put the right objects into the drm_file
> > - a generic lookup_handle function on the drm_file knows the Driver trait
> > and so can give you back the right type right away.
> >
> > Why the wrapping, what do I miss?
>
> Sigh, so this is one of the many ways I'm trying to work around the "Rust
> doesn't do subclasses" problem (so we can figure out what the best one is
> ^^).
>
> The generic shmem::Object::lookup_handle() call *is* fully generic and will
> get you back a driver-specific object. But since Rust doesn't do
> subclassing, what you get back isn't a driver-specific type T, but rather a
> (reference to a) shmem::Object<T>. T represents the inner driver-specific
> data/functionality (only), and the outer shmem::Object<T> includes the
> actual drm_gem_shmem_object plus a T. This is backwards from C, where you
> expect the opposite situation where T contains a shmem object, but that just
> doesn't work with Rust because there's no way to build a safe API around
> that model as far as I know.
Ah I think I just got confused. I did untangle (I think at least) the
Object<T> trick, I guess the only thing that confused me here is why this
is in the shmem module? Or is that the rust problem again?
I'd kinda have expected that we'd have a gem::Object<T> here that the
lookup_handle function returns. So for the shmem case I guess that would
then be gem::Object<shmem::Object<T>> for the driver type T with driver
specific stuff? I guess not very pretty ...
> Now the problem is from the higher layers I want object operations that
> interact with the shmem::Object<T> (that is, they call generic GEM functions
> on the object). Options so far:
>
> 1. Add an outer wrapper and put that functionality there.
> 2. Just have the functions on T as helpers, so you need to call T::foo(obj)
> instead of obj.foo().
> 3. Use the undocumented method receiver trait thing to make shmem::Object<T>
> a valid `self` type, plus add auto-Deref to shmem::Object. Then obj.foo()
> works.
>
> #1 is what I use here. #2 is how the driver-specific File ioctl callbacks
> are implemented, and also sched::Job<T>. #3 is used for fence callbacks
> (FenceObject<T>). None of them are great, and I'd love to hear what people
> think of the various options...
>
> There are other unexplored options, like in this GEM case it could be
> covered with a driver-internal auxiliary trait impl'd on shmem::Object<T>
> buuut that doesn't work when you actually need callbacks on T itself to
> circle back to shmem::Object<T>, as is the case with File/Job/FenceObject.
Ok I think I'm completely lost here. But I also havent' looked at how this
is all really used in the driver, it's really just the shmem:: module in
the lookup_handle function which looked strange to me.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
hvettp://blog.ffwll.ch
^ permalink raw reply [flat|nested] 122+ messages in thread* Re: [Linaro-mm-sig] Re: [PATCH RFC 18/18] drm/asahi: Add the Asahi driver for Apple AGX GPUs
2023-04-06 11:25 ` [Linaro-mm-sig] " Daniel Vetter
@ 2023-04-06 13:32 ` Asahi Lina
2023-04-06 13:54 ` Daniel Vetter
0 siblings, 1 reply; 122+ messages in thread
From: Asahi Lina @ 2023-04-06 13:32 UTC (permalink / raw)
To: Daniel Vetter
Cc: David Airlie, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, Miguel Ojeda, Alex Gaynor,
Wedson Almeida Filho, Boqun Feng, Gary Guo, Björn Roy Baron,
Sumit Semwal, Christian König, Luben Tuikov,
Jarkko Sakkinen, Dave Hansen, Alyssa Rosenzweig, Karol Herbst,
Ella Stanforth, Faith Ekstrand, Mary, linux-kernel, dri-devel,
rust-for-linux, linux-media, linaro-mm-sig, linux-sgx, asahi
On 06/04/2023 20.25, Daniel Vetter wrote:
> On Thu, Apr 06, 2023 at 02:02:55PM +0900, Asahi Lina wrote:
>> On 05/04/2023 23.44, Daniel Vetter wrote:
>>> On Tue, Mar 07, 2023 at 11:25:43PM +0900, Asahi Lina wrote:
>>>> +/// Look up a GEM object handle for a `File` and return an `ObjectRef` for it.
>>>> +pub(crate) fn lookup_handle(file: &DrmFile, handle: u32) -> Result<ObjectRef> {
>>>> + Ok(ObjectRef::new(shmem::Object::lookup_handle(file, handle)?))
>>>> +}
>>>
>>> So maybe my expectations for rust typing is a bit too much, but I kinda
>>> expected this to be fully generic:
>>>
>>> - trait Driver (drm_driver) knows the driver's object type
>>> - a generic create_handle function could ensure that for drm_file (which
>>> is always for a specific drm_device and hence Driver) can ensure at the
>>> type level that you only put the right objects into the drm_file
>>> - a generic lookup_handle function on the drm_file knows the Driver trait
>>> and so can give you back the right type right away.
>>>
>>> Why the wrapping, what do I miss?
>>
>> Sigh, so this is one of the many ways I'm trying to work around the "Rust
>> doesn't do subclasses" problem (so we can figure out what the best one is
>> ^^).
>>
>> The generic shmem::Object::lookup_handle() call *is* fully generic and will
>> get you back a driver-specific object. But since Rust doesn't do
>> subclassing, what you get back isn't a driver-specific type T, but rather a
>> (reference to a) shmem::Object<T>. T represents the inner driver-specific
>> data/functionality (only), and the outer shmem::Object<T> includes the
>> actual drm_gem_shmem_object plus a T. This is backwards from C, where you
>> expect the opposite situation where T contains a shmem object, but that just
>> doesn't work with Rust because there's no way to build a safe API around
>> that model as far as I know.
>
> Ah I think I just got confused. I did untangle (I think at least) the
> Object<T> trick, I guess the only thing that confused me here is why this
> is in the shmem module? Or is that the rust problem again?
>
> I'd kinda have expected that we'd have a gem::Object<T> here that the
> lookup_handle function returns. So for the shmem case I guess that would
> then be gem::Object<shmem::Object<T>> for the driver type T with driver
> specific stuff? I guess not very pretty ...
Ahh, uh... Yeah, so shmem objects are allocated their own way (the shmem
core expects to kfree them in drm_gem_shmem_free) and
bindings::drm_gem_shmem_object already contains a
bindings::drm_gem_object. Since the composition is already done in the C
side, we can't just do it again in Rust cleanly. That's why I have this
weird setup with both a common trait for common GEM functionality and
separate actual types that both implement it.
Honestly the whole GEM codepath is untested other than the bits
inherited by shmem. I'm not sure I'll be able to verify that this all
makes sense until another Rust driver comes along that needs something
other than shmem. I just felt I had to do *something* for GEM since the
hierarchy is there and I needed shmem...
This whole gem stuff is IMO the messiest part of the abstractions
though, so I'm happy to turn it on its head if it makes it better and
someone has an idea of how to do that ^^
>> Now the problem is from the higher layers I want object operations that
>> interact with the shmem::Object<T> (that is, they call generic GEM functions
>> on the object). Options so far:
>>
>> 1. Add an outer wrapper and put that functionality there.
>> 2. Just have the functions on T as helpers, so you need to call T::foo(obj)
>> instead of obj.foo().
>> 3. Use the undocumented method receiver trait thing to make shmem::Object<T>
>> a valid `self` type, plus add auto-Deref to shmem::Object. Then obj.foo()
>> works.
>>
>> #1 is what I use here. #2 is how the driver-specific File ioctl callbacks
>> are implemented, and also sched::Job<T>. #3 is used for fence callbacks
>> (FenceObject<T>). None of them are great, and I'd love to hear what people
>> think of the various options...
>>
>> There are other unexplored options, like in this GEM case it could be
>> covered with a driver-internal auxiliary trait impl'd on shmem::Object<T>
>> buuut that doesn't work when you actually need callbacks on T itself to
>> circle back to shmem::Object<T>, as is the case with File/Job/FenceObject.
>
> Ok I think I'm completely lost here. But I also havent' looked at how this
> is all really used in the driver, it's really just the shmem:: module in
> the lookup_handle function which looked strange to me.
Ah, sorry, I misunderstood what you were talking about in my previous
email then. That's just a default trait function. It comes from common
functionality in the gem module, but shmem::Object implements the trait
so it ends up offering it too (lookup_handle() is not duplicated, it
only lives in gem, shmem only has to implement going to/from the
drm_gem_object pointer so the rest of the methods can use it). That's
part of why the type/trait hierarchy is kind of messy here, it's so I
can share functionality between both types even though they are
pre-composed on the C side.
In the end the object types are specialized for any given driver, so
you're always getting your own unique kind of object anyway. It's just
that drivers based on shmem will go through it to reach the common code
and work with a shmem::Object<T>, and drivers using raw gem will use
gem::Object<T> instead.
~~ Lina
^ permalink raw reply [flat|nested] 122+ messages in thread* Re: [Linaro-mm-sig] Re: [PATCH RFC 18/18] drm/asahi: Add the Asahi driver for Apple AGX GPUs
2023-04-06 13:32 ` Asahi Lina
@ 2023-04-06 13:54 ` Daniel Vetter
0 siblings, 0 replies; 122+ messages in thread
From: Daniel Vetter @ 2023-04-06 13:54 UTC (permalink / raw)
To: Asahi Lina
Cc: Daniel Vetter, David Airlie, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, Miguel Ojeda, Alex Gaynor,
Wedson Almeida Filho, Boqun Feng, Gary Guo, Björn Roy Baron,
Sumit Semwal, Christian König, Luben Tuikov,
Jarkko Sakkinen, Dave Hansen, Alyssa Rosenzweig, Karol Herbst,
Ella Stanforth, Faith Ekstrand, Mary, linux-kernel, dri-devel,
rust-for-linux, linux-media, linaro-mm-sig, linux-sgx, asahi
On Thu, Apr 06, 2023 at 10:32:29PM +0900, Asahi Lina wrote:
> On 06/04/2023 20.25, Daniel Vetter wrote:
> > On Thu, Apr 06, 2023 at 02:02:55PM +0900, Asahi Lina wrote:
> > > On 05/04/2023 23.44, Daniel Vetter wrote:
> > > > On Tue, Mar 07, 2023 at 11:25:43PM +0900, Asahi Lina wrote:
> > > > > +/// Look up a GEM object handle for a `File` and return an `ObjectRef` for it.
> > > > > +pub(crate) fn lookup_handle(file: &DrmFile, handle: u32) -> Result<ObjectRef> {
> > > > > + Ok(ObjectRef::new(shmem::Object::lookup_handle(file, handle)?))
> > > > > +}
> > > >
> > > > So maybe my expectations for rust typing is a bit too much, but I kinda
> > > > expected this to be fully generic:
> > > >
> > > > - trait Driver (drm_driver) knows the driver's object type
> > > > - a generic create_handle function could ensure that for drm_file (which
> > > > is always for a specific drm_device and hence Driver) can ensure at the
> > > > type level that you only put the right objects into the drm_file
> > > > - a generic lookup_handle function on the drm_file knows the Driver trait
> > > > and so can give you back the right type right away.
> > > >
> > > > Why the wrapping, what do I miss?
> > >
> > > Sigh, so this is one of the many ways I'm trying to work around the "Rust
> > > doesn't do subclasses" problem (so we can figure out what the best one is
> > > ^^).
> > >
> > > The generic shmem::Object::lookup_handle() call *is* fully generic and will
> > > get you back a driver-specific object. But since Rust doesn't do
> > > subclassing, what you get back isn't a driver-specific type T, but rather a
> > > (reference to a) shmem::Object<T>. T represents the inner driver-specific
> > > data/functionality (only), and the outer shmem::Object<T> includes the
> > > actual drm_gem_shmem_object plus a T. This is backwards from C, where you
> > > expect the opposite situation where T contains a shmem object, but that just
> > > doesn't work with Rust because there's no way to build a safe API around
> > > that model as far as I know.
> >
> > Ah I think I just got confused. I did untangle (I think at least) the
> > Object<T> trick, I guess the only thing that confused me here is why this
> > is in the shmem module? Or is that the rust problem again?
> >
> > I'd kinda have expected that we'd have a gem::Object<T> here that the
> > lookup_handle function returns. So for the shmem case I guess that would
> > then be gem::Object<shmem::Object<T>> for the driver type T with driver
> > specific stuff? I guess not very pretty ...
>
> Ahh, uh... Yeah, so shmem objects are allocated their own way (the shmem
> core expects to kfree them in drm_gem_shmem_free) and
> bindings::drm_gem_shmem_object already contains a bindings::drm_gem_object.
> Since the composition is already done in the C side, we can't just do it
> again in Rust cleanly. That's why I have this weird setup with both a common
> trait for common GEM functionality and separate actual types that both
> implement it.
Hm this is annoying. For a single driver it doesn't matter, but I do
expect that once we have more, and especially once we have more libraries
wrapped (ttm, gpuva, execbuf submit helpers, ...) then the common glue
really becomes the gem_bo for many of these things.
Could we have a GemObject trait which covers this? sole function is an
unsafe one that gives you the raw C pointer :-) It still means that every
gem memory manager library needs to impl that trait, but all the
manager-agnostic bits in the wrappers would be generic? trait would then
also have the right dependent type to ensure type safety in all this.
Maybe something to discuss in the next meeting with the rust folks.
> Honestly the whole GEM codepath is untested other than the bits inherited by
> shmem. I'm not sure I'll be able to verify that this all makes sense until
> another Rust driver comes along that needs something other than shmem. I
> just felt I had to do *something* for GEM since the hierarchy is there and I
> needed shmem...
>
> This whole gem stuff is IMO the messiest part of the abstractions though, so
> I'm happy to turn it on its head if it makes it better and someone has an
> idea of how to do that ^^
Yeah I still haven't worked up enough courage to type up my gem
abstraction review :-/
> > > Now the problem is from the higher layers I want object operations that
> > > interact with the shmem::Object<T> (that is, they call generic GEM functions
> > > on the object). Options so far:
> > >
> > > 1. Add an outer wrapper and put that functionality there.
> > > 2. Just have the functions on T as helpers, so you need to call T::foo(obj)
> > > instead of obj.foo().
> > > 3. Use the undocumented method receiver trait thing to make shmem::Object<T>
> > > a valid `self` type, plus add auto-Deref to shmem::Object. Then obj.foo()
> > > works.
> > >
> > > #1 is what I use here. #2 is how the driver-specific File ioctl callbacks
> > > are implemented, and also sched::Job<T>. #3 is used for fence callbacks
> > > (FenceObject<T>). None of them are great, and I'd love to hear what people
> > > think of the various options...
> > >
> > > There are other unexplored options, like in this GEM case it could be
> > > covered with a driver-internal auxiliary trait impl'd on shmem::Object<T>
> > > buuut that doesn't work when you actually need callbacks on T itself to
> > > circle back to shmem::Object<T>, as is the case with File/Job/FenceObject.
> >
> > Ok I think I'm completely lost here. But I also havent' looked at how this
> > is all really used in the driver, it's really just the shmem:: module in
> > the lookup_handle function which looked strange to me.
>
> Ah, sorry, I misunderstood what you were talking about in my previous email
> then. That's just a default trait function. It comes from common
> functionality in the gem module, but shmem::Object implements the trait so
> it ends up offering it too (lookup_handle() is not duplicated, it only lives
> in gem, shmem only has to implement going to/from the drm_gem_object pointer
> so the rest of the methods can use it). That's part of why the type/trait
> hierarchy is kind of messy here, it's so I can share functionality between
> both types even though they are pre-composed on the C side.
Ok, so it's all already what I expect and I'm just confused with rust
syntax.
> In the end the object types are specialized for any given driver, so you're
> always getting your own unique kind of object anyway. It's just that drivers
> based on shmem will go through it to reach the common code and work with a
> shmem::Object<T>, and drivers using raw gem will use gem::Object<T> instead.
Ok, sounds all good.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
^ permalink raw reply [flat|nested] 122+ messages in thread
[parent not found: <ZC2HtBOaoUAzVCVH@phenom.ffwll.local>]
* Re: [PATCH RFC 18/18] drm/asahi: Add the Asahi driver for Apple AGX GPUs
[not found] ` <ZC2HtBOaoUAzVCVH@phenom.ffwll.local>
@ 2023-04-06 4:44 ` Asahi Lina
2023-04-06 5:09 ` Asahi Lina
` (2 more replies)
0 siblings, 3 replies; 122+ messages in thread
From: Asahi Lina @ 2023-04-06 4:44 UTC (permalink / raw)
To: David Airlie
Cc: Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
Miguel Ojeda, Alex Gaynor, Wedson Almeida Filho, Boqun Feng,
Gary Guo, Björn Roy Baron, Sumit Semwal,
Christian König, Luben Tuikov, Jarkko Sakkinen, Dave Hansen,
Alyssa Rosenzweig, Karol Herbst, Ella Stanforth, Faith Ekstrand,
Mary, linux-kernel, dri-devel, rust-for-linux, linux-media,
linaro-mm-sig, linux-sgx, asahi
On 05/04/2023 23.37, Daniel Vetter wrote:
> On Tue, Mar 07, 2023 at 11:25:43PM +0900, Asahi Lina wrote:
>> +/// A generic monotonically incrementing ID used to uniquely identify object instances within the
>> +/// driver.
>> +pub(crate) struct ID(AtomicU64);
>> +
>> +impl ID {
>> + /// Create a new ID counter with a given value.
>> + fn new(val: u64) -> ID {
>> + ID(AtomicU64::new(val))
>> + }
>> +
>> + /// Fetch the next unique ID.
>> + pub(crate) fn next(&self) -> u64 {
>> + self.0.fetch_add(1, Ordering::Relaxed)
>> + }
>> +}
>
> Continuing the theme of me commenting on individual things, I stumbled
> over this because I noticed that there's a lot of id based lookups where I
> don't expect them, and started chasing.
>
> - For ids use xarray, not atomic counters. Yes I know dma_fence timelines
> gets this wrong, this goes back to an innocent time where we didn't
> allocate more than one timeline per engine, and no one fixed it since
> then. Yes u64 should be big enough for everyone :-/
>
> - Attaching ID spaces to drm_device is also not great. drm is full of
> these mistakes. Much better if their per drm_file and so private to each
> client.
>
> - They shouldn't be used for anything else than uapi id -> kernel object
> lookup at the beginning of ioctl code, and nowhere else. At least from
> skimming it seems like these are used all over the driver codebase,
> which does freak me out. At least on the C side that's a clear indicator
> for a refcount/lockin/data structure model that's not thought out at
> all.
>
> What's going on here, what do I miss?
These aren't UAPI IDs, they are driver-internal IDs (the UAPI IDs do use
xarray and are per-File). Most of them are just for debugging, so that
when I enable full debug spam I have some way to correlate different
things that are happening together (this subset of interleaved log lines
relate to the same submission). Basically just object names that are
easier to read (and less of a security leak) than pointers and
guaranteed not to repeat. You could get rid of most of them and it
wouldn't affect the driver design, it just makes it very hard to see
what's going on with debug logs ^^;
There are only two that are ever used for non-debugging purposes: the VM
ID, and the File ID. Both are per-device global IDs attached to the VMs
(not the UAPI VM objects, but rather the underlyng MMU address space
managers they represent, including the kernel-internal ones) and to
Files themselves. They are used for destroying GEM objects: since the
objects are also device-global across multiple clients, I need a way to
do things like "clean up all mappings for this File" or "clean up all
mappings for this VM". There's an annoying circular reference between
GEM objects and their mappings, which is why this is explicitly coded
out in destroy paths instead of naturally happening via Drop semantics
(without that cleanup code, the circular reference leaks it).
So e.g. when a File does a GEM close or explicitly asks for all mappings
of an object to be removed, it goes out to the (possibly shared) GEM
object and tells it to drop all mappings marked as owned by that unique
File ID. When an explicit "unmap all in VM" op happens, it asks the GEM
object to drop all mappings for that underlying VM ID. Similarly, when a
UAPI VM object is dropped (in the Drop impl, so both explicitly and when
the whole File/xarray is dropped and such), that does an explicit unmap
of a special dummy object it owns which would otherwise leak since it is
not tracked as a GEM object owned by that File and therefore not handled
by GEM closing. And again along the same lines, the allocators in
alloc.rs explicitly destroy the mappings for their backing GEM objects
on Drop. All this is due to that annoying circular reference between VMs
and GEM objects that I'm not sure how to fix.
Note that if I *don't* do this (or forget to do it somewhere) the
consequence is just that we leak memory, and if you try to destroy the
wrong IDs somehow the worst that can happen is you unmap things you
shouldn't and fault the GPU (or, in the kernel or kernel-managed user VM
cases, potentially the firmware). Rust safety guarantees still keep
things from going entirely off the rails within the kernel, since
everything that matters is reference counted (which is why these
reference cycles are possible at all).
This all started when I was looking at the panfrost driver for
reference. It does the same thing except it uses actual pointers to the
owning entities instead of IDs, and pointer comparison (see
panfrost_gem_close). Of course you could try do that in Rust too
(literally storing and comparing raw pointers that aren't owned
references), but then you're introducing a Pin<> requirement on those
objects to make their addresses stable and it feels way more icky and
error-prone than unique IDs (since addresses can be reused). panfrost
only has a single mmu (what I call the raw VM) per File while I have an
arbitrary number, which is why I end up with the extra
distinction/complexity of both File and VM IDs, but the concept is the same.
Some of this is going to be refactored when I implement arbitrary VM
range mapping/unmapping, which would be a good time to improve this...
but is there something particularly wrong/broken about the way I'm doing
it now that I missed? I figured unique u64 IDs would be a pretty safe
way to identify entities and cleanup the mappings when needed.
~~ Lina
^ permalink raw reply [flat|nested] 122+ messages in thread* Re: [PATCH RFC 18/18] drm/asahi: Add the Asahi driver for Apple AGX GPUs
2023-04-06 4:44 ` Asahi Lina
@ 2023-04-06 5:09 ` Asahi Lina
2023-04-06 11:26 ` Daniel Vetter
2023-04-06 10:42 ` [Linaro-mm-sig] " Daniel Vetter
2023-04-06 11:55 ` Daniel Vetter
2 siblings, 1 reply; 122+ messages in thread
From: Asahi Lina @ 2023-04-06 5:09 UTC (permalink / raw)
To: Daniel Vetter
Cc: Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
Miguel Ojeda, Alex Gaynor, Wedson Almeida Filho, Boqun Feng,
Gary Guo, Björn Roy Baron, Sumit Semwal,
Christian König, Luben Tuikov, Jarkko Sakkinen, Dave Hansen,
Alyssa Rosenzweig, Karol Herbst, Ella Stanforth, Faith Ekstrand,
Mary, linux-kernel, dri-devel, rust-for-linux, linux-media,
linaro-mm-sig, linux-sgx, asahi, David Airlie
Argh. This (and my other reply) was supposed to go to Daniel, but
Thunderbird... just dropped that recipient? And then my silly brain saw
all the Cc:s go to To: and figured it was some weird consolidation and
so I moved everything to Cc: except the only name that started with "Da"
and... yeah, that wasn't the same person.
Sorry for the confusion... I have no idea why Thunderbird hates Daniel...
On 06/04/2023 13.44, Asahi Lina wrote:
> On 05/04/2023 23.37, Daniel Vetter wrote:
>> On Tue, Mar 07, 2023 at 11:25:43PM +0900, Asahi Lina wrote:
>>> +/// A generic monotonically incrementing ID used to uniquely identify object instances within the
>>> +/// driver.
>>> +pub(crate) struct ID(AtomicU64);
>>> +
>>> +impl ID {
>>> + /// Create a new ID counter with a given value.
>>> + fn new(val: u64) -> ID {
>>> + ID(AtomicU64::new(val))
>>> + }
>>> +
>>> + /// Fetch the next unique ID.
>>> + pub(crate) fn next(&self) -> u64 {
>>> + self.0.fetch_add(1, Ordering::Relaxed)
>>> + }
>>> +}
>>
>> Continuing the theme of me commenting on individual things, I stumbled
>> over this because I noticed that there's a lot of id based lookups where I
>> don't expect them, and started chasing.
>>
>> - For ids use xarray, not atomic counters. Yes I know dma_fence timelines
>> gets this wrong, this goes back to an innocent time where we didn't
>> allocate more than one timeline per engine, and no one fixed it since
>> then. Yes u64 should be big enough for everyone :-/
>>
>> - Attaching ID spaces to drm_device is also not great. drm is full of
>> these mistakes. Much better if their per drm_file and so private to each
>> client.
>>
>> - They shouldn't be used for anything else than uapi id -> kernel object
>> lookup at the beginning of ioctl code, and nowhere else. At least from
>> skimming it seems like these are used all over the driver codebase,
>> which does freak me out. At least on the C side that's a clear indicator
>> for a refcount/lockin/data structure model that's not thought out at
>> all.
>>
>> What's going on here, what do I miss?
>
> These aren't UAPI IDs, they are driver-internal IDs (the UAPI IDs do use
> xarray and are per-File). Most of them are just for debugging, so that
> when I enable full debug spam I have some way to correlate different
> things that are happening together (this subset of interleaved log lines
> relate to the same submission). Basically just object names that are
> easier to read (and less of a security leak) than pointers and
> guaranteed not to repeat. You could get rid of most of them and it
> wouldn't affect the driver design, it just makes it very hard to see
> what's going on with debug logs ^^;
>
> There are only two that are ever used for non-debugging purposes: the VM
> ID, and the File ID. Both are per-device global IDs attached to the VMs
> (not the UAPI VM objects, but rather the underlyng MMU address space
> managers they represent, including the kernel-internal ones) and to
> Files themselves. They are used for destroying GEM objects: since the
> objects are also device-global across multiple clients, I need a way to
> do things like "clean up all mappings for this File" or "clean up all
> mappings for this VM". There's an annoying circular reference between
> GEM objects and their mappings, which is why this is explicitly coded
> out in destroy paths instead of naturally happening via Drop semantics
> (without that cleanup code, the circular reference leaks it).
>
> So e.g. when a File does a GEM close or explicitly asks for all mappings
> of an object to be removed, it goes out to the (possibly shared) GEM
> object and tells it to drop all mappings marked as owned by that unique
> File ID. When an explicit "unmap all in VM" op happens, it asks the GEM
> object to drop all mappings for that underlying VM ID. Similarly, when a
> UAPI VM object is dropped (in the Drop impl, so both explicitly and when
> the whole File/xarray is dropped and such), that does an explicit unmap
> of a special dummy object it owns which would otherwise leak since it is
> not tracked as a GEM object owned by that File and therefore not handled
> by GEM closing. And again along the same lines, the allocators in
> alloc.rs explicitly destroy the mappings for their backing GEM objects
> on Drop. All this is due to that annoying circular reference between VMs
> and GEM objects that I'm not sure how to fix.
>
> Note that if I *don't* do this (or forget to do it somewhere) the
> consequence is just that we leak memory, and if you try to destroy the
> wrong IDs somehow the worst that can happen is you unmap things you
> shouldn't and fault the GPU (or, in the kernel or kernel-managed user VM
> cases, potentially the firmware). Rust safety guarantees still keep
> things from going entirely off the rails within the kernel, since
> everything that matters is reference counted (which is why these
> reference cycles are possible at all).
>
> This all started when I was looking at the panfrost driver for
> reference. It does the same thing except it uses actual pointers to the
> owning entities instead of IDs, and pointer comparison (see
> panfrost_gem_close). Of course you could try do that in Rust too
> (literally storing and comparing raw pointers that aren't owned
> references), but then you're introducing a Pin<> requirement on those
> objects to make their addresses stable and it feels way more icky and
> error-prone than unique IDs (since addresses can be reused). panfrost
> only has a single mmu (what I call the raw VM) per File while I have an
> arbitrary number, which is why I end up with the extra
> distinction/complexity of both File and VM IDs, but the concept is the same.
>
> Some of this is going to be refactored when I implement arbitrary VM
> range mapping/unmapping, which would be a good time to improve this...
> but is there something particularly wrong/broken about the way I'm doing
> it now that I missed? I figured unique u64 IDs would be a pretty safe
> way to identify entities and cleanup the mappings when needed.
>
> ~~ Lina
>
~~ Lina
^ permalink raw reply [flat|nested] 122+ messages in thread* Re: [PATCH RFC 18/18] drm/asahi: Add the Asahi driver for Apple AGX GPUs
2023-04-06 5:09 ` Asahi Lina
@ 2023-04-06 11:26 ` Daniel Vetter
0 siblings, 0 replies; 122+ messages in thread
From: Daniel Vetter @ 2023-04-06 11:26 UTC (permalink / raw)
To: Asahi Lina
Cc: Daniel Vetter, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, Miguel Ojeda, Alex Gaynor,
Wedson Almeida Filho, Boqun Feng, Gary Guo, Björn Roy Baron,
Sumit Semwal, Christian König, Luben Tuikov,
Jarkko Sakkinen, Dave Hansen, Alyssa Rosenzweig, Karol Herbst,
Ella Stanforth, Faith Ekstrand, Mary, linux-kernel, dri-devel,
rust-for-linux, linux-media, linaro-mm-sig, linux-sgx, asahi,
David Airlie
On Thu, Apr 06, 2023 at 02:09:21PM +0900, Asahi Lina wrote:
> Argh. This (and my other reply) was supposed to go to Daniel, but
> Thunderbird... just dropped that recipient? And then my silly brain saw all
> the Cc:s go to To: and figured it was some weird consolidation and so I
> moved everything to Cc: except the only name that started with "Da" and...
> yeah, that wasn't the same person.
>
> Sorry for the confusion... I have no idea why Thunderbird hates Daniel...
Don't worry, I get cc'ed on so much stuff that whether I'm cc'ed or not
has zero impact on whether I'll read a mail or not. It just kinda
disappears into the big lable:cc bucket ...
-Daniel
>
> On 06/04/2023 13.44, Asahi Lina wrote:
> > On 05/04/2023 23.37, Daniel Vetter wrote:
> > > On Tue, Mar 07, 2023 at 11:25:43PM +0900, Asahi Lina wrote:
> > > > +/// A generic monotonically incrementing ID used to uniquely identify object instances within the
> > > > +/// driver.
> > > > +pub(crate) struct ID(AtomicU64);
> > > > +
> > > > +impl ID {
> > > > + /// Create a new ID counter with a given value.
> > > > + fn new(val: u64) -> ID {
> > > > + ID(AtomicU64::new(val))
> > > > + }
> > > > +
> > > > + /// Fetch the next unique ID.
> > > > + pub(crate) fn next(&self) -> u64 {
> > > > + self.0.fetch_add(1, Ordering::Relaxed)
> > > > + }
> > > > +}
> > >
> > > Continuing the theme of me commenting on individual things, I stumbled
> > > over this because I noticed that there's a lot of id based lookups where I
> > > don't expect them, and started chasing.
> > >
> > > - For ids use xarray, not atomic counters. Yes I know dma_fence timelines
> > > gets this wrong, this goes back to an innocent time where we didn't
> > > allocate more than one timeline per engine, and no one fixed it since
> > > then. Yes u64 should be big enough for everyone :-/
> > >
> > > - Attaching ID spaces to drm_device is also not great. drm is full of
> > > these mistakes. Much better if their per drm_file and so private to each
> > > client.
> > >
> > > - They shouldn't be used for anything else than uapi id -> kernel object
> > > lookup at the beginning of ioctl code, and nowhere else. At least from
> > > skimming it seems like these are used all over the driver codebase,
> > > which does freak me out. At least on the C side that's a clear indicator
> > > for a refcount/lockin/data structure model that's not thought out at
> > > all.
> > >
> > > What's going on here, what do I miss?
> >
> > These aren't UAPI IDs, they are driver-internal IDs (the UAPI IDs do use
> > xarray and are per-File). Most of them are just for debugging, so that
> > when I enable full debug spam I have some way to correlate different
> > things that are happening together (this subset of interleaved log lines
> > relate to the same submission). Basically just object names that are
> > easier to read (and less of a security leak) than pointers and
> > guaranteed not to repeat. You could get rid of most of them and it
> > wouldn't affect the driver design, it just makes it very hard to see
> > what's going on with debug logs ^^;
> >
> > There are only two that are ever used for non-debugging purposes: the VM
> > ID, and the File ID. Both are per-device global IDs attached to the VMs
> > (not the UAPI VM objects, but rather the underlyng MMU address space
> > managers they represent, including the kernel-internal ones) and to
> > Files themselves. They are used for destroying GEM objects: since the
> > objects are also device-global across multiple clients, I need a way to
> > do things like "clean up all mappings for this File" or "clean up all
> > mappings for this VM". There's an annoying circular reference between
> > GEM objects and their mappings, which is why this is explicitly coded
> > out in destroy paths instead of naturally happening via Drop semantics
> > (without that cleanup code, the circular reference leaks it).
> >
> > So e.g. when a File does a GEM close or explicitly asks for all mappings
> > of an object to be removed, it goes out to the (possibly shared) GEM
> > object and tells it to drop all mappings marked as owned by that unique
> > File ID. When an explicit "unmap all in VM" op happens, it asks the GEM
> > object to drop all mappings for that underlying VM ID. Similarly, when a
> > UAPI VM object is dropped (in the Drop impl, so both explicitly and when
> > the whole File/xarray is dropped and such), that does an explicit unmap
> > of a special dummy object it owns which would otherwise leak since it is
> > not tracked as a GEM object owned by that File and therefore not handled
> > by GEM closing. And again along the same lines, the allocators in
> > alloc.rs explicitly destroy the mappings for their backing GEM objects
> > on Drop. All this is due to that annoying circular reference between VMs
> > and GEM objects that I'm not sure how to fix.
> >
> > Note that if I *don't* do this (or forget to do it somewhere) the
> > consequence is just that we leak memory, and if you try to destroy the
> > wrong IDs somehow the worst that can happen is you unmap things you
> > shouldn't and fault the GPU (or, in the kernel or kernel-managed user VM
> > cases, potentially the firmware). Rust safety guarantees still keep
> > things from going entirely off the rails within the kernel, since
> > everything that matters is reference counted (which is why these
> > reference cycles are possible at all).
> >
> > This all started when I was looking at the panfrost driver for
> > reference. It does the same thing except it uses actual pointers to the
> > owning entities instead of IDs, and pointer comparison (see
> > panfrost_gem_close). Of course you could try do that in Rust too
> > (literally storing and comparing raw pointers that aren't owned
> > references), but then you're introducing a Pin<> requirement on those
> > objects to make their addresses stable and it feels way more icky and
> > error-prone than unique IDs (since addresses can be reused). panfrost
> > only has a single mmu (what I call the raw VM) per File while I have an
> > arbitrary number, which is why I end up with the extra
> > distinction/complexity of both File and VM IDs, but the concept is the same.
> >
> > Some of this is going to be refactored when I implement arbitrary VM
> > range mapping/unmapping, which would be a good time to improve this...
> > but is there something particularly wrong/broken about the way I'm doing
> > it now that I missed? I figured unique u64 IDs would be a pretty safe
> > way to identify entities and cleanup the mappings when needed.
> >
> > ~~ Lina
> >
>
> ~~ Lina
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
^ permalink raw reply [flat|nested] 122+ messages in thread
* Re: [Linaro-mm-sig] Re: [PATCH RFC 18/18] drm/asahi: Add the Asahi driver for Apple AGX GPUs
2023-04-06 4:44 ` Asahi Lina
2023-04-06 5:09 ` Asahi Lina
@ 2023-04-06 10:42 ` Daniel Vetter
2023-04-06 11:55 ` Daniel Vetter
2 siblings, 0 replies; 122+ messages in thread
From: Daniel Vetter @ 2023-04-06 10:42 UTC (permalink / raw)
To: Asahi Lina
Cc: David Airlie, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, Miguel Ojeda, Alex Gaynor,
Wedson Almeida Filho, Boqun Feng, Gary Guo, Björn Roy Baron,
Sumit Semwal, Christian König, Luben Tuikov,
Jarkko Sakkinen, Dave Hansen, Alyssa Rosenzweig, Karol Herbst,
Ella Stanforth, Faith Ekstrand, Mary, linux-kernel, dri-devel,
rust-for-linux, linux-media, linaro-mm-sig, linux-sgx, asahi
On Thu, Apr 06, 2023 at 01:44:22PM +0900, Asahi Lina wrote:
> On 05/04/2023 23.37, Daniel Vetter wrote:
> > On Tue, Mar 07, 2023 at 11:25:43PM +0900, Asahi Lina wrote:
> > > +/// A generic monotonically incrementing ID used to uniquely identify object instances within the
> > > +/// driver.
> > > +pub(crate) struct ID(AtomicU64);
> > > +
> > > +impl ID {
> > > + /// Create a new ID counter with a given value.
> > > + fn new(val: u64) -> ID {
> > > + ID(AtomicU64::new(val))
> > > + }
> > > +
> > > + /// Fetch the next unique ID.
> > > + pub(crate) fn next(&self) -> u64 {
> > > + self.0.fetch_add(1, Ordering::Relaxed)
> > > + }
> > > +}
> >
> > Continuing the theme of me commenting on individual things, I stumbled
> > over this because I noticed that there's a lot of id based lookups where I
> > don't expect them, and started chasing.
> >
> > - For ids use xarray, not atomic counters. Yes I know dma_fence timelines
> > gets this wrong, this goes back to an innocent time where we didn't
> > allocate more than one timeline per engine, and no one fixed it since
> > then. Yes u64 should be big enough for everyone :-/
> >
> > - Attaching ID spaces to drm_device is also not great. drm is full of
> > these mistakes. Much better if their per drm_file and so private to each
> > client.
> >
> > - They shouldn't be used for anything else than uapi id -> kernel object
> > lookup at the beginning of ioctl code, and nowhere else. At least from
> > skimming it seems like these are used all over the driver codebase,
> > which does freak me out. At least on the C side that's a clear indicator
> > for a refcount/lockin/data structure model that's not thought out at
> > all.
> >
> > What's going on here, what do I miss?
>
> These aren't UAPI IDs, they are driver-internal IDs (the UAPI IDs do use
> xarray and are per-File). Most of them are just for debugging, so that when
> I enable full debug spam I have some way to correlate different things that
> are happening together (this subset of interleaved log lines relate to the
> same submission). Basically just object names that are easier to read (and
> less of a security leak) than pointers and guaranteed not to repeat. You
> could get rid of most of them and it wouldn't affect the driver design, it
> just makes it very hard to see what's going on with debug logs ^^;
Hm generally we just print the kernel addresses with the right printk
modifiers. Those filter/hash addresses if you have the right paranoia
settings enabled. I guess throwing in a debug id doesn't hurt, but would
be good to make that a lot more clearer.
I haven't read the full driver yet because I'm still too much lost, that's
why I guess I missed the xarray stuff on the file. I'll try and go
understand that.
For the big topic below I need to think more.
-Daniel
> There are only two that are ever used for non-debugging purposes: the VM ID,
> and the File ID. Both are per-device global IDs attached to the VMs (not the
> UAPI VM objects, but rather the underlyng MMU address space managers they
> represent, including the kernel-internal ones) and to Files themselves. They
> are used for destroying GEM objects: since the objects are also
> device-global across multiple clients, I need a way to do things like "clean
> up all mappings for this File" or "clean up all mappings for this VM".
> There's an annoying circular reference between GEM objects and their
> mappings, which is why this is explicitly coded out in destroy paths instead
> of naturally happening via Drop semantics (without that cleanup code, the
> circular reference leaks it).
>
> So e.g. when a File does a GEM close or explicitly asks for all mappings of
> an object to be removed, it goes out to the (possibly shared) GEM object and
> tells it to drop all mappings marked as owned by that unique File ID. When
> an explicit "unmap all in VM" op happens, it asks the GEM object to drop all
> mappings for that underlying VM ID. Similarly, when a UAPI VM object is
> dropped (in the Drop impl, so both explicitly and when the whole File/xarray
> is dropped and such), that does an explicit unmap of a special dummy object
> it owns which would otherwise leak since it is not tracked as a GEM object
> owned by that File and therefore not handled by GEM closing. And again along
> the same lines, the allocators in alloc.rs explicitly destroy the mappings
> for their backing GEM objects on Drop. All this is due to that annoying
> circular reference between VMs and GEM objects that I'm not sure how to fix.
>
> Note that if I *don't* do this (or forget to do it somewhere) the
> consequence is just that we leak memory, and if you try to destroy the wrong
> IDs somehow the worst that can happen is you unmap things you shouldn't and
> fault the GPU (or, in the kernel or kernel-managed user VM cases,
> potentially the firmware). Rust safety guarantees still keep things from
> going entirely off the rails within the kernel, since everything that
> matters is reference counted (which is why these reference cycles are
> possible at all).
>
> This all started when I was looking at the panfrost driver for reference. It
> does the same thing except it uses actual pointers to the owning entities
> instead of IDs, and pointer comparison (see panfrost_gem_close). Of course
> you could try do that in Rust too (literally storing and comparing raw
> pointers that aren't owned references), but then you're introducing a Pin<>
> requirement on those objects to make their addresses stable and it feels way
> more icky and error-prone than unique IDs (since addresses can be reused).
> panfrost only has a single mmu (what I call the raw VM) per File while I
> have an arbitrary number, which is why I end up with the extra
> distinction/complexity of both File and VM IDs, but the concept is the same.
>
> Some of this is going to be refactored when I implement arbitrary VM range
> mapping/unmapping, which would be a good time to improve this... but is
> there something particularly wrong/broken about the way I'm doing it now
> that I missed? I figured unique u64 IDs would be a pretty safe way to
> identify entities and cleanup the mappings when needed.
>
> ~~ Lina
>
> _______________________________________________
> Linaro-mm-sig mailing list -- linaro-mm-sig@lists.linaro.org
> To unsubscribe send an email to linaro-mm-sig-leave@lists.linaro.org
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
^ permalink raw reply [flat|nested] 122+ messages in thread* Re: [Linaro-mm-sig] Re: [PATCH RFC 18/18] drm/asahi: Add the Asahi driver for Apple AGX GPUs
2023-04-06 4:44 ` Asahi Lina
2023-04-06 5:09 ` Asahi Lina
2023-04-06 10:42 ` [Linaro-mm-sig] " Daniel Vetter
@ 2023-04-06 11:55 ` Daniel Vetter
2023-04-06 13:15 ` Asahi Lina
2 siblings, 1 reply; 122+ messages in thread
From: Daniel Vetter @ 2023-04-06 11:55 UTC (permalink / raw)
To: Asahi Lina
Cc: David Airlie, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, Miguel Ojeda, Alex Gaynor,
Wedson Almeida Filho, Boqun Feng, Gary Guo, Björn Roy Baron,
Sumit Semwal, Christian König, Luben Tuikov,
Jarkko Sakkinen, Dave Hansen, Alyssa Rosenzweig, Karol Herbst,
Ella Stanforth, Faith Ekstrand, Mary, linux-kernel, dri-devel,
rust-for-linux, linux-media, linaro-mm-sig, linux-sgx, asahi
On Thu, Apr 06, 2023 at 01:44:22PM +0900, Asahi Lina wrote:
> On 05/04/2023 23.37, Daniel Vetter wrote:
> > On Tue, Mar 07, 2023 at 11:25:43PM +0900, Asahi Lina wrote:
> > > +/// A generic monotonically incrementing ID used to uniquely identify object instances within the
> > > +/// driver.
> > > +pub(crate) struct ID(AtomicU64);
> > > +
> > > +impl ID {
> > > + /// Create a new ID counter with a given value.
> > > + fn new(val: u64) -> ID {
> > > + ID(AtomicU64::new(val))
> > > + }
> > > +
> > > + /// Fetch the next unique ID.
> > > + pub(crate) fn next(&self) -> u64 {
> > > + self.0.fetch_add(1, Ordering::Relaxed)
> > > + }
> > > +}
> >
> > Continuing the theme of me commenting on individual things, I stumbled
> > over this because I noticed that there's a lot of id based lookups where I
> > don't expect them, and started chasing.
> >
> > - For ids use xarray, not atomic counters. Yes I know dma_fence timelines
> > gets this wrong, this goes back to an innocent time where we didn't
> > allocate more than one timeline per engine, and no one fixed it since
> > then. Yes u64 should be big enough for everyone :-/
> >
> > - Attaching ID spaces to drm_device is also not great. drm is full of
> > these mistakes. Much better if their per drm_file and so private to each
> > client.
> >
> > - They shouldn't be used for anything else than uapi id -> kernel object
> > lookup at the beginning of ioctl code, and nowhere else. At least from
> > skimming it seems like these are used all over the driver codebase,
> > which does freak me out. At least on the C side that's a clear indicator
> > for a refcount/lockin/data structure model that's not thought out at
> > all.
> >
> > What's going on here, what do I miss?
>
> These aren't UAPI IDs, they are driver-internal IDs (the UAPI IDs do use
> xarray and are per-File). Most of them are just for debugging, so that when
> I enable full debug spam I have some way to correlate different things that
> are happening together (this subset of interleaved log lines relate to the
> same submission). Basically just object names that are easier to read (and
> less of a security leak) than pointers and guaranteed not to repeat. You
> could get rid of most of them and it wouldn't affect the driver design, it
> just makes it very hard to see what's going on with debug logs ^^;
>
> There are only two that are ever used for non-debugging purposes: the VM ID,
> and the File ID. Both are per-device global IDs attached to the VMs (not the
> UAPI VM objects, but rather the underlyng MMU address space managers they
> represent, including the kernel-internal ones) and to Files themselves. They
> are used for destroying GEM objects: since the objects are also
> device-global across multiple clients, I need a way to do things like "clean
> up all mappings for this File" or "clean up all mappings for this VM".
> There's an annoying circular reference between GEM objects and their
> mappings, which is why this is explicitly coded out in destroy paths instead
> of naturally happening via Drop semantics (without that cleanup code, the
> circular reference leaks it).
>
> So e.g. when a File does a GEM close or explicitly asks for all mappings of
> an object to be removed, it goes out to the (possibly shared) GEM object and
> tells it to drop all mappings marked as owned by that unique File ID. When
> an explicit "unmap all in VM" op happens, it asks the GEM object to drop all
> mappings for that underlying VM ID. Similarly, when a UAPI VM object is
> dropped (in the Drop impl, so both explicitly and when the whole File/xarray
> is dropped and such), that does an explicit unmap of a special dummy object
> it owns which would otherwise leak since it is not tracked as a GEM object
> owned by that File and therefore not handled by GEM closing. And again along
> the same lines, the allocators in alloc.rs explicitly destroy the mappings
> for their backing GEM objects on Drop. All this is due to that annoying
> circular reference between VMs and GEM objects that I'm not sure how to fix.
>
> Note that if I *don't* do this (or forget to do it somewhere) the
> consequence is just that we leak memory, and if you try to destroy the wrong
> IDs somehow the worst that can happen is you unmap things you shouldn't and
> fault the GPU (or, in the kernel or kernel-managed user VM cases,
> potentially the firmware). Rust safety guarantees still keep things from
> going entirely off the rails within the kernel, since everything that
> matters is reference counted (which is why these reference cycles are
> possible at all).
>
> This all started when I was looking at the panfrost driver for reference. It
> does the same thing except it uses actual pointers to the owning entities
> instead of IDs, and pointer comparison (see panfrost_gem_close). Of course
> you could try do that in Rust too (literally storing and comparing raw
> pointers that aren't owned references), but then you're introducing a Pin<>
> requirement on those objects to make their addresses stable and it feels way
> more icky and error-prone than unique IDs (since addresses can be reused).
> panfrost only has a single mmu (what I call the raw VM) per File while I
> have an arbitrary number, which is why I end up with the extra
> distinction/complexity of both File and VM IDs, but the concept is the same.
>
> Some of this is going to be refactored when I implement arbitrary VM range
> mapping/unmapping, which would be a good time to improve this... but is
> there something particularly wrong/broken about the way I'm doing it now
> that I missed? I figured unique u64 IDs would be a pretty safe way to
> identify entities and cleanup the mappings when needed.
Ok, some attempt at going through the vm_id/file_id stuff. Extremely
high-level purely informed by having read too many drivers:
First on the drm_file/struct file/file_id. This is the uapi interface
object, and it's refcounted in the vfs, but that's entirely the vfs'
business and none of the driver (or even subsystem). Once userspace has
done the final close() the file is gone, there's no way to ever get
anything meaningfully out of it because userspace dropped it. So if the
driver has any kind of backpointer to that's a design bug, because in all
the place you might want to care (ioctl, fdinfo for schedu stats, any
other file_operations callback) the vfs ensures it stays alive during the
callback and you essentially have a borrowed reference.
I've seen a lot of drivers try to make clever backpointings to stuff
that's essentially tied to the drm_file, and I've not found a single case
that made sense. iow, file_id as a lookup thingie needs to go. In
principle it's the same argument I've made already for the syncobj rust
wrappers. For specific uses I guess I need some rust reading help, but
from your description it sounds like the vm_id is much more the core
piece.
So for that we have the gpu ctx -> vm -> gem_bos chain of reference. Now
on the C side if you have a modern driver that uses the
vm_bind/unbind/gpuva manager approach, the reference counts go in that
single direction only, anything else is essentially borrowed references
under protection of a mutex/lock or similar thing (for e.g. going from the
bo to the vm for eviction).
In addition to the above chain the xarray in the drm_file also holds
references to each of these. So far so good, in the drm_file ->postclose
callback you just walk the xarrays and drop all the references, and
everything gets cleaned up, at least in the C world.
Aside: I'm ignoring the entire sched/job/gpu-ctx side because that's a
separate can of worms and big other threads floating around already.
But if either due to the uabi being a bit more legacy, or Rust requiring
that the backpointers are reference-counted from the gem_bo->vma->vm and
can't follow borrow semantics (afaiui the usual linux list_head pattern of
walking the list under a lock giving you a borrowed reference for each
element doesn't work too well in rust?) then that's not a problem, you can
still all clean it out:
- The key bit is that your vm struct needs both a refcount like kref and
a separate open count. Each gpu ctx and the xarray for vm objects in
drm_file hold _both_ the kref and the open refcount (in rust the open
refcount implies the Arc or things go sideways).
- the other key bit is that drm_file ->postclose does _not_ have simple
Drop semantics, it's more explicit.
- in the drm_file lastclose you first walk all the gpu ctx. The simplest
semantics is that close() synchronously tears down all leftover gpu ctx,
i.e. you unload them from the gpu. Details are under a lot of discussion
in the various scheduler threads, but essentially this should ensure
that the gpu ctx destruction completely removes all references to the
ctx. If instead you have the legacy problem of apps expecting that
rendering continues even if they called exit() before it finishes, then
it gets more messy. I have no idea whether that's still a problem for
new drivers or can be avoided.
- Next up you do the same thing for the vm xarray (which drops both the
kref an open refcounts).
- At this point there might still be a ton of vm objects around with
elevated kref. Except not, because at this point the open refcount of
each vm should have dropped to zero. When that happens the vm object
itself is still alive, plus even better for rust, you are in the
vm_close(vm) function call so you have a full borrowed reference to
that. Which means you can walk the entire address space and unmap
everything explicit. Which should get rid of any gem_bo->vma->vm
backpointers you have lying around.
- At that point all your vm objects are gone too, because the kref managed
backpointers are gone.
- You walk the xarray of gem_bo (well the drm subsystem does that for
you), which cleans out the reamining references to gem_bo. Only the
gem_bo which are shared with other process or have a dma_buf will
survive, like they should.
No leak, no funky driver-internal vm_id based lookup, and with rust we
should even be able to guarantee you never mix up Arc<Vm> with OpenRef<Vm>
(or however that exactly works in rust types, I have not much real clue).
If you have any other functional needs for vm_id then I guess I need to go
through them, but they should be all fixable.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
^ permalink raw reply [flat|nested] 122+ messages in thread* Re: [Linaro-mm-sig] Re: [PATCH RFC 18/18] drm/asahi: Add the Asahi driver for Apple AGX GPUs
2023-04-06 11:55 ` Daniel Vetter
@ 2023-04-06 13:15 ` Asahi Lina
2023-04-06 13:48 ` Daniel Vetter
0 siblings, 1 reply; 122+ messages in thread
From: Asahi Lina @ 2023-04-06 13:15 UTC (permalink / raw)
To: Daniel Vetter
Cc: David Airlie, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, Miguel Ojeda, Alex Gaynor,
Wedson Almeida Filho, Boqun Feng, Gary Guo, Björn Roy Baron,
Sumit Semwal, Christian König, Luben Tuikov,
Jarkko Sakkinen, Dave Hansen, Alyssa Rosenzweig, Karol Herbst,
Ella Stanforth, Faith Ekstrand, Mary, linux-kernel, dri-devel,
rust-for-linux, linux-media, linaro-mm-sig, linux-sgx, asahi
On 06/04/2023 20.55, Daniel Vetter wrote:
> On Thu, Apr 06, 2023 at 01:44:22PM +0900, Asahi Lina wrote:
>> On 05/04/2023 23.37, Daniel Vetter wrote:
>>> On Tue, Mar 07, 2023 at 11:25:43PM +0900, Asahi Lina wrote:
>>>> +/// A generic monotonically incrementing ID used to uniquely identify object instances within the
>>>> +/// driver.
>>>> +pub(crate) struct ID(AtomicU64);
>>>> +
>>>> +impl ID {
>>>> + /// Create a new ID counter with a given value.
>>>> + fn new(val: u64) -> ID {
>>>> + ID(AtomicU64::new(val))
>>>> + }
>>>> +
>>>> + /// Fetch the next unique ID.
>>>> + pub(crate) fn next(&self) -> u64 {
>>>> + self.0.fetch_add(1, Ordering::Relaxed)
>>>> + }
>>>> +}
>>>
>>> Continuing the theme of me commenting on individual things, I stumbled
>>> over this because I noticed that there's a lot of id based lookups where I
>>> don't expect them, and started chasing.
>>>
>>> - For ids use xarray, not atomic counters. Yes I know dma_fence timelines
>>> gets this wrong, this goes back to an innocent time where we didn't
>>> allocate more than one timeline per engine, and no one fixed it since
>>> then. Yes u64 should be big enough for everyone :-/
>>>
>>> - Attaching ID spaces to drm_device is also not great. drm is full of
>>> these mistakes. Much better if their per drm_file and so private to each
>>> client.
>>>
>>> - They shouldn't be used for anything else than uapi id -> kernel object
>>> lookup at the beginning of ioctl code, and nowhere else. At least from
>>> skimming it seems like these are used all over the driver codebase,
>>> which does freak me out. At least on the C side that's a clear indicator
>>> for a refcount/lockin/data structure model that's not thought out at
>>> all.
>>>
>>> What's going on here, what do I miss?
>>
>> These aren't UAPI IDs, they are driver-internal IDs (the UAPI IDs do use
>> xarray and are per-File). Most of them are just for debugging, so that when
>> I enable full debug spam I have some way to correlate different things that
>> are happening together (this subset of interleaved log lines relate to the
>> same submission). Basically just object names that are easier to read (and
>> less of a security leak) than pointers and guaranteed not to repeat. You
>> could get rid of most of them and it wouldn't affect the driver design, it
>> just makes it very hard to see what's going on with debug logs ^^;
>>
>> There are only two that are ever used for non-debugging purposes: the VM ID,
>> and the File ID. Both are per-device global IDs attached to the VMs (not the
>> UAPI VM objects, but rather the underlyng MMU address space managers they
>> represent, including the kernel-internal ones) and to Files themselves. They
>> are used for destroying GEM objects: since the objects are also
>> device-global across multiple clients, I need a way to do things like "clean
>> up all mappings for this File" or "clean up all mappings for this VM".
>> There's an annoying circular reference between GEM objects and their
>> mappings, which is why this is explicitly coded out in destroy paths instead
>> of naturally happening via Drop semantics (without that cleanup code, the
>> circular reference leaks it).
>>
>> So e.g. when a File does a GEM close or explicitly asks for all mappings of
>> an object to be removed, it goes out to the (possibly shared) GEM object and
>> tells it to drop all mappings marked as owned by that unique File ID. When
>> an explicit "unmap all in VM" op happens, it asks the GEM object to drop all
>> mappings for that underlying VM ID. Similarly, when a UAPI VM object is
>> dropped (in the Drop impl, so both explicitly and when the whole File/xarray
>> is dropped and such), that does an explicit unmap of a special dummy object
>> it owns which would otherwise leak since it is not tracked as a GEM object
>> owned by that File and therefore not handled by GEM closing. And again along
>> the same lines, the allocators in alloc.rs explicitly destroy the mappings
>> for their backing GEM objects on Drop. All this is due to that annoying
>> circular reference between VMs and GEM objects that I'm not sure how to fix.
>>
>> Note that if I *don't* do this (or forget to do it somewhere) the
>> consequence is just that we leak memory, and if you try to destroy the wrong
>> IDs somehow the worst that can happen is you unmap things you shouldn't and
>> fault the GPU (or, in the kernel or kernel-managed user VM cases,
>> potentially the firmware). Rust safety guarantees still keep things from
>> going entirely off the rails within the kernel, since everything that
>> matters is reference counted (which is why these reference cycles are
>> possible at all).
>>
>> This all started when I was looking at the panfrost driver for reference. It
>> does the same thing except it uses actual pointers to the owning entities
>> instead of IDs, and pointer comparison (see panfrost_gem_close). Of course
>> you could try do that in Rust too (literally storing and comparing raw
>> pointers that aren't owned references), but then you're introducing a Pin<>
>> requirement on those objects to make their addresses stable and it feels way
>> more icky and error-prone than unique IDs (since addresses can be reused).
>> panfrost only has a single mmu (what I call the raw VM) per File while I
>> have an arbitrary number, which is why I end up with the extra
>> distinction/complexity of both File and VM IDs, but the concept is the same.
>>
>> Some of this is going to be refactored when I implement arbitrary VM range
>> mapping/unmapping, which would be a good time to improve this... but is
>> there something particularly wrong/broken about the way I'm doing it now
>> that I missed? I figured unique u64 IDs would be a pretty safe way to
>> identify entities and cleanup the mappings when needed.
>
> Ok, some attempt at going through the vm_id/file_id stuff. Extremely
> high-level purely informed by having read too many drivers:
>
> First on the drm_file/struct file/file_id. This is the uapi interface
> object, and it's refcounted in the vfs, but that's entirely the vfs'
> business and none of the driver (or even subsystem). Once userspace has
> done the final close() the file is gone, there's no way to ever get
> anything meaningfully out of it because userspace dropped it. So if the
> driver has any kind of backpointer to that's a design bug, because in all
> the place you might want to care (ioctl, fdinfo for schedu stats, any
> other file_operations callback) the vfs ensures it stays alive during the
> callback and you essentially have a borrowed reference.
Right, there's none of that for the File, and it is not refcounted
itself. Certainly there are no direct references, and as for the IDs:
the IDs of relevant Files live in GEM objects that hold mappings owned
by that file. As part of File close all the GEM objects get closed,
which removes those mappings. So by the time the File goes away there
should be no references to its ID anywhere (other than if I stashed some
away for debugging, I forget whether I did in some child object).
If this process breaks for some reason (say, stray mappings remain
indexed to a File ID that is gone), that means we leak the mappings,
which leaks the GEM objects themselves and the VM they are mapped to.
Not great but not fireworks either. As long as the DRM core properly
calls the GEM close callback on everything before calling the File close
callback though, that shouldn't happen.
> I've seen a lot of drivers try to make clever backpointings to stuff
> that's essentially tied to the drm_file, and I've not found a single case
> that made sense. iow, file_id as a lookup thingie needs to go. In
> principle it's the same argument I've made already for the syncobj rust
> wrappers. For specific uses I guess I need some rust reading help, but
> from your description it sounds like the vm_id is much more the core
> piece.
The file ID is simply how GEM mappings are identified as belonging to an
active file within the mapping list of an object. GEM object close is
literally the only place this ID is ever used for anything other than
passing around:
/// Callback to drop all mappings for a GEM object owned by a given `File`
fn close(obj: &Object, file: &DrmFile) {
mod_pr_debug!("DriverObject::close vm_id={:?} id={}\n", obj.vm_id,
obj.id);
obj.drop_file_mappings(file.inner().file_id());
}
I could also just iterate through the VM XArray for the File and drop
mappings one VM at a time instead of doing all of them in one go, it's
just slightly more cumbersome (though potentially less code because I
could get rid of all the forwarding the file_id I do now).
On the other hand, once we implement arbitrary VM maps, I suspect this
is going to go away anyway with the new design, so I'm not really very
inclined to fix it until that happens... ^^
> So for that we have the gpu ctx -> vm -> gem_bos chain of reference. Now
> on the C side if you have a modern driver that uses the
> vm_bind/unbind/gpuva manager approach, the reference counts go in that
> single direction only, anything else is essentially borrowed references
> under protection of a mutex/lock or similar thing (for e.g. going from the
> bo to the vm for eviction).
Right, so that is what is going to change with the pending refactor.
What I have right now is a design that used to be the old driver-managed
VM design (and still retains part of that for kernel-managed objects)
for the old synchronous demo UAPI, that I then shoehorned into the
redesigned vm_bind UAPI by just not supporting the interesting cases
(partial maps/unmaps/remaps, etc.). This is all temporary, it's just to
get us by for now since OpenGL doesn't need it and there is no usable
Vulkan driver that cares yet... I wanted to focus on the explicit sync
and general sched/queuing part of the new UAPI before I got to the VM
bind stuff, since I figured that would be more interesting (and pulls in
all the new abstractions, plus major perf benefit). So the UAPI itself
has vm_bind but only the "easy" subset of cases are supported by the
driver (whole object maps/unmaps) and the refcounting is still backwards.
As I said this originally came from the Panfrost design that doesn't
have vm_bind but instead keeps a list of mappings with pointer equality
checks in BOs... so that's why ^^
Thanks for explaining the design approach though, it's roughly what I
had in mind but it's good to hear I'm on the right track! I'd love to go
into more detail about how to implement vm_bind if you have time though
(maybe a meeting?). In particular things like using the mm allocator to
keep track of mapping ranges and supporting splitting and all that.
> In addition to the above chain the xarray in the drm_file also holds
> references to each of these. So far so good, in the drm_file ->postclose
> callback you just walk the xarrays and drop all the references, and
> everything gets cleaned up, at least in the C world.
In the Rust world you just do nothing since the XArray abstraction knows
how to drop all of its contained objects!
> But if either due to the uabi being a bit more legacy, or Rust requiring
> that the backpointers are reference-counted from the gem_bo->vma->vm and
> can't follow borrow semantics (afaiui the usual linux list_head pattern of
> walking the list under a lock giving you a borrowed reference for each
> element doesn't work too well in rust?) then that's not a problem, you can
> still all clean it out:
>
> - The key bit is that your vm struct needs both a refcount like kref and
> a separate open count. Each gpu ctx and the xarray for vm objects in
> drm_file hold _both_ the kref and the open refcount (in rust the open
> refcount implies the Arc or things go sideways).
>
> - the other key bit is that drm_file ->postclose does _not_ have simple
> Drop semantics, it's more explicit.
>
> - in the drm_file lastclose you first walk all the gpu ctx. The simplest
> semantics is that close() synchronously tears down all leftover gpu ctx,
> i.e. you unload them from the gpu. Details are under a lot of discussion
> in the various scheduler threads, but essentially this should ensure
> that the gpu ctx destruction completely removes all references to the
> ctx. If instead you have the legacy problem of apps expecting that
> rendering continues even if they called exit() before it finishes, then
> it gets more messy. I have no idea whether that's still a problem for
> new drivers or can be avoided.
>
> - Next up you do the same thing for the vm xarray (which drops both the
> kref an open refcounts).
>
> - At this point there might still be a ton of vm objects around with
> elevated kref. Except not, because at this point the open refcount of
> each vm should have dropped to zero. When that happens the vm object
> itself is still alive, plus even better for rust, you are in the
> vm_close(vm) function call so you have a full borrowed reference to
> that. Which means you can walk the entire address space and unmap
> everything explicit. Which should get rid of any gem_bo->vma->vm
> backpointers you have lying around.
>
> - At that point all your vm objects are gone too, because the kref managed
> backpointers are gone.
>
> - You walk the xarray of gem_bo (well the drm subsystem does that for
> you), which cleans out the reamining references to gem_bo. Only the
> gem_bo which are shared with other process or have a dma_buf will
> survive, like they should.
>
> No leak, no funky driver-internal vm_id based lookup, and with rust we
> should even be able to guarantee you never mix up Arc<Vm> with OpenRef<Vm>
> (or however that exactly works in rust types, I have not much real clue).
That would totally work, and actually I already use somewhat analogous
mechanisms in other places like firmware queues!
If this all weren't getting turned on its head for the new VM management
I'd implement it, but hopefully we can agree there's not much point
right now... I'd rather focus on the DRM abstraction design and work on
improving the driver in parallel right now, and then about one kernel
cycle or so from now it should definitely be in a better place for
review. Honestly, there are bigger design problems with the driver right
now than these IDs (that I already know about)... so I want to focus
more on the abstractions and their usage right now than the internal
driver design which I *know* has problems ^^
Rust is really good at getting you to come up with a *safe* design as
far as memory and ownership, but that doesn't mean it's perfectly clean
code and more importantly it does nothing for deadlocks and allocating
in the wrong paths and getting resource allocation semantics right etc
etc. The GPU FW queue stuff is at the very least due for another major
refactor/cleanup to defer resource allocation and actual queuing to job
prepare/run time (right now there's some horrible hacks to do it upfront
at submit because I don't have a mechanism to back-patch job structures
with those resource IDs later at exec time, but I want to add that), and
along the way I can also fix the using job fences to block on pending
job count thing that Christian really wants me to do instead of the
can_run_job thing, and then getting all this resource stuff truly right
is also going to mean eventually using fences to handle blocking on
resource exhaustion too (though maybe I can get away with implementing
that a bit later)...
The driver works stupidly well for how quickly I wrote it, but it still
has all these rough edges that definitely need fixing before it's
something I could say I'm happy with... I'm sure if you start hammering
it with evil workloads you will hit some of its current problems (like I
did yesterday with the deadlocks on GpuContext inval). I also need to
learn more about the subtleties of fence signaling and all that,
especially once a shrinker comes into play...
~~ Lina
^ permalink raw reply [flat|nested] 122+ messages in thread* Re: [Linaro-mm-sig] Re: [PATCH RFC 18/18] drm/asahi: Add the Asahi driver for Apple AGX GPUs
2023-04-06 13:15 ` Asahi Lina
@ 2023-04-06 13:48 ` Daniel Vetter
2023-04-06 15:19 ` Asahi Lina
0 siblings, 1 reply; 122+ messages in thread
From: Daniel Vetter @ 2023-04-06 13:48 UTC (permalink / raw)
To: Asahi Lina
Cc: Daniel Vetter, David Airlie, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, Miguel Ojeda, Alex Gaynor,
Wedson Almeida Filho, Boqun Feng, Gary Guo, Björn Roy Baron,
Sumit Semwal, Christian König, Luben Tuikov,
Jarkko Sakkinen, Dave Hansen, Alyssa Rosenzweig, Karol Herbst,
Ella Stanforth, Faith Ekstrand, Mary, linux-kernel, dri-devel,
rust-for-linux, linux-media, linaro-mm-sig, linux-sgx, asahi
On Thu, Apr 06, 2023 at 10:15:56PM +0900, Asahi Lina wrote:
> On 06/04/2023 20.55, Daniel Vetter wrote:
> > On Thu, Apr 06, 2023 at 01:44:22PM +0900, Asahi Lina wrote:
> > > On 05/04/2023 23.37, Daniel Vetter wrote:
> > > > On Tue, Mar 07, 2023 at 11:25:43PM +0900, Asahi Lina wrote:
> > > > > +/// A generic monotonically incrementing ID used to uniquely identify object instances within the
> > > > > +/// driver.
> > > > > +pub(crate) struct ID(AtomicU64);
> > > > > +
> > > > > +impl ID {
> > > > > + /// Create a new ID counter with a given value.
> > > > > + fn new(val: u64) -> ID {
> > > > > + ID(AtomicU64::new(val))
> > > > > + }
> > > > > +
> > > > > + /// Fetch the next unique ID.
> > > > > + pub(crate) fn next(&self) -> u64 {
> > > > > + self.0.fetch_add(1, Ordering::Relaxed)
> > > > > + }
> > > > > +}
> > > >
> > > > Continuing the theme of me commenting on individual things, I stumbled
> > > > over this because I noticed that there's a lot of id based lookups where I
> > > > don't expect them, and started chasing.
> > > >
> > > > - For ids use xarray, not atomic counters. Yes I know dma_fence timelines
> > > > gets this wrong, this goes back to an innocent time where we didn't
> > > > allocate more than one timeline per engine, and no one fixed it since
> > > > then. Yes u64 should be big enough for everyone :-/
> > > >
> > > > - Attaching ID spaces to drm_device is also not great. drm is full of
> > > > these mistakes. Much better if their per drm_file and so private to each
> > > > client.
> > > >
> > > > - They shouldn't be used for anything else than uapi id -> kernel object
> > > > lookup at the beginning of ioctl code, and nowhere else. At least from
> > > > skimming it seems like these are used all over the driver codebase,
> > > > which does freak me out. At least on the C side that's a clear indicator
> > > > for a refcount/lockin/data structure model that's not thought out at
> > > > all.
> > > >
> > > > What's going on here, what do I miss?
> > >
> > > These aren't UAPI IDs, they are driver-internal IDs (the UAPI IDs do use
> > > xarray and are per-File). Most of them are just for debugging, so that when
> > > I enable full debug spam I have some way to correlate different things that
> > > are happening together (this subset of interleaved log lines relate to the
> > > same submission). Basically just object names that are easier to read (and
> > > less of a security leak) than pointers and guaranteed not to repeat. You
> > > could get rid of most of them and it wouldn't affect the driver design, it
> > > just makes it very hard to see what's going on with debug logs ^^;
> > >
> > > There are only two that are ever used for non-debugging purposes: the VM ID,
> > > and the File ID. Both are per-device global IDs attached to the VMs (not the
> > > UAPI VM objects, but rather the underlyng MMU address space managers they
> > > represent, including the kernel-internal ones) and to Files themselves. They
> > > are used for destroying GEM objects: since the objects are also
> > > device-global across multiple clients, I need a way to do things like "clean
> > > up all mappings for this File" or "clean up all mappings for this VM".
> > > There's an annoying circular reference between GEM objects and their
> > > mappings, which is why this is explicitly coded out in destroy paths instead
> > > of naturally happening via Drop semantics (without that cleanup code, the
> > > circular reference leaks it).
> > >
> > > So e.g. when a File does a GEM close or explicitly asks for all mappings of
> > > an object to be removed, it goes out to the (possibly shared) GEM object and
> > > tells it to drop all mappings marked as owned by that unique File ID. When
> > > an explicit "unmap all in VM" op happens, it asks the GEM object to drop all
> > > mappings for that underlying VM ID. Similarly, when a UAPI VM object is
> > > dropped (in the Drop impl, so both explicitly and when the whole File/xarray
> > > is dropped and such), that does an explicit unmap of a special dummy object
> > > it owns which would otherwise leak since it is not tracked as a GEM object
> > > owned by that File and therefore not handled by GEM closing. And again along
> > > the same lines, the allocators in alloc.rs explicitly destroy the mappings
> > > for their backing GEM objects on Drop. All this is due to that annoying
> > > circular reference between VMs and GEM objects that I'm not sure how to fix.
> > >
> > > Note that if I *don't* do this (or forget to do it somewhere) the
> > > consequence is just that we leak memory, and if you try to destroy the wrong
> > > IDs somehow the worst that can happen is you unmap things you shouldn't and
> > > fault the GPU (or, in the kernel or kernel-managed user VM cases,
> > > potentially the firmware). Rust safety guarantees still keep things from
> > > going entirely off the rails within the kernel, since everything that
> > > matters is reference counted (which is why these reference cycles are
> > > possible at all).
> > >
> > > This all started when I was looking at the panfrost driver for reference. It
> > > does the same thing except it uses actual pointers to the owning entities
> > > instead of IDs, and pointer comparison (see panfrost_gem_close). Of course
> > > you could try do that in Rust too (literally storing and comparing raw
> > > pointers that aren't owned references), but then you're introducing a Pin<>
> > > requirement on those objects to make their addresses stable and it feels way
> > > more icky and error-prone than unique IDs (since addresses can be reused).
> > > panfrost only has a single mmu (what I call the raw VM) per File while I
> > > have an arbitrary number, which is why I end up with the extra
> > > distinction/complexity of both File and VM IDs, but the concept is the same.
> > >
> > > Some of this is going to be refactored when I implement arbitrary VM range
> > > mapping/unmapping, which would be a good time to improve this... but is
> > > there something particularly wrong/broken about the way I'm doing it now
> > > that I missed? I figured unique u64 IDs would be a pretty safe way to
> > > identify entities and cleanup the mappings when needed.
> >
> > Ok, some attempt at going through the vm_id/file_id stuff. Extremely
> > high-level purely informed by having read too many drivers:
> >
> > First on the drm_file/struct file/file_id. This is the uapi interface
> > object, and it's refcounted in the vfs, but that's entirely the vfs'
> > business and none of the driver (or even subsystem). Once userspace has
> > done the final close() the file is gone, there's no way to ever get
> > anything meaningfully out of it because userspace dropped it. So if the
> > driver has any kind of backpointer to that's a design bug, because in all
> > the place you might want to care (ioctl, fdinfo for schedu stats, any
> > other file_operations callback) the vfs ensures it stays alive during the
> > callback and you essentially have a borrowed reference.
>
> Right, there's none of that for the File, and it is not refcounted itself.
> Certainly there are no direct references, and as for the IDs: the IDs of
> relevant Files live in GEM objects that hold mappings owned by that file. As
> part of File close all the GEM objects get closed, which removes those
> mappings. So by the time the File goes away there should be no references to
> its ID anywhere (other than if I stashed some away for debugging, I forget
> whether I did in some child object).
>
> If this process breaks for some reason (say, stray mappings remain indexed
> to a File ID that is gone), that means we leak the mappings, which leaks the
> GEM objects themselves and the VM they are mapped to. Not great but not
> fireworks either. As long as the DRM core properly calls the GEM close
> callback on everything before calling the File close callback though, that
> shouldn't happen.
>
> > I've seen a lot of drivers try to make clever backpointings to stuff
> > that's essentially tied to the drm_file, and I've not found a single case
> > that made sense. iow, file_id as a lookup thingie needs to go. In
> > principle it's the same argument I've made already for the syncobj rust
> > wrappers. For specific uses I guess I need some rust reading help, but
> > from your description it sounds like the vm_id is much more the core
> > piece.
>
> The file ID is simply how GEM mappings are identified as belonging to an
> active file within the mapping list of an object. GEM object close is
> literally the only place this ID is ever used for anything other than
> passing around:
>
> /// Callback to drop all mappings for a GEM object owned by a given `File`
> fn close(obj: &Object, file: &DrmFile) {
> mod_pr_debug!("DriverObject::close vm_id={:?} id={}\n", obj.vm_id,
> obj.id);
> obj.drop_file_mappings(file.inner().file_id());
> }
>
> I could also just iterate through the VM XArray for the File and drop
> mappings one VM at a time instead of doing all of them in one go, it's just
> slightly more cumbersome (though potentially less code because I could get
> rid of all the forwarding the file_id I do now).
>
> On the other hand, once we implement arbitrary VM maps, I suspect this is
> going to go away anyway with the new design, so I'm not really very inclined
> to fix it until that happens... ^^
Yeah the driver-managed vm needs a bunch more reference loops and gets
awkward fast. the gpuva library might need to keep support for that, but I
really hope it's not needed.
> > So for that we have the gpu ctx -> vm -> gem_bos chain of reference. Now
> > on the C side if you have a modern driver that uses the
> > vm_bind/unbind/gpuva manager approach, the reference counts go in that
> > single direction only, anything else is essentially borrowed references
> > under protection of a mutex/lock or similar thing (for e.g. going from the
> > bo to the vm for eviction).
>
> Right, so that is what is going to change with the pending refactor. What I
> have right now is a design that used to be the old driver-managed VM design
> (and still retains part of that for kernel-managed objects) for the old
> synchronous demo UAPI, that I then shoehorned into the redesigned vm_bind
> UAPI by just not supporting the interesting cases (partial
> maps/unmaps/remaps, etc.). This is all temporary, it's just to get us by for
> now since OpenGL doesn't need it and there is no usable Vulkan driver that
> cares yet... I wanted to focus on the explicit sync and general
> sched/queuing part of the new UAPI before I got to the VM bind stuff, since
> I figured that would be more interesting (and pulls in all the new
> abstractions, plus major perf benefit). So the UAPI itself has vm_bind but
> only the "easy" subset of cases are supported by the driver (whole object
> maps/unmaps) and the refcounting is still backwards.
>
> As I said this originally came from the Panfrost design that doesn't have
> vm_bind but instead keeps a list of mappings with pointer equality checks in
> BOs... so that's why ^^
>
> Thanks for explaining the design approach though, it's roughly what I had in
> mind but it's good to hear I'm on the right track! I'd love to go into more
> detail about how to implement vm_bind if you have time though (maybe a
> meeting?). In particular things like using the mm allocator to keep track of
> mapping ranges and supporting splitting and all that.
Yeah vm_bind sounds like a good topic to discuss. I don't think we'll get
all the pieces aligned to land that before asahi, but the driver internals
should at least match wrt semantics with that so that the refactoring
isn't total pain.
> > In addition to the above chain the xarray in the drm_file also holds
> > references to each of these. So far so good, in the drm_file ->postclose
> > callback you just walk the xarrays and drop all the references, and
> > everything gets cleaned up, at least in the C world.
>
> In the Rust world you just do nothing since the XArray abstraction knows how
> to drop all of its contained objects!
Yeah xarray should work with Drop, but I guess you need a special
uapi/open-reference object that knows that it needs to perform additional
cleanup (like quiescent the gpu ctx or unamp everything for the vm).
> > But if either due to the uabi being a bit more legacy, or Rust requiring
> > that the backpointers are reference-counted from the gem_bo->vma->vm and
> > can't follow borrow semantics (afaiui the usual linux list_head pattern of
> > walking the list under a lock giving you a borrowed reference for each
> > element doesn't work too well in rust?) then that's not a problem, you can
> > still all clean it out:
> >
> > - The key bit is that your vm struct needs both a refcount like kref and
> > a separate open count. Each gpu ctx and the xarray for vm objects in
> > drm_file hold _both_ the kref and the open refcount (in rust the open
> > refcount implies the Arc or things go sideways).
> >
> > - the other key bit is that drm_file ->postclose does _not_ have simple
> > Drop semantics, it's more explicit.
> >
> > - in the drm_file lastclose you first walk all the gpu ctx. The simplest
> > semantics is that close() synchronously tears down all leftover gpu ctx,
> > i.e. you unload them from the gpu. Details are under a lot of discussion
> > in the various scheduler threads, but essentially this should ensure
> > that the gpu ctx destruction completely removes all references to the
> > ctx. If instead you have the legacy problem of apps expecting that
> > rendering continues even if they called exit() before it finishes, then
> > it gets more messy. I have no idea whether that's still a problem for
> > new drivers or can be avoided.
> >
> > - Next up you do the same thing for the vm xarray (which drops both the
> > kref an open refcounts).
> >
> > - At this point there might still be a ton of vm objects around with
> > elevated kref. Except not, because at this point the open refcount of
> > each vm should have dropped to zero. When that happens the vm object
> > itself is still alive, plus even better for rust, you are in the
> > vm_close(vm) function call so you have a full borrowed reference to
> > that. Which means you can walk the entire address space and unmap
> > everything explicit. Which should get rid of any gem_bo->vma->vm
> > backpointers you have lying around.
> >
> > - At that point all your vm objects are gone too, because the kref managed
> > backpointers are gone.
> >
> > - You walk the xarray of gem_bo (well the drm subsystem does that for
> > you), which cleans out the reamining references to gem_bo. Only the
> > gem_bo which are shared with other process or have a dma_buf will
> > survive, like they should.
> >
> > No leak, no funky driver-internal vm_id based lookup, and with rust we
> > should even be able to guarantee you never mix up Arc<Vm> with OpenRef<Vm>
> > (or however that exactly works in rust types, I have not much real clue).
>
> That would totally work, and actually I already use somewhat analogous
> mechanisms in other places like firmware queues!
>
> If this all weren't getting turned on its head for the new VM management I'd
> implement it, but hopefully we can agree there's not much point right now...
> I'd rather focus on the DRM abstraction design and work on improving the
> driver in parallel right now, and then about one kernel cycle or so from now
> it should definitely be in a better place for review. Honestly, there are
> bigger design problems with the driver right now than these IDs (that I
> already know about)... so I want to focus more on the abstractions and their
> usage right now than the internal driver design which I *know* has problems
> ^^
Yeah I think the only fundamental issue you have is that (if I get this
all right) you're trying to clean up mappings from the gem_bo, not from
the vm. The gem_bo (unlike the vm) is freely shareable (at least in
general), so tying anything else to the lifetime of a gem_bo in any way is
a design flaw.
This is similar to dma_fence that can end up absolutely everywhere, and
why drm/sched has this decoupling between hw_fence and drm_job fences with
wider visibility. i915-gem/i915-scheduler and a lot of the really old
drivers all get this wrong, and you end up with either terrible explicit
cleanup code that tries to go around looking for all the references that
it needs to drop. Or you just leak.
All these things need to be sorted out at design time so that they're
impossible.
> Rust is really good at getting you to come up with a *safe* design as far as
> memory and ownership, but that doesn't mean it's perfectly clean code and
> more importantly it does nothing for deadlocks and allocating in the wrong
> paths and getting resource allocation semantics right etc etc. The GPU FW
> queue stuff is at the very least due for another major refactor/cleanup to
> defer resource allocation and actual queuing to job prepare/run time (right
> now there's some horrible hacks to do it upfront at submit because I don't
> have a mechanism to back-patch job structures with those resource IDs later
> at exec time, but I want to add that), and along the way I can also fix the
> using job fences to block on pending job count thing that Christian really
> wants me to do instead of the can_run_job thing, and then getting all this
> resource stuff truly right is also going to mean eventually using fences to
> handle blocking on resource exhaustion too (though maybe I can get away with
> implementing that a bit later)...
>
> The driver works stupidly well for how quickly I wrote it, but it still has
> all these rough edges that definitely need fixing before it's something I
> could say I'm happy with... I'm sure if you start hammering it with evil
> workloads you will hit some of its current problems (like I did yesterday
> with the deadlocks on GpuContext inval). I also need to learn more about the
> subtleties of fence signaling and all that, especially once a shrinker comes
> into play...
Yeah I think rust is impressive at creating working code. The real
challenge, and really where I see all the short term value at least, is in
clarifying the semantics. Because that'll help us to clarify the semantics
on the C side too, which gives immediate benefits for everyone. Not just
new drivers in rust.
But it's also the part that's really, really hard work.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
^ permalink raw reply [flat|nested] 122+ messages in thread* Re: [Linaro-mm-sig] Re: [PATCH RFC 18/18] drm/asahi: Add the Asahi driver for Apple AGX GPUs
2023-04-06 13:48 ` Daniel Vetter
@ 2023-04-06 15:19 ` Asahi Lina
0 siblings, 0 replies; 122+ messages in thread
From: Asahi Lina @ 2023-04-06 15:19 UTC (permalink / raw)
To: Daniel Vetter
Cc: David Airlie, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, Miguel Ojeda, Alex Gaynor,
Wedson Almeida Filho, Boqun Feng, Gary Guo, Björn Roy Baron,
Sumit Semwal, Christian König, Luben Tuikov,
Jarkko Sakkinen, Dave Hansen, Alyssa Rosenzweig, Karol Herbst,
Ella Stanforth, Faith Ekstrand, Mary, linux-kernel, dri-devel,
rust-for-linux, linux-media, linaro-mm-sig, linux-sgx, asahi
On 06/04/2023 22.48, Daniel Vetter wrote:
> On Thu, Apr 06, 2023 at 10:15:56PM +0900, Asahi Lina wrote:
>> On 06/04/2023 20.55, Daniel Vetter wrote:
>>> On Thu, Apr 06, 2023 at 01:44:22PM +0900, Asahi Lina wrote:
>>>> On 05/04/2023 23.37, Daniel Vetter wrote:
>>>>> On Tue, Mar 07, 2023 at 11:25:43PM +0900, Asahi Lina wrote:
>>>>>> +/// A generic monotonically incrementing ID used to uniquely identify object instances within the
>>>>>> +/// driver.
>>>>>> +pub(crate) struct ID(AtomicU64);
>>>>>> +
>>>>>> +impl ID {
>>>>>> + /// Create a new ID counter with a given value.
>>>>>> + fn new(val: u64) -> ID {
>>>>>> + ID(AtomicU64::new(val))
>>>>>> + }
>>>>>> +
>>>>>> + /// Fetch the next unique ID.
>>>>>> + pub(crate) fn next(&self) -> u64 {
>>>>>> + self.0.fetch_add(1, Ordering::Relaxed)
>>>>>> + }
>>>>>> +}
>>>>>
>>>>> Continuing the theme of me commenting on individual things, I stumbled
>>>>> over this because I noticed that there's a lot of id based lookups where I
>>>>> don't expect them, and started chasing.
>>>>>
>>>>> - For ids use xarray, not atomic counters. Yes I know dma_fence timelines
>>>>> gets this wrong, this goes back to an innocent time where we didn't
>>>>> allocate more than one timeline per engine, and no one fixed it since
>>>>> then. Yes u64 should be big enough for everyone :-/
>>>>>
>>>>> - Attaching ID spaces to drm_device is also not great. drm is full of
>>>>> these mistakes. Much better if their per drm_file and so private to each
>>>>> client.
>>>>>
>>>>> - They shouldn't be used for anything else than uapi id -> kernel object
>>>>> lookup at the beginning of ioctl code, and nowhere else. At least from
>>>>> skimming it seems like these are used all over the driver codebase,
>>>>> which does freak me out. At least on the C side that's a clear indicator
>>>>> for a refcount/lockin/data structure model that's not thought out at
>>>>> all.
>>>>>
>>>>> What's going on here, what do I miss?
>>>>
>>>> These aren't UAPI IDs, they are driver-internal IDs (the UAPI IDs do use
>>>> xarray and are per-File). Most of them are just for debugging, so that when
>>>> I enable full debug spam I have some way to correlate different things that
>>>> are happening together (this subset of interleaved log lines relate to the
>>>> same submission). Basically just object names that are easier to read (and
>>>> less of a security leak) than pointers and guaranteed not to repeat. You
>>>> could get rid of most of them and it wouldn't affect the driver design, it
>>>> just makes it very hard to see what's going on with debug logs ^^;
>>>>
>>>> There are only two that are ever used for non-debugging purposes: the VM ID,
>>>> and the File ID. Both are per-device global IDs attached to the VMs (not the
>>>> UAPI VM objects, but rather the underlyng MMU address space managers they
>>>> represent, including the kernel-internal ones) and to Files themselves. They
>>>> are used for destroying GEM objects: since the objects are also
>>>> device-global across multiple clients, I need a way to do things like "clean
>>>> up all mappings for this File" or "clean up all mappings for this VM".
>>>> There's an annoying circular reference between GEM objects and their
>>>> mappings, which is why this is explicitly coded out in destroy paths instead
>>>> of naturally happening via Drop semantics (without that cleanup code, the
>>>> circular reference leaks it).
>>>>
>>>> So e.g. when a File does a GEM close or explicitly asks for all mappings of
>>>> an object to be removed, it goes out to the (possibly shared) GEM object and
>>>> tells it to drop all mappings marked as owned by that unique File ID. When
>>>> an explicit "unmap all in VM" op happens, it asks the GEM object to drop all
>>>> mappings for that underlying VM ID. Similarly, when a UAPI VM object is
>>>> dropped (in the Drop impl, so both explicitly and when the whole File/xarray
>>>> is dropped and such), that does an explicit unmap of a special dummy object
>>>> it owns which would otherwise leak since it is not tracked as a GEM object
>>>> owned by that File and therefore not handled by GEM closing. And again along
>>>> the same lines, the allocators in alloc.rs explicitly destroy the mappings
>>>> for their backing GEM objects on Drop. All this is due to that annoying
>>>> circular reference between VMs and GEM objects that I'm not sure how to fix.
>>>>
>>>> Note that if I *don't* do this (or forget to do it somewhere) the
>>>> consequence is just that we leak memory, and if you try to destroy the wrong
>>>> IDs somehow the worst that can happen is you unmap things you shouldn't and
>>>> fault the GPU (or, in the kernel or kernel-managed user VM cases,
>>>> potentially the firmware). Rust safety guarantees still keep things from
>>>> going entirely off the rails within the kernel, since everything that
>>>> matters is reference counted (which is why these reference cycles are
>>>> possible at all).
>>>>
>>>> This all started when I was looking at the panfrost driver for reference. It
>>>> does the same thing except it uses actual pointers to the owning entities
>>>> instead of IDs, and pointer comparison (see panfrost_gem_close). Of course
>>>> you could try do that in Rust too (literally storing and comparing raw
>>>> pointers that aren't owned references), but then you're introducing a Pin<>
>>>> requirement on those objects to make their addresses stable and it feels way
>>>> more icky and error-prone than unique IDs (since addresses can be reused).
>>>> panfrost only has a single mmu (what I call the raw VM) per File while I
>>>> have an arbitrary number, which is why I end up with the extra
>>>> distinction/complexity of both File and VM IDs, but the concept is the same.
>>>>
>>>> Some of this is going to be refactored when I implement arbitrary VM range
>>>> mapping/unmapping, which would be a good time to improve this... but is
>>>> there something particularly wrong/broken about the way I'm doing it now
>>>> that I missed? I figured unique u64 IDs would be a pretty safe way to
>>>> identify entities and cleanup the mappings when needed.
>>>
>>> Ok, some attempt at going through the vm_id/file_id stuff. Extremely
>>> high-level purely informed by having read too many drivers:
>>>
>>> First on the drm_file/struct file/file_id. This is the uapi interface
>>> object, and it's refcounted in the vfs, but that's entirely the vfs'
>>> business and none of the driver (or even subsystem). Once userspace has
>>> done the final close() the file is gone, there's no way to ever get
>>> anything meaningfully out of it because userspace dropped it. So if the
>>> driver has any kind of backpointer to that's a design bug, because in all
>>> the place you might want to care (ioctl, fdinfo for schedu stats, any
>>> other file_operations callback) the vfs ensures it stays alive during the
>>> callback and you essentially have a borrowed reference.
>>
>> Right, there's none of that for the File, and it is not refcounted itself.
>> Certainly there are no direct references, and as for the IDs: the IDs of
>> relevant Files live in GEM objects that hold mappings owned by that file. As
>> part of File close all the GEM objects get closed, which removes those
>> mappings. So by the time the File goes away there should be no references to
>> its ID anywhere (other than if I stashed some away for debugging, I forget
>> whether I did in some child object).
>>
>> If this process breaks for some reason (say, stray mappings remain indexed
>> to a File ID that is gone), that means we leak the mappings, which leaks the
>> GEM objects themselves and the VM they are mapped to. Not great but not
>> fireworks either. As long as the DRM core properly calls the GEM close
>> callback on everything before calling the File close callback though, that
>> shouldn't happen.
>>
>>> I've seen a lot of drivers try to make clever backpointings to stuff
>>> that's essentially tied to the drm_file, and I've not found a single case
>>> that made sense. iow, file_id as a lookup thingie needs to go. In
>>> principle it's the same argument I've made already for the syncobj rust
>>> wrappers. For specific uses I guess I need some rust reading help, but
>>> from your description it sounds like the vm_id is much more the core
>>> piece.
>>
>> The file ID is simply how GEM mappings are identified as belonging to an
>> active file within the mapping list of an object. GEM object close is
>> literally the only place this ID is ever used for anything other than
>> passing around:
>>
>> /// Callback to drop all mappings for a GEM object owned by a given `File`
>> fn close(obj: &Object, file: &DrmFile) {
>> mod_pr_debug!("DriverObject::close vm_id={:?} id={}\n", obj.vm_id,
>> obj.id);
>> obj.drop_file_mappings(file.inner().file_id());
>> }
>>
>> I could also just iterate through the VM XArray for the File and drop
>> mappings one VM at a time instead of doing all of them in one go, it's just
>> slightly more cumbersome (though potentially less code because I could get
>> rid of all the forwarding the file_id I do now).
>>
>> On the other hand, once we implement arbitrary VM maps, I suspect this is
>> going to go away anyway with the new design, so I'm not really very inclined
>> to fix it until that happens... ^^
>
> Yeah the driver-managed vm needs a bunch more reference loops and gets
> awkward fast. the gpuva library might need to keep support for that, but I
> really hope it's not needed.
>
>>> So for that we have the gpu ctx -> vm -> gem_bos chain of reference. Now
>>> on the C side if you have a modern driver that uses the
>>> vm_bind/unbind/gpuva manager approach, the reference counts go in that
>>> single direction only, anything else is essentially borrowed references
>>> under protection of a mutex/lock or similar thing (for e.g. going from the
>>> bo to the vm for eviction).
>>
>> Right, so that is what is going to change with the pending refactor. What I
>> have right now is a design that used to be the old driver-managed VM design
>> (and still retains part of that for kernel-managed objects) for the old
>> synchronous demo UAPI, that I then shoehorned into the redesigned vm_bind
>> UAPI by just not supporting the interesting cases (partial
>> maps/unmaps/remaps, etc.). This is all temporary, it's just to get us by for
>> now since OpenGL doesn't need it and there is no usable Vulkan driver that
>> cares yet... I wanted to focus on the explicit sync and general
>> sched/queuing part of the new UAPI before I got to the VM bind stuff, since
>> I figured that would be more interesting (and pulls in all the new
>> abstractions, plus major perf benefit). So the UAPI itself has vm_bind but
>> only the "easy" subset of cases are supported by the driver (whole object
>> maps/unmaps) and the refcounting is still backwards.
>>
>> As I said this originally came from the Panfrost design that doesn't have
>> vm_bind but instead keeps a list of mappings with pointer equality checks in
>> BOs... so that's why ^^
>>
>> Thanks for explaining the design approach though, it's roughly what I had in
>> mind but it's good to hear I'm on the right track! I'd love to go into more
>> detail about how to implement vm_bind if you have time though (maybe a
>> meeting?). In particular things like using the mm allocator to keep track of
>> mapping ranges and supporting splitting and all that.
>
> Yeah vm_bind sounds like a good topic to discuss. I don't think we'll get
> all the pieces aligned to land that before asahi, but the driver internals
> should at least match wrt semantics with that so that the refactoring
> isn't total pain.
>
>>> In addition to the above chain the xarray in the drm_file also holds
>>> references to each of these. So far so good, in the drm_file ->postclose
>>> callback you just walk the xarrays and drop all the references, and
>>> everything gets cleaned up, at least in the C world.
>>
>> In the Rust world you just do nothing since the XArray abstraction knows how
>> to drop all of its contained objects!
>
> Yeah xarray should work with Drop, but I guess you need a special
> uapi/open-reference object that knows that it needs to perform additional
> cleanup (like quiescent the gpu ctx or unamp everything for the vm).
Yeah, I already have that for VMs. Since I have a layer between UAPI VM
objects and the underlying MMU VM objects, the UAPI VM object Drop impl
can take care of explicitly unmapping whatever it needs to, or however
that ends up working out with the new design. I prefer that to explicit
cleanup code since it means you can't forget to do it.
Rust is pretty nice for throwing around tiny objects, 1:1 wrappers, or
even zero-sized types that just do one thing + Drop in order to make
some semantic ergonomic to use. That's how the XArray reservation stuff
works: you get back a trivial object that just references the queue (yay
lifetimes, no refcounting here) and holds the reservation open, and then
you either fill it (which consumes the reservation guard) or drop it
(which cleans up the reservation). There's lots of that kind of pattern
in kernel Rust and I think we should use it often, it just makes things
a lot less error-prone (ScopeGuard is another nice one!)
>>> But if either due to the uabi being a bit more legacy, or Rust requiring
>>> that the backpointers are reference-counted from the gem_bo->vma->vm and
>>> can't follow borrow semantics (afaiui the usual linux list_head pattern of
>>> walking the list under a lock giving you a borrowed reference for each
>>> element doesn't work too well in rust?) then that's not a problem, you can
>>> still all clean it out:
>>>
>>> - The key bit is that your vm struct needs both a refcount like kref and
>>> a separate open count. Each gpu ctx and the xarray for vm objects in
>>> drm_file hold _both_ the kref and the open refcount (in rust the open
>>> refcount implies the Arc or things go sideways).
>>>
>>> - the other key bit is that drm_file ->postclose does _not_ have simple
>>> Drop semantics, it's more explicit.
>>>
>>> - in the drm_file lastclose you first walk all the gpu ctx. The simplest
>>> semantics is that close() synchronously tears down all leftover gpu ctx,
>>> i.e. you unload them from the gpu. Details are under a lot of discussion
>>> in the various scheduler threads, but essentially this should ensure
>>> that the gpu ctx destruction completely removes all references to the
>>> ctx. If instead you have the legacy problem of apps expecting that
>>> rendering continues even if they called exit() before it finishes, then
>>> it gets more messy. I have no idea whether that's still a problem for
>>> new drivers or can be avoided.
>>>
>>> - Next up you do the same thing for the vm xarray (which drops both the
>>> kref an open refcounts).
>>>
>>> - At this point there might still be a ton of vm objects around with
>>> elevated kref. Except not, because at this point the open refcount of
>>> each vm should have dropped to zero. When that happens the vm object
>>> itself is still alive, plus even better for rust, you are in the
>>> vm_close(vm) function call so you have a full borrowed reference to
>>> that. Which means you can walk the entire address space and unmap
>>> everything explicit. Which should get rid of any gem_bo->vma->vm
>>> backpointers you have lying around.
>>>
>>> - At that point all your vm objects are gone too, because the kref managed
>>> backpointers are gone.
>>>
>>> - You walk the xarray of gem_bo (well the drm subsystem does that for
>>> you), which cleans out the reamining references to gem_bo. Only the
>>> gem_bo which are shared with other process or have a dma_buf will
>>> survive, like they should.
>>>
>>> No leak, no funky driver-internal vm_id based lookup, and with rust we
>>> should even be able to guarantee you never mix up Arc<Vm> with OpenRef<Vm>
>>> (or however that exactly works in rust types, I have not much real clue).
>>
>> That would totally work, and actually I already use somewhat analogous
>> mechanisms in other places like firmware queues!
>>
>> If this all weren't getting turned on its head for the new VM management I'd
>> implement it, but hopefully we can agree there's not much point right now...
>> I'd rather focus on the DRM abstraction design and work on improving the
>> driver in parallel right now, and then about one kernel cycle or so from now
>> it should definitely be in a better place for review. Honestly, there are
>> bigger design problems with the driver right now than these IDs (that I
>> already know about)... so I want to focus more on the abstractions and their
>> usage right now than the internal driver design which I *know* has problems
>> ^^
>
> Yeah I think the only fundamental issue you have is that (if I get this
> all right) you're trying to clean up mappings from the gem_bo, not from
> the vm. The gem_bo (unlike the vm) is freely shareable (at least in
> general), so tying anything else to the lifetime of a gem_bo in any way is
> a design flaw.
Yeah, it wasn't nice from the start. Actually the first bit of code I
wrote is the MMU code, and originally it was even literally C code based
on the panfrost MMU code as-is... I quickly realized that the C wasn't
going to be that useful when I started diving into the GEM abstractions,
so it got rewritten in Rust early on...
So right now it works (and I have no reason to believe it has actual
leak bugs lurking today) but it's not a nice design and it's going to
get a major refactor/redesign once I switch to proper vm_bind tracking.
> This is similar to dma_fence that can end up absolutely everywhere, and
> why drm/sched has this decoupling between hw_fence and drm_job fences with
> wider visibility. i915-gem/i915-scheduler and a lot of the really old
> drivers all get this wrong, and you end up with either terrible explicit
> cleanup code that tries to go around looking for all the references that
> it needs to drop. Or you just leak.
I think for fences my general approach is going to be to just try to
keep to what I'm doing now and minimize the references fences hold, and
treat them as a signaling mechanism that ideally doesn't have to hold a
reference to anything other than the module. After all, the real king of
what needs to be alive is the firmware, and its mechanisms don't map
well to fences directly, so I need to do bespoke resource management
there anyway (and then just plug it into fences so it can feed into
drm_sched and the rest of the world). I don't know if that makes sense,
but it feels like it does? I still need to spend a bunch of time
thinking about this though...
> All these things need to be sorted out at design time so that they're
> impossible.
That's the other nice thing about Rust, it makes refactoring a lot
faster too! The compiler is really good at annoying you and refusing to
compile things until you've fixed all the really dumb mistakes you
introduced, and then there's a pretty good chance it'll run and the
remaining bugs will be really obvious after that. As much as you learn
to hate the compiler, it's so much better than trying to debug things at
runtime... ^^
I'm not sure what your opinion is on this, but personally if you/others
were okay with it I wouldn't be too worried about hypothetically merging
the driver in the state it's in today, with the expectation to hack
major parts of it to bits and pieces over the next few months. I've done
it a few times already... it usually doesn't take more than a day or two
to make some major refactor to a component and get it back up and
running. (I do expect to do a bunch of that cleanup over the next few
months before it's even possible to merge anyway, just a hypothetical).
>> Rust is really good at getting you to come up with a *safe* design as far as
>> memory and ownership, but that doesn't mean it's perfectly clean code and
>> more importantly it does nothing for deadlocks and allocating in the wrong
>> paths and getting resource allocation semantics right etc etc. The GPU FW
>> queue stuff is at the very least due for another major refactor/cleanup to
>> defer resource allocation and actual queuing to job prepare/run time (right
>> now there's some horrible hacks to do it upfront at submit because I don't
>> have a mechanism to back-patch job structures with those resource IDs later
>> at exec time, but I want to add that), and along the way I can also fix the
>> using job fences to block on pending job count thing that Christian really
>> wants me to do instead of the can_run_job thing, and then getting all this
>> resource stuff truly right is also going to mean eventually using fences to
>> handle blocking on resource exhaustion too (though maybe I can get away with
>> implementing that a bit later)...
>>
>> The driver works stupidly well for how quickly I wrote it, but it still has
>> all these rough edges that definitely need fixing before it's something I
>> could say I'm happy with... I'm sure if you start hammering it with evil
>> workloads you will hit some of its current problems (like I did yesterday
>> with the deadlocks on GpuContext inval). I also need to learn more about the
>> subtleties of fence signaling and all that, especially once a shrinker comes
>> into play...
>
> Yeah I think rust is impressive at creating working code. The real
> challenge, and really where I see all the short term value at least, is in
> clarifying the semantics. Because that'll help us to clarify the semantics
> on the C side too, which gives immediate benefits for everyone. Not just
> new drivers in rust.
>
> But it's also the part that's really, really hard work.
Yup!
~~ Lina
^ permalink raw reply [flat|nested] 122+ messages in thread