Re: [PATCH 22/22] rust/hpet: Enable lockless IO

[Paolo Bonzini <pbonzini@redhat.com>]

On 11/13/25 06:19, Zhao Liu wrote:
> Enable lockless IO for HPET to allow BQL free MMIO access.
> 
> But BQL context is still needed for some cases during MMIO:
>   * IRQ handling:
> 
>     Like C version of HPET did (commit d99041a20328 ("hpet: guard IRQ
>     handling with BQL"), BQL context is needed during IRQ handling.
> 
>     But Rust HPET has an extra reason that InterruptSource is placed in
>     BqlCell, which requires BQL context explicitly. (This also shows
>     that the BQL limitation in the design of the InterruptSource binding
>     is reasonable.)

Thanks, this is helpful.  It shows some complications that I honestly 
hadn't thought about.  So many more things to be precise about, compared 
to C...  but I have an idea which I'll mention below. :)

>   * BqlCell/BqlRefCell access.
> 
>     Except InterruptSource, HPETState has other BqlCell and BqlRefCell:
>     hpet_offset (BqlCell<u64>), rtc_irq_level (BqlCell<u32>) and timers
>     ([BqlRefCell<HPETTimer>; HPET_MAX_TIMERS]).
> 
>     Their data may change during runtime, so the atomic context is
>     required.

I have already mentioned HPETTimer in the other email, but I would also 
move hpet_offset to HPETRegisters if possible.  It doesn't seem hard.

And as an aside, I wonder if you really need to pass MutexGuard and not 
&mut HPETRegisters.  Once you don't have BQL dependencies, you can just 
remove the assert!(bql::is_locked()) without switching to MutexGuard<>.

In the meanwhile, even if they are not perfect (especially due to 
migration), I think touching patches 1-19 further is too messy, so I'll 
rebase on top of Stefan's tracing patches and push them to rust-next. 
Let's start from there and I'll take a look tomorrow maybe on how to fix 
migration.  Migratable<HPETTimer> looks like a powerful tool for that.

Then the new problem is that we have to figure out a way to handle IRQs. 
They are also messy for PL011 compared to the C version, and that will 
make it possible to enable lockless IO.

The crazy idea that just came to mind, is a Latched<u32> that is 
something like an (AtomicU32, BqlCell<u32>) tuple.  Then we set the 
individual bits outside the BQL and update IRQs at the end of the MMIO 
in a bql::with_guard() block.  Maybe if you have some time you can 
prototype that for PL011 (even without generics, you could just do 
LatchedU32 for a start)?

Paolo