From: Zhao Liu <zhao1.liu@intel.com>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: qemu-devel@nongnu.org, qemu-rust@nongnu.org
Subject: Re: [PATCH 08/10] rust: qdev: switch from legacy reset to Resettable
Date: Mon, 27 Jan 2025 18:31:59 +0800 [thread overview]
Message-ID: <Z5dgn5MQNGEa5lry@intel.com> (raw)
In-Reply-To: <20250117194003.1173231-9-pbonzini@redhat.com>
> +/// Trait providing the contents of [`ResettablePhases`].
> +pub trait ResettablePhasesImpl {
> + /// If not None, this is called when the object enters reset. It
> + /// can reset local state of the object, but it must not do anything that
> + /// has a side-effect on other objects, such as raising or lowering a
> + /// [`qemu_irq`] line or reading or writing guest memory. It takes the
> + /// reset's type as argument.
> + const ENTER: Option<fn(&Self, ResetType)> = None;
> +
> + /// If not None, this is called when the object for entry into reset, once
> + /// every object in the system which is being reset has had its
> + /// @phases.enter method called. At this point devices can do actions
Maybe s/@phases.enter/ResettablePhasesImpl::ENTER/?
> + /// that affect other objects.
> + ///
> + /// If in doubt, implement this method.
> + const HOLD: Option<fn(&Self, ResetType)> = None;
> +
> + /// If not None, this phase is called when the object leaves the reset
> + /// state. Actions affecting other objects are permitted.
> + const EXIT: Option<fn(&Self, ResetType)> = None;
> +}
> +
...
> impl<T> ClassInitImpl<DeviceClass> for T
> where
> - T: ClassInitImpl<ObjectClass> + DeviceImpl,
> + T: ClassInitImpl<ObjectClass> + ClassInitImpl<ResettableClass> + DeviceImpl,
This constraint requires each device to explicitly implement ResettablePhasesImpl,
even the device doesn't want to do anything for reset.
So what about the following changes:
* Define 3-Phases methods in DeviceImpl.
* Implement ResettablePhasesImpl for all devices by passing their 3-Phases
methods to ResettablePhasesImpl's.
Then device doesn't need to implement this reset trait if unnecessary.
For example:
--- a/rust/qemu-api/src/qdev.rs
+++ b/rust/qemu-api/src/qdev.rs
@@ -84,7 +84,7 @@ pub trait ResettablePhasesImpl {
}
/// Trait providing the contents of [`DeviceClass`].
-pub trait DeviceImpl: ObjectImpl + ResettablePhasesImpl {
+pub trait DeviceImpl: ObjectImpl {
/// _Realization_ is the second stage of device creation. It contains
/// all operations that depend on device properties and can fail (note:
/// this is not yet supported for Rust devices).
@@ -106,6 +106,18 @@ fn properties() -> &'static [Property] {
fn vmsd() -> Option<&'static VMStateDescription> {
None
}
+
+ const RESET_ENTER: Option<fn(&Self, ResetType)> = None;
+ const RESET_HOLD: Option<fn(&Self, ResetType)> = None;
+ const RESET_EXIT: Option<fn(&Self, ResetType)> = None;
+}
+
+impl<T> ResettablePhasesImpl for T
+where T: DeviceImpl
+{
+ const ENTER: Option<fn(&Self, ResetType)> = T::RESET_ENTER;
+ const HOLD: Option<fn(&Self, ResetType)> = T::RESET_HOLD;
+ const EXIT: Option<fn(&Self, ResetType)> = T::RESET_EXIT;
}
/// # Safety
---
Though this way add duplicate methods, it reduces the burden on the
device developer.
Regards,
Zhao
> {
> fn class_init(dc: &mut DeviceClass) {
> if <T as DeviceImpl>::REALIZE.is_some() {
> dc.realize = Some(rust_realize_fn::<T>);
> }
> - if <T as DeviceImpl>::RESET.is_some() {
> - unsafe {
> - bindings::device_class_set_legacy_reset(dc, Some(rust_reset_fn::<T>));
> - }
> - }
> if let Some(vmsd) = <T as DeviceImpl>::vmsd() {
> dc.vmsd = vmsd;
> }
> @@ -99,6 +162,7 @@ fn class_init(dc: &mut DeviceClass) {
> }
> }
>
> + ResettableClass::interface_init::<T, DeviceState>(dc);
> <T as ClassInitImpl<ObjectClass>>::class_init(&mut dc.parent_class);
> }
> }
next prev parent reply other threads:[~2025-01-27 10:13 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-01-17 19:39 [RFC PATCH 00/10] rust: remaining part of qdev bindings Paolo Bonzini
2025-01-17 19:39 ` [PATCH 01/10] rust: qemu-api: add sub-subclass to the integration tests Paolo Bonzini
2025-01-20 16:40 ` Zhao Liu
2025-01-17 19:39 ` [PATCH 02/10] rust: qom: add reference counting functionality Paolo Bonzini
2025-01-26 15:15 ` Zhao Liu
2025-01-29 10:03 ` Paolo Bonzini
2025-02-05 8:28 ` Zhao Liu
2025-01-27 7:57 ` Zhao Liu
2025-01-29 10:16 ` Paolo Bonzini
2025-02-05 9:13 ` Zhao Liu
2025-02-05 9:10 ` Paolo Bonzini
2025-02-05 9:40 ` Zhao Liu
2025-02-06 3:26 ` Zhao Liu
2025-01-17 19:39 ` [PATCH 03/10] rust: qom: add object creation functionality Paolo Bonzini
2025-02-06 7:49 ` Zhao Liu
2025-02-06 7:39 ` Paolo Bonzini
2025-01-17 19:39 ` [PATCH 04/10] rust: callbacks: allow passing optional callbacks as () Paolo Bonzini
2025-01-27 8:41 ` Zhao Liu
2025-01-17 19:39 ` [PATCH 05/10] rust: qdev: add clock creation Paolo Bonzini
2025-02-06 8:15 ` Zhao Liu
2025-01-17 19:39 ` [PATCH 06/10] rust: qom: allow initializing interface vtables Paolo Bonzini
2025-01-27 10:33 ` Zhao Liu
2025-01-17 19:40 ` [PATCH 07/10] rust: qdev: make ObjectImpl a supertrait of DeviceImpl Paolo Bonzini
2025-01-27 9:10 ` Zhao Liu
2025-02-06 8:37 ` Philippe Mathieu-Daudé
2025-01-17 19:40 ` [PATCH 08/10] rust: qdev: switch from legacy reset to Resettable Paolo Bonzini
2025-01-27 10:31 ` Zhao Liu [this message]
2025-01-27 18:01 ` Paolo Bonzini
2025-01-28 9:25 ` Zhao Liu
2025-02-06 8:31 ` Zhao Liu
2025-01-17 19:40 ` [PATCH 09/10] rust: bindings: add Sync markers to types referred to by MemoryRegionOps Paolo Bonzini
2025-01-27 10:58 ` Zhao Liu
2025-01-17 19:40 ` [PATCH 10/10] rust: bindings for MemoryRegionOps Paolo Bonzini
2025-01-27 12:12 ` Zhao Liu
2025-01-27 18:11 ` Paolo Bonzini
2025-02-06 9:15 ` Zhao Liu
2025-02-06 9:15 ` Paolo Bonzini
2025-02-06 8:39 ` Philippe Mathieu-Daudé
2025-02-06 8:46 ` Paolo Bonzini
2025-02-06 10:02 ` Philippe Mathieu-Daudé
2025-02-06 10:19 ` Paolo Bonzini
2025-02-10 10:38 ` Philippe Mathieu-Daudé
2025-01-24 2:46 ` [RFC PATCH 00/10] rust: remaining part of qdev bindings 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=Z5dgn5MQNGEa5lry@intel.com \
--to=zhao1.liu@intel.com \
--cc=pbonzini@redhat.com \
--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).