All of lore.kernel.org
 help / color / mirror / Atom feed
From: Zhao Liu <zhao1.liu@intel.com>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: qemu-devel@nongnu.org, junjie.mao@hotmail.com, qemu-rust@nongnu.org
Subject: Re: [PATCH 2/2] rust: add bindings for interrupt sources
Date: Tue, 26 Nov 2024 21:45:19 +0800	[thread overview]
Message-ID: <Z0XQ79uYWNUrbmR2@intel.com> (raw)
In-Reply-To: <20241122074756.282142-3-pbonzini@redhat.com>

On Fri, Nov 22, 2024 at 08:47:56AM +0100, Paolo Bonzini wrote:
> Date: Fri, 22 Nov 2024 08:47:56 +0100
> From: Paolo Bonzini <pbonzini@redhat.com>
> Subject: [PATCH 2/2] rust: add bindings for interrupt sources
> X-Mailer: git-send-email 2.47.0
> 
> The InterruptSource bindings let us call qemu_set_irq() and sysbus_init_irq()
> as safe code.
> 
> Interrupt sources, qemu_irq in C code, are pointers to IRQState objects.
> They are QOM link properties and can be written to outside the control
> of the device (i.e. from a shared reference); therefore they must be
> interior-mutable in Rust. 

Out of curiosity, are there any examples of this situation?

> Since thread-safety is provided by the BQL,
> what we want here is the newly-introduced BqlCell.  A pointer to the
> contents of the BqlCell (an IRQState**, or equivalently qemu_irq*)
> is then passed to the C sysbus_init_irq function.
> 
> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
> ---
>  rust/hw/char/pl011/src/device.rs | 22 ++++++-----
>  rust/qemu-api/meson.build        |  2 +
>  rust/qemu-api/src/irq.rs         | 66 ++++++++++++++++++++++++++++++++
>  rust/qemu-api/src/lib.rs         |  2 +
>  rust/qemu-api/src/sysbus.rs      | 26 +++++++++++++
>  5 files changed, 108 insertions(+), 10 deletions(-)
>  create mode 100644 rust/qemu-api/src/irq.rs
>  create mode 100644 rust/qemu-api/src/sysbus.rs

...

> +    /// Send `level` to the interrupt sink.
> +    pub fn set(&self, level: bool) {
> +        unsafe {
> +            qemu_set_irq(self.0.get(), level.into());
> +        }
> +    }

Regarding the boolean discussion, the c_int/i32->boolean conversion
seems unavoidable if it is changed to a boolean, for example, the
level parameter in qemu_irq_handler is declared to be c_int, and
there is a pattern of setting the level in qemu_irq_handler with the
level irq:
* hpet_handle_legacy_irq
* split_irq_handler
* a9mp_priv_set_irq
...

So it feels like a more direct way to follow the use of c_int or i32?
Inconsistent types for level are always confusing. Maybe we can change
the type of rust after the C version can be standardized to boolean?

> +    pub(crate) const fn as_ptr(&self) -> *mut *mut IRQState {
> +        self.0.as_ptr()
> +    }
> +}
> +
> +impl Default for InterruptSource {
> +    fn default() -> Self {
> +        InterruptSource(BqlCell::new(ptr::null_mut()))
> +    }
> +}
> +

I like this idea and this binding is very useful!

HPET also needs qdev_init_gpio_in() and qdev_init_gpio_out(). 
Should these two safe binding wrappers be implemented as methods of
DeviceState, or just the public functions?

Regards,
Zhao




  parent reply	other threads:[~2024-11-26 13:52 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-11-22  7:47 [PATCH 0/2] rust: safe wrappers for interrupt sources Paolo Bonzini
2024-11-22  7:47 ` [PATCH 1/2] rust: add BQL-enforcing Cell variant Paolo Bonzini
2024-11-26 14:56   ` Zhao Liu
2024-11-26 16:11     ` Paolo Bonzini
2024-11-27  6:35       ` Zhao Liu
2024-11-27  8:31         ` Paolo Bonzini
2024-11-27  6:54   ` Junjie Mao
2024-11-22  7:47 ` [PATCH 2/2] rust: add bindings for interrupt sources Paolo Bonzini
2024-11-22  8:28   ` Philippe Mathieu-Daudé
2024-11-22  8:32     ` Paolo Bonzini
2024-11-22 10:30       ` Philippe Mathieu-Daudé
2024-11-22 10:53         ` Paolo Bonzini
2024-11-22 11:07           ` Philippe Mathieu-Daudé
2024-11-26 13:45   ` Zhao Liu [this message]
2024-11-26 13:35     ` Paolo Bonzini

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=Z0XQ79uYWNUrbmR2@intel.com \
    --to=zhao1.liu@intel.com \
    --cc=junjie.mao@hotmail.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.