> > > +impl_vmstate_scalar!(vmstate_info_uint64, u64);
> >
> > What about applying this to "usize" with vmstate_info_uint64?
>
> There's 32-bit hosts too... So one would have to add vmstate_info_ulong
> which is serialized as 64-bit.
>
> We can add it later, but perhaps we could also create a derive(Index,
> IndexMut) macro that makes it possible to specify the type of the index.
> While Rust uses usize instead of uNN for array indices, that does not have
> to be universal; using uNN is a lot better if it means you can get rid of
> casts from register values to array indices and back. See for example
> commit 6b4f7b0705b ("rust: pl011: fix migration stream", 2024-12-19).
Yes, I agree!
> That is indeed also an issue for HPET, but in that case it can be isolated
> to a couple lines,
>
> let timer_id: usize = ((addr - 0x100) / 0x20) as usize;
>
> and it could even be wrapped further
>
> fn timer_and_addr(&self, addr: hwaddr) -> Option<&BqlRefCell<HPETTimer>,
> hwaddr> {
> let timer_id: usize = ((addr - 0x100) / 0x20) as usize;
> if timer_id > self.num_timers.get() {
> // TODO: Add trace point -
> trace_hpet_timer_id_out_of_range(timer_id)
> None
> } else {
> Some((self.get_timer(timer_id), addr & 0x18))
> }
> }
>
> ...
>
> match self.timer_and_addr(addr) {
> None => 0 // Reserved,
> Some(timer, addr) => timer.borrow_mut().read(addr, size)
> }
>
>
> So for HPET you didn't reach the threshold of having to create "pub struct
> HPETTimers([BqlRefCell<HPETTimer>; MAX_HPET_TIMERS])" and implement Index<>.
>
Thank you Paolo! Will apply your wrapping suggestion!
Regards,
Zhao
