| 9bd7e6f7 | 18-Mar-2025 |
Zhao Liu <zhao1.liu@intel.com> |
rust/vmstate: Add unit test for vmstate_validate
Add a unit test for vmstate_validate, which corresponds to the C version
macro: VMSTATE_VALIDATE.
Signed-off-by: Zhao Liu <zhao1.liu@intel.com>
Link
rust/vmstate: Add unit test for vmstate_validate
Add a unit test for vmstate_validate, which corresponds to the C version
macro: VMSTATE_VALIDATE.
Signed-off-by: Zhao Liu <zhao1.liu@intel.com>
Link: https://lore.kernel.org/r/20250318130219.1799170-15-zhao1.liu@intel.com
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
show more ...
|
| 8df1b001 | 18-Mar-2025 |
Zhao Liu <zhao1.liu@intel.com> |
rust/vmstate: Add unit test for pointer case
Add a unit test to cover some patterns accepted by vmstate_of macro,
which correspond to the following C version macros:
* VMSTATE_POINTER
* VMSTATE_AR
rust/vmstate: Add unit test for pointer case
Add a unit test to cover some patterns accepted by vmstate_of macro,
which correspond to the following C version macros:
* VMSTATE_POINTER
* VMSTATE_ARRAY_OF_POINTER
Note: Currently, vmstate_struct can't handle the pointer to structure
case. Leave this case as a FIXME and use vmstate_unused as a place
holder.
Signed-off-by: Zhao Liu <zhao1.liu@intel.com>
Link: https://lore.kernel.org/r/20250318130219.1799170-14-zhao1.liu@intel.com
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
show more ...
|
| 57c327f3 | 18-Mar-2025 |
Zhao Liu <zhao1.liu@intel.com> |
rust/vmstate: Add unit test for vmstate_{of|struct} macro
Add a unit test to cover some patterns accepted by vmstate_of and
vmstate_struct macros, which correspond to the following C version
macros:
rust/vmstate: Add unit test for vmstate_{of|struct} macro
Add a unit test to cover some patterns accepted by vmstate_of and
vmstate_struct macros, which correspond to the following C version
macros:
* VMSTATE_BOOL_V
* VMSTATE_U64
* VMSTATE_STRUCT_VARRAY_UINT8
* (no C version) MULTIPLY variant of VMSTATE_STRUCT_VARRAY_UINT32
* VMSTATE_ARRAY
Signed-off-by: Zhao Liu <zhao1.liu@intel.com>
Link: https://lore.kernel.org/r/20250318130219.1799170-13-zhao1.liu@intel.com
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
show more ...
|
| 567c0c41 | 13-Feb-2025 |
Paolo Bonzini <pbonzini@redhat.com> |
rust: pl011, qemu_api tests: do not use ClassInitImpl
Outside the qemu_api crate, orphan rules make the usage of ClassInitImpl
unwieldy. Now that it is optional, do not use it.
For PL011Class, thi
rust: pl011, qemu_api tests: do not use ClassInitImpl
Outside the qemu_api crate, orphan rules make the usage of ClassInitImpl
unwieldy. Now that it is optional, do not use it.
For PL011Class, this makes it easier to provide a PL011Impl trait similar
to the ones in the qemu_api crate. The device id consts are moved there.
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 ...
|
| ba3b81f3 | 05-Nov-2024 |
Paolo Bonzini <pbonzini@redhat.com> |
rust: qom: add initial subset of methods on Object
Add an example of implementing instance methods and converting the
result back to a Rust type. In this case the returned types are a
string (actua
rust: qom: add initial subset of methods on Object
Add an example of implementing instance methods and converting the
result back to a Rust type. In this case the returned types are a
string (actually a Cow<str>; but that's transparent as long as it derefs
to &str) and a QOM class.
Reviewed-by: Zhao Liu <zhao1.liu@intel.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
show more ...
|
| f50cd85c | 19-Dec-2024 |
Paolo Bonzini <pbonzini@redhat.com> |
rust: qom: add casting functionality
Add traits that let client cast typecast safely between object types.
In particular, an upcast is compile-time guaranteed to succeed, and a
YOLO C-style downcast
rust: qom: add casting functionality
Add traits that let client cast typecast safely between object types.
In particular, an upcast is compile-time guaranteed to succeed, and a
YOLO C-style downcast must be marked as unsafe.
The traits are based on an IsA<> trait that declares what
is a subclass of what, which is an idea taken from glib-rs
(https://docs.rs/glib/latest/glib/object/trait.IsA.html).
The four primitives are also taken from there
(https://docs.rs/glib/latest/glib/object/trait.Cast.html). However,
the implementation of casting itself is a bit different and uses the
Deref trait.
This removes some pointer arithmetic from the pl011 device; it is also a
prerequisite for the definition of methods, so that they can be invoked
on all subclass structs. This will use the IsA<> trait to detect the
structs that support the methods.
glib also has a "monadic" casting trait which could be implemented on
Option (as in https://docs.rs/glib/latest/glib/object/trait.CastNone.html)
and perhaps even Result. For now I'm leaving it out, as the patch is
already big enough and the benefit seems debatable.
Reviewed-by: Zhao Liu <zhao1.liu@intel.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
show more ...
|
| 716d89f9 | 31-Oct-2024 |
Paolo Bonzini <pbonzini@redhat.com> |
rust: re-export C types from qemu-api submodules
Long term we do not want device code to use "bindings" at all, so make it
possible to get the relevant types from the other modules of qemu-api.
Rev
rust: re-export C types from qemu-api submodules
Long term we do not want device code to use "bindings" at all, so make it
possible to get the relevant types from the other modules of qemu-api.
Reviewed-by: Zhao Liu <zhao1.liu@intel.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
show more ...
|