From: Zhao Liu <zhao1.liu@intel.com>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: "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>,
qemu-devel@nongnu.org, qemu-rust@nongnu.org
Subject: Re: [RFC 03/13] rust/cell: add get_mut() method for BqlCell
Date: Sat, 7 Dec 2024 23:56:41 +0800 [thread overview]
Message-ID: <Z1RwOR3RWQTjrnYs@intel.com> (raw)
In-Reply-To: <75edc6e5-e65f-40c0-90ee-6ac1fa018f5c@redhat.com>
On Thu, Dec 05, 2024 at 04:55:47PM +0100, Paolo Bonzini wrote:
> Date: Thu, 5 Dec 2024 16:55:47 +0100
> From: Paolo Bonzini <pbonzini@redhat.com>
> Subject: Re: [RFC 03/13] rust/cell: add get_mut() method for BqlCell
>
> On 12/5/24 07:07, Zhao Liu wrote:
> > The get_mut() is useful when doing compound assignment operations, e.g.,
> > *c.get_mut() += 1.
> >
> > Implement get_mut() for BqlCell by referring to Cell.
>
> I think you can't do this because the BQL might be released while the owner has a &mut. Like:
Thanks for pointing that out, I really didn't think of that, I
understand how that would break the atomicity of the BQL lock, right?
> let mtx = Mutex<BqlCell<u32>>::new();
> let guard = mtx.lock();
> let cell = &mut *guard;
> let inner = cell.get_mut(cell);
> // anything that releases bql_lock
> *inner += 1;
>
> On the other hand I don't think you need it. You have just two uses.
>
> First, this one:
>
> + if set && self.is_int_level_triggered() {
> + // If Timer N Interrupt Enable bit is 0, "the timer will
> + // still operate and generate appropriate status bits, but
> + // will not cause an interrupt"
> + *self.get_state_mut().int_status.get_mut() |= mask;
> + } else {
> + *self.get_state_mut().int_status.get_mut() &= !mask;
> + }
>
> Where you can just write
>
> self.get_state_ref().update_int_status(self.index,
> set && self.is_int_level_triggered())
>
> and the HPETState can do something like
>
> fn update_int_status(&self, index: u32, level: bool) {
> self.int_status.set(deposit64(self.int_status.get(), bit, 1, level as u64));
> }
Yes, it's clearer!
> For hpet_fw_cfg you have unsafe in the device and it's better if you do:
>
> - self.hpet_id.set(unsafe { hpet_fw_cfg.assign_hpet_id() });
> + self.hpet_id.set(fw_cfg_config::assign_hpet_id());
>
> with methods like this that do the unsafe access:
>
> impl fw_cfg_config {
> pub(crate) fn assign_hpet_id() -> usize {
> assert!(bql_locked());
> // SAFETY: all accesses go through these methods, which guarantee
> // that the accesses are protected by the BQL.
> let fw_cfg = unsafe { &mut *hpet_fw_cfg };
Nice idea!
> if self.count == u8::MAX {
> // first instance
> fw_cfg.count = 0;
> }
Will something like “anything that releases bql_lock” happen here?
There seems to be no atomicity guarantee here.
> if fw_cfg.count == 8 {
> // TODO: Add error binding: error_setg()
> panic!("Only 8 instances of HPET is allowed");
> }
>
> let id: usize = fw_cfg.count.into();
> fw_cfg.count += 1;
> id
> }
> }
>
> and you can assert bql_locked by hand instead of using the BqlCell.
Thanks! I can also add a line of doc for bql_locked that it can be used
directly without BqlCell if necessary.
And if you also agree the Phillipe's idea, I also need to add BqlCell
for fw_cfg field in HPETClass :-).
Regards,
Zhao
next prev parent reply other threads:[~2024-12-07 15:39 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 [this message]
2024-12-07 19:49 ` Paolo Bonzini
2024-12-05 6:07 ` [RFC 04/13] rust: add bindings for gpio_{in|out} initialization Zhao Liu
2024-12-05 18:53 ` 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=Z1RwOR3RWQTjrnYs@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).