From: Zhao Liu <zhao1.liu@intel.com>
To: "Paolo Bonzini" <pbonzini@redhat.com>,
"Michael S . Tsirkin" <mst@redhat.com>,
"Manos Pitsidianakis" <manos.pitsidianakis@linaro.org>,
"Junjie Mao" <junjie.mao@hotmail.com>,
"Alex Bennée" <alex.bennee@linaro.org>,
"Philippe Mathieu-Daudé" <philmd@linaro.org>,
"Peter Maydell" <peter.maydell@linaro.org>
Cc: qemu-devel@nongnu.org, qemu-rust@nongnu.org,
Zhao Liu <zhao1.liu@intel.com>
Subject: [RFC 04/13] rust: add bindings for gpio_{in|out} initialization
Date: Thu, 5 Dec 2024 14:07:05 +0800 [thread overview]
Message-ID: <20241205060714.256270-5-zhao1.liu@intel.com> (raw)
In-Reply-To: <20241205060714.256270-1-zhao1.liu@intel.com>
The qdev_init_gpio_{in|out} are qdev interfaces, so that it's natural to
wrap them as DeviceState's methods in Rust API, which could eliminate
unsafe cases in the device lib.
Wrap qdev_init_gpio_{in|out} as methods in a new trait DeviceGPIOImpl.
In addition, for qdev_init_gpio_in(), to convert the idiomatic Rust
callback into a C-style callback qemu_irq_handler, add a handler pointer
member in DeviceGPIOImpl. For any device needs to initialize GPIO in, it
needs to define a handler. And for device which just wants to initialize
GPIO out, it can leave the GPIO_IRQ_HANDLER as None.
Then device could use init_gpio_in() and init_gpio_out() to initialize
GPIO in and out, like C code.
Note, for qemu_irq_handler, assume the opaque parameter refers to the
self DeviceState, and this is enough as for now, as it's the most common
case in QEMU.
Signed-off-by: Zhao Liu <zhao1.liu@intel.com>
---
rust/qemu-api/src/qdev.rs | 55 +++++++++++++++++++++++++++++++++++++--
1 file changed, 53 insertions(+), 2 deletions(-)
diff --git a/rust/qemu-api/src/qdev.rs b/rust/qemu-api/src/qdev.rs
index 23a06b377b2c..5e6580b6f261 100644
--- a/rust/qemu-api/src/qdev.rs
+++ b/rust/qemu-api/src/qdev.rs
@@ -4,12 +4,17 @@
//! Bindings to create devices and access device functionality from Rust.
-use std::ffi::CStr;
+use std::{
+ ffi::CStr,
+ os::raw::{c_int, c_void},
+ ptr::{addr_of, NonNull},
+};
pub use bindings::{DeviceClass, DeviceState, Property};
use crate::{
- bindings::{self, Error},
+ bindings::{self, qdev_init_gpio_in, qdev_init_gpio_out, Error},
+ irq::InterruptSource,
qom::{ClassInitImpl, Object, ObjectClass, ObjectType},
qom_isa,
vmstate::VMStateDescription,
@@ -144,3 +149,49 @@ unsafe impl ObjectType for DeviceState {
unsafe { CStr::from_bytes_with_nul_unchecked(bindings::TYPE_DEVICE) };
}
qom_isa!(DeviceState: Object);
+
+/// # Safety
+///
+/// We expect the FFI user of this function to pass a valid pointer that
+/// can be downcasted to type `T`. We also expect the device is
+/// readable/writeable from one thread at any time.
+///
+/// Note: Always assume opaque is referred to the self DeviceState, and
+/// this is also the most common case in QEMU.
+unsafe extern "C" fn rust_irq_handler<T: DeviceGPIOImpl>(
+ opaque: *mut c_void,
+ lines_num: c_int,
+ level: c_int,
+) {
+ // SAFETY:
+ // the pointer is convertible to a reference
+ let state = unsafe { NonNull::new(opaque.cast::<T>()).unwrap().as_mut() };
+
+ T::GPIO_IRQ_HANDLER.unwrap()(state, lines_num as u32, level as u32);
+}
+
+/// Trait that defines the irq handler for GPIO in.
+pub trait DeviceGPIOImpl {
+ const GPIO_IRQ_HANDLER: Option<fn(&mut Self, lines_num: u32, level: u32)> = None;
+
+ fn init_gpio_in(&self, lines_num: u32)
+ where
+ Self: Sized,
+ {
+ assert!(Self::GPIO_IRQ_HANDLER.is_some());
+
+ unsafe {
+ qdev_init_gpio_in(
+ addr_of!(*self) as *mut _,
+ Some(rust_irq_handler::<Self>),
+ lines_num as c_int,
+ );
+ }
+ }
+
+ fn init_gpio_out(&self, pins: &InterruptSource, lines_num: u32) {
+ unsafe {
+ qdev_init_gpio_out(addr_of!(*self) as *mut _, pins.as_ptr(), lines_num as c_int);
+ }
+ }
+}
--
2.34.1
next prev parent reply other threads:[~2024-12-05 5:49 UTC|newest]
Thread overview: 72+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-12-05 6:07 [RFC 00/13] rust: Reinvent the wheel for HPET timer in Rust Zhao Liu
2024-12-05 6:07 ` [RFC 01/13] bql: check that the BQL is not dropped within marked sections Zhao Liu
2024-12-05 6:07 ` [RFC 02/13] rust: cell: add BQL-enforcing RefCell variant Zhao Liu
2024-12-05 6:07 ` [RFC 03/13] rust/cell: add get_mut() method for BqlCell Zhao Liu
2024-12-05 15:55 ` Paolo Bonzini
2024-12-07 15:56 ` Zhao Liu
2024-12-07 19:49 ` Paolo Bonzini
2024-12-05 6:07 ` Zhao Liu [this message]
2024-12-05 18:53 ` [RFC 04/13] rust: add bindings for gpio_{in|out} initialization Paolo Bonzini
2024-12-08 16:27 ` Zhao Liu
2024-12-09 11:08 ` Paolo Bonzini
2025-01-16 3:04 ` Zhao Liu
2025-01-17 9:40 ` Paolo Bonzini
2025-01-17 11:14 ` Zhao Liu
2025-01-17 12:47 ` Paolo Bonzini
2024-12-05 6:07 ` [RFC 05/13] rust: add a bit operation binding for deposit64 Zhao Liu
2024-12-05 16:09 ` Paolo Bonzini
2024-12-07 16:01 ` Zhao Liu
2024-12-07 19:44 ` Paolo Bonzini
2024-12-05 6:07 ` [RFC 06/13] rust: add bindings for memattrs Zhao Liu
2024-12-05 18:15 ` Richard Henderson
2024-12-05 18:30 ` Paolo Bonzini
2024-12-05 23:51 ` Richard Henderson
2024-12-06 8:41 ` Zhao Liu
2024-12-06 14:07 ` Richard Henderson
2024-12-06 10:59 ` Peter Maydell
2024-12-06 14:28 ` Paolo Bonzini
2024-12-06 14:42 ` Peter Maydell
2024-12-06 19:13 ` Paolo Bonzini
2025-01-20 16:52 ` Zhao Liu
2025-01-20 17:19 ` Paolo Bonzini
2025-01-23 15:10 ` Zhao Liu
2025-01-23 15:33 ` Paolo Bonzini
2024-12-07 9:21 ` Philippe Mathieu-Daudé
2024-12-08 9:30 ` Paolo Bonzini
2024-12-08 15:51 ` Zhao Liu
2024-12-05 6:07 ` [RFC 07/13] rust: add bindings for timer Zhao Liu
2024-12-05 18:18 ` Richard Henderson
2024-12-07 17:18 ` Zhao Liu
2024-12-05 18:46 ` Paolo Bonzini
2024-12-07 16:54 ` Zhao Liu
2025-01-14 15:36 ` Zhao Liu
2025-01-14 15:42 ` Zhao Liu
2025-01-14 16:14 ` Paolo Bonzini
2025-01-15 7:09 ` Zhao Liu
2024-12-05 6:07 ` [RFC 08/13] rust/qdev: add the macro to define bit property Zhao Liu
2024-12-05 6:07 ` [RFC 09/13] i386/fw_cfg: move hpet_cfg definition to hpet.c Zhao Liu
2024-12-05 12:04 ` Philippe Mathieu-Daudé
2024-12-05 12:46 ` Zhao Liu
2024-12-05 21:17 ` Philippe Mathieu-Daudé
2024-12-05 21:19 ` Paolo Bonzini
2024-12-07 9:16 ` Philippe Mathieu-Daudé
2024-12-07 15:36 ` Zhao Liu
2024-12-05 15:30 ` Paolo Bonzini
2024-12-07 15:28 ` Zhao Liu
2025-01-17 10:31 ` Zhao Liu
2025-01-17 10:15 ` Paolo Bonzini
2024-12-05 6:07 ` [RFC 10/13] rust/timer/hpet: define hpet_fw_cfg Zhao Liu
2024-12-05 6:07 ` [RFC 11/13] rust/timer/hpet: add basic HPET timer & state Zhao Liu
2024-12-05 20:22 ` Paolo Bonzini
2024-12-05 21:20 ` Paolo Bonzini
2024-12-09 7:46 ` Zhao Liu
2024-12-09 7:26 ` Zhao Liu
2024-12-05 6:07 ` [RFC 12/13] rust/timer/hpet: add qdev APIs support Zhao Liu
2024-12-05 18:58 ` Paolo Bonzini
2024-12-07 16:05 ` Zhao Liu
2024-12-05 6:07 ` [RFC 13/13] i386: enable rust hpet for pc when rust is enabled Zhao Liu
2024-12-05 15:20 ` Paolo Bonzini
2024-12-06 9:06 ` Zhao Liu
2024-12-05 6:22 ` [RFC 00/13] rust: Reinvent the wheel for HPET timer in Rust Zhao Liu
2024-12-05 16:28 ` Paolo Bonzini
2024-12-09 7:57 ` Zhao Liu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20241205060714.256270-5-zhao1.liu@intel.com \
--to=zhao1.liu@intel.com \
--cc=alex.bennee@linaro.org \
--cc=junjie.mao@hotmail.com \
--cc=manos.pitsidianakis@linaro.org \
--cc=mst@redhat.com \
--cc=pbonzini@redhat.com \
--cc=peter.maydell@linaro.org \
--cc=philmd@linaro.org \
--cc=qemu-devel@nongnu.org \
--cc=qemu-rust@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).