e5655e92 | 18-Mar-2025 |
Zhao Liu <zhao1.liu@intel.com> |
rust/vmstate: Fix unnecessary VMState bound of with_varray_flag()
The VMState type bound is not used in with_varray_flag().
And for vmstate_struct, Rust cannot infer the type of `num` from the call
rust/vmstate: Fix unnecessary VMState bound of with_varray_flag()
The VMState type bound is not used in with_varray_flag().
And for vmstate_struct, Rust cannot infer the type of `num` from the call_func_with_field(), so this causes the compiling error because it complains "cannot satisfy `_: VMState`" in with_varray_flag().
Note Rust can infer the type in vmstate_of macro so that with_varray_flag() can work at there. It is possible that the different initialization ways in the two macros cause differences in Rust's type inference.
But in fact, the VMState type bound is not used in with_varray_flag() and vmstate_varray_flag() has already checked the VMState type, it's safe to drop VMState bound of with_varray_flag(), which can fix the above compiling error.
Signed-off-by: Zhao Liu <zhao1.liu@intel.com> Link: https://lore.kernel.org/r/20250318130219.1799170-8-zhao1.liu@intel.com Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
show more ...
|
42c814b1 | 18-Mar-2025 |
Zhao Liu <zhao1.liu@intel.com> |
rust/vmstate: Fix "cannot infer type" error in vmstate_struct
Rust cannot infer the type (it should be VMStateField) after Zeroable::ZERO, which cause the compiling error.
To fix this error, call w
rust/vmstate: Fix "cannot infer type" error in vmstate_struct
Rust cannot infer the type (it should be VMStateField) after Zeroable::ZERO, which cause the compiling error.
To fix this error, call with_varray_flag() after VMStateField's initialization.
Signed-off-by: Zhao Liu <zhao1.liu@intel.com> Link: https://lore.kernel.org/r/20250318130219.1799170-7-zhao1.liu@intel.com Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
show more ...
|
61825825 | 18-Mar-2025 |
Zhao Liu <zhao1.liu@intel.com> |
rust/vmstate: Fix type check for varray in vmstate_struct
When pass a varray to vmstate_struct, the `type` parameter should be the type of the element in the varray, for example:
vmstate_struct!(HP
rust/vmstate: Fix type check for varray in vmstate_struct
When pass a varray to vmstate_struct, the `type` parameter should be the type of the element in the varray, for example:
vmstate_struct!(HPETState, timers, [0 .. num_timers], VMSTATE_HPET_TIMER, BqlRefCell<HPETTimer>).with_version_id(0)
But this breaks current type check, because it checks the type of `field`, which is an array type (for the above example, type of timers is [BqlRefCell<HPETTimer>; 32], not BqlRefCell<HPETTimer>).
But the current assert_field_type() can no longer be extended to include new arguments, so a variant of it (a second macro containing the `num = $num:ident` parameter) had to be added to handle array cases.
In this new macro, it not only checks the type of element, but also checks whether the `num` (number of elements in varray) is out of range.
Signed-off-by: Zhao Liu <zhao1.liu@intel.com> Link: https://lore.kernel.org/r/20250318130219.1799170-6-zhao1.liu@intel.com Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
show more ...
|
20797069 | 18-Mar-2025 |
Zhao Liu <zhao1.liu@intel.com> |
rust/vmstate: Fix size field of VMStateField with VMS_ARRAY_OF_POINTER flag
The `size` field of the VMStateField with VMS_ARRAY_OF_POINTER flag should stores the size of pointer, which depends on pl
rust/vmstate: Fix size field of VMStateField with VMS_ARRAY_OF_POINTER flag
The `size` field of the VMStateField with VMS_ARRAY_OF_POINTER flag should stores the size of pointer, which depends on platform.
Currently, `*const`, `*mut`, `NonNull`, `Box<>` and their wrapper are supported, and they have the same size as `usize`.
Store the size (of `usize`) when VMS_ARRAY_OF_POINTER flag is set.
The size may be changed when more smart pointers are supported, but now the size of "usize" is enough.
Signed-off-by: Zhao Liu <zhao1.liu@intel.com> Link: https://lore.kernel.org/r/20250318130219.1799170-5-zhao1.liu@intel.com Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
show more ...
|
c3d80af5 | 18-Mar-2025 |
Zhao Liu <zhao1.liu@intel.com> |
rust/vmstate: Fix num field when varray flags are set
Array type vmstate has the VMStateField with `num` equals its length.
When the varray vmstate is built based a array type, the `num` field shou
rust/vmstate: Fix num field when varray flags are set
Array type vmstate has the VMStateField with `num` equals its length.
When the varray vmstate is built based a array type, the `num` field should be cleaned to 0, because varray uses `num_offset` instead of `num` to store elements number information.
Signed-off-by: Zhao Liu <zhao1.liu@intel.com> Link: https://lore.kernel.org/r/20250318130219.1799170-4-zhao1.liu@intel.com Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
show more ...
|
6ca5c3be | 18-Mar-2025 |
Zhao Liu <zhao1.liu@intel.com> |
rust/vmstate: Fix num_offset in vmstate macros
`num_offset` is a member of `VMStateField`, and there's no need to use "." to access this field in a `VMStateField` instance.
Signed-off-by: Zhao Liu
rust/vmstate: Fix num_offset in vmstate macros
`num_offset` is a member of `VMStateField`, and there's no need to use "." to access this field in a `VMStateField` instance.
Signed-off-by: Zhao Liu <zhao1.liu@intel.com> Link: https://lore.kernel.org/r/20250318130219.1799170-3-zhao1.liu@intel.com Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
show more ...
|
ea8a7ceb | 18-Mar-2025 |
Zhao Liu <zhao1.liu@intel.com> |
rust/vmstate: Remove unnecessary unsafe
Remove the `unsafe` block of vmsd, because vmsd (passed to vmstate_struct) is defined in Rust side now, and it doesn't need `unsafe`.
Signed-off-by: Zhao Liu
rust/vmstate: Remove unnecessary unsafe
Remove the `unsafe` block of vmsd, because vmsd (passed to vmstate_struct) is defined in Rust side now, and it doesn't need `unsafe`.
Signed-off-by: Zhao Liu <zhao1.liu@intel.com> Link: https://lore.kernel.org/r/20250318130219.1799170-2-zhao1.liu@intel.com Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
show more ...
|
9d116f42 | 21-Mar-2025 |
Paolo Bonzini <pbonzini@redhat.com> |
rust: assertions: add static_assert
Add a new assertion that is similar to "const { assert!(...) }" but can be used outside functions and with older versions of Rust. A similar macro is found in Li
rust: assertions: add static_assert
Add a new assertion that is similar to "const { assert!(...) }" but can be used outside functions and with older versions of Rust. A similar macro is found in Linux, whereas the "static_assertions" crate has a const_assert macro that produces worse error messages.
Suggested-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Reviewed-by: Zhao Liu <zhao1.liu@intel.com> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Link: https://lore.kernel.org/r/20250321112523.1774131-2-peter.maydell@linaro.org Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
show more ...
|
094cd359 | 13-Dec-2024 |
Paolo Bonzini <pbonzini@redhat.com> |
rust: qom: remove operations on &mut
The dubious casts of mutable references to objects are not used anymore: the wrappers for qdev_init_clock_in and for IRQ and MMIO initialization can be called di
rust: qom: remove operations on &mut
The dubious casts of mutable references to objects are not used anymore: the wrappers for qdev_init_clock_in and for IRQ and MMIO initialization can be called directly on the subclasses, without casts, plus they take a shared reference so they can just use "upcast()" instead of "upcast_mut()". Remove them.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
show more ...
|
5778ce99 | 14-Feb-2025 |
Paolo Bonzini <pbonzini@redhat.com> |
rust: cell: add full example of declaring a SysBusDevice
Reviewed-by: Zhao Liu <zhao1.liu@intel.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> |
2d0050cb | 14-Feb-2025 |
Paolo Bonzini <pbonzini@redhat.com> |
rust: chardev: provide basic bindings to character devices
Most of the character device API is pretty simple, with "0 or -errno" or "number of bytes or -errno" as the convention for return codes. Ad
rust: chardev: provide basic bindings to character devices
Most of the character device API is pretty simple, with "0 or -errno" or "number of bytes or -errno" as the convention for return codes. Add safe wrappers for the API to the CharBackend bindgen-generated struct.
The API is not complete, but it covers the parts that are used by the PL011 device, plus qemu_chr_fe_write which is needed to implement the standard library Write trait.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
show more ...
|
2ad011d4 | 14-Feb-2025 |
Paolo Bonzini <pbonzini@redhat.com> |
rust: bindings: remove more unnecessary Send/Sync impls
Send and Sync are now implemented on the opaque wrappers. Remove them from the bindings module, unless the structs are pure data containers a
rust: bindings: remove more unnecessary Send/Sync impls
Send and Sync are now implemented on the opaque wrappers. Remove them from the bindings module, unless the structs are pure data containers and/or have no C functions defined on them.
Reviewed-by: Zhao Liu <zhao1.liu@intel.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
show more ...
|
48627510 | 14-Feb-2025 |
Paolo Bonzini <pbonzini@redhat.com> |
rust: chardev: wrap Chardev with Opaque<>
Reviewed-by: Zhao Liu <zhao1.liu@intel.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> |
af0868cb | 14-Feb-2025 |
Paolo Bonzini <pbonzini@redhat.com> |
rust: memory: wrap MemoryRegion with Opaque<>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> |
f4751c7a | 14-Feb-2025 |
Paolo Bonzini <pbonzini@redhat.com> |
rust: sysbus: wrap SysBusDevice with Opaque<>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> |
09fda8f5 | 25-Feb-2025 |
Paolo Bonzini <pbonzini@redhat.com> |
rust: hpet: do not access fields of SysBusDevice
Fields of SysBusDevice must only be accessed with the BQL taken. Add a wrapper that verifies that.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.co
rust: hpet: do not access fields of SysBusDevice
Fields of SysBusDevice must only be accessed with the BQL taken. Add a wrapper that verifies that.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
show more ...
|
fc22d650 | 14-Feb-2025 |
Paolo Bonzini <pbonzini@redhat.com> |
rust: qdev: wrap Clock and DeviceState with Opaque<>
Reviewed-by: Zhao Liu <zhao1.liu@intel.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> |
7fb4a99d | 14-Feb-2025 |
Paolo Bonzini <pbonzini@redhat.com> |
rust: qom: wrap Object with Opaque<>
Reviewed-by: Zhao Liu <zhao1.liu@intel.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> |
9c9a6a88 | 14-Feb-2025 |
Paolo Bonzini <pbonzini@redhat.com> |
rust: irq: wrap IRQState with Opaque<>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> |
a32b2396 | 14-Feb-2025 |
Paolo Bonzini <pbonzini@redhat.com> |
rust: timer: wrap QEMUTimer with Opaque<> and express pinning requirements
Timers must be pinned in memory, because modify() stores a pointer to them in the TimerList. To express this requirement,
rust: timer: wrap QEMUTimer with Opaque<> and express pinning requirements
Timers must be pinned in memory, because modify() stores a pointer to them in the TimerList. To express this requirement, change init_full() to take a pinned reference. Because the only way to obtain a Timer is through Timer::new(), which is unsafe, modify() can assume that the timer it got was later initialized; and because the initialization takes a Pin<&mut Timer> modify() can assume that the timer is pinned. In the future the pinning requirement will be expressed through the pin_init crate instead.
Note that Timer is a bit different from other users of Opaque, in that it is created in Rust code rather than C code. This is why it has to use the unsafe constructors provided by Opaque; and in fact Timer::new() is also unsafe, because it leaves it to the caller to invoke init_full() before modify(). Without a call to init_full(), modify() will cause a NULL pointer dereference.
An alternative could be to combine new() + init_full() by returning a pinned box; however, using a reference makes it easier to express the requirement that the opaque outlives the timer.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
show more ...
|
d7f5ae8b | 25-Feb-2025 |
Paolo Bonzini <pbonzini@redhat.com> |
rust: vmstate: add std::pin::Pin as transparent wrapper
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> |
f07a5674 | 14-Feb-2025 |
Paolo Bonzini <pbonzini@redhat.com> |
rust: qemu_api_macros: add Wrapper derive macro
Add a derive macro that makes it easy to peel off all the layers of specialness (UnsafeCell, MaybeUninit, etc.) and just get a pointer to the wrapped
rust: qemu_api_macros: add Wrapper derive macro
Add a derive macro that makes it easy to peel off all the layers of specialness (UnsafeCell, MaybeUninit, etc.) and just get a pointer to the wrapped type; and likewise add them back starting from a *mut.
Reviewed-by: Zhao Liu <zhao1.liu@intel.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
show more ...
|
0b9d05e3 | 14-Feb-2025 |
Paolo Bonzini <pbonzini@redhat.com> |
rust: cell: add wrapper for FFI types
Inspired by the same-named type in Linux. This type provides the compiler with a correct view of what goes on with FFI types. In addition, it separates the gl
rust: cell: add wrapper for FFI types
Inspired by the same-named type in Linux. This type provides the compiler with a correct view of what goes on with FFI types. In addition, it separates the glue code from the bindgen-generated code, allowing traits such as Send, Sync or Zeroable to be specified independently for C and Rust structs.
Reviewed-by: Zhao Liu <zhao1.liu@intel.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
show more ...
|
d556226d | 13-Feb-2025 |
Paolo Bonzini <pbonzini@redhat.com> |
rust: qom: get rid of ClassInitImpl
Complete the conversion from the ClassInitImpl trait to class_init() methods. This will provide more freedom to split the qemu_api crate in separate parts.
Revie
rust: qom: get rid of ClassInitImpl
Complete the conversion from the ClassInitImpl trait to class_init() methods. This will provide more freedom to split the qemu_api crate in separate parts.
Reviewed-by: Zhao Liu <zhao1.liu@intel.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
show more ...
|
4551f342 | 12-Feb-2025 |
Paolo Bonzini <pbonzini@redhat.com> |
rust: qom: add ObjectImpl::CLASS_INIT
As shown in the PL011 device, the orphan rules required a manual implementation of ClassInitImpl for anything not in the qemu_api crate; this gets in the way of
rust: qom: add ObjectImpl::CLASS_INIT
As shown in the PL011 device, the orphan rules required a manual implementation of ClassInitImpl for anything not in the qemu_api crate; this gets in the way of moving system emulation-specific code (including DeviceClass, which as a blanket ClassInitImpl<DeviceClass> implementation) into its own crate.
Make ClassInitImpl optional, at the cost of having to specify the CLASS_INIT member by hand in every implementation of ObjectImpl. The next commits will get rid of it, replacing all the "impl<T> ClassInitImpl<Class> for T" blocks with a generic class_init<T> method on Class.
Right now the definition is always the same, but do not provide a default as that will not be true once ClassInitImpl goes away.
Reviewed-by: Zhao Liu <zhao1.liu@intel.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
show more ...
|