ab810022 | 15-Jun-2025 |
Bernhard Beschow <shentey@gmail.com> |
rust/qemu-api: Add initial logging support based on C API
A log_mask_ln!() macro is provided which expects similar arguments as the C version. However, the formatting works as one would expect from
rust/qemu-api: Add initial logging support based on C API
A log_mask_ln!() macro is provided which expects similar arguments as the C version. However, the formatting works as one would expect from Rust.
To maximize code reuse the macro is just a thin wrapper around qemu_log(). Also, just the bare minimum of logging masks is provided which should suffice for the current use case of Rust in QEMU.
Signed-off-by: Bernhard Beschow <shentey@gmail.com> Link: https://lore.kernel.org/r/20250615112037.11992-2-shentey@gmail.com Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
show more ...
|
345bef46 | 04-Mar-2025 |
Paolo Bonzini <pbonzini@redhat.com> |
rust: qom: change instance_init to take a ParentInit<>
This removes undefined behavior associated to writing to uninitialized fields, and makes it possible to remove "unsafe" from the instance_init
rust: qom: change instance_init to take a ParentInit<>
This removes undefined behavior associated to writing to uninitialized fields, and makes it possible to remove "unsafe" from the instance_init implementation.
However, the init function itself is still unsafe, because it must promise (as a sort as MaybeUninit::assume_init) that all fields have been initialized.
Reviewed-by: Zhao Liu <zhao1.liu@intel.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
show more ...
|
8d394f6c | 28-Feb-2025 |
Paolo Bonzini <pbonzini@redhat.com> |
rust: qom: make ParentInit lifetime-invariant
This is the trick that allows the parent-field initializer to be used only for the object that it's meant to be initialized. This way, the owner of a M
rust: qom: make ParentInit lifetime-invariant
This is the trick that allows the parent-field initializer to be used only for the object that it's meant to be initialized. This way, the owner of a MemoryRegion must be the object that embeds it.
More information is in the comments; it's best explained with a simplified example.
Reviewed-by: Zhao Liu <zhao1.liu@intel.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
show more ...
|
a4412225 | 28-Feb-2025 |
Paolo Bonzini <pbonzini@redhat.com> |
rust: qom: introduce ParentInit
This is a smart pointer for MaybeUninit; it can be upcasted to the already-initialized parent classes, or dereferenced to a MaybeUninit for the class that is being in
rust: qom: introduce ParentInit
This is a smart pointer for MaybeUninit; it can be upcasted to the already-initialized parent classes, or dereferenced to a MaybeUninit for the class that is being initialized.
Reviewed-by: Zhao Liu <zhao1.liu@intel.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
show more ...
|
b4ff3cf3 | 03-Jun-2025 |
Paolo Bonzini <pbonzini@redhat.com> |
rust: qemu-api: add bindings to Error
Provide an implementation of std::error::Error that bridges the Rust anyhow::Error and std::panic::Location types with QEMU's Error*.
It also has several utili
rust: qemu-api: add bindings to Error
Provide an implementation of std::error::Error that bridges the Rust anyhow::Error and std::panic::Location types with QEMU's Error*.
It also has several utility methods, analogous to error_propagate(), that convert a Result into a return value + Error** pair. One important difference is that these propagation methods *panic* if *errp is NULL, unlike error_propagate() which eats subsequent errors[1]. The reason for this is that in C you have an error_set*() call at the site where the error is created, and calls to error_propagate() are relatively rare.
In Rust instead, even though these functions do "propagate" a qemu_api::Error into a C Error**, there is no error_setg() anywhere that could check for non-NULL errp and call abort(). error_propagate()'s behavior of ignoring subsequent errors is generally considered weird, and there would be a bigger risk of triggering it from Rust code.
[1] This is actually a violation of the preconditions of error_propagate(), so it should not happen. But you never know...
Reviewed-by: Zhao Liu <zhao1.liu@intel.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
show more ...
|
aef5ac86 | 20-May-2025 |
Zhao Liu <zhao1.liu@intel.com> |
rust: Fix the typos in doc
These typos are found by "cargo spellcheck". Though it outputs a lot of noise and false positives, there still are some real typos.
Signed-off-by: Zhao Liu <zhao1.liu@int
rust: Fix the typos in doc
These typos are found by "cargo spellcheck". Though it outputs a lot of noise and false positives, there still are some real typos.
Signed-off-by: Zhao Liu <zhao1.liu@intel.com> Link: https://lore.kernel.org/r/20250520152750.2542612-6-zhao1.liu@intel.com Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
show more ...
|
3a1c694d | 02-May-2025 |
Paolo Bonzini <pbonzini@redhat.com> |
rust: qom: fix TODO about zeroability of classes
The proposed suggestion is not correct. First it is not necessary for *all* classes to be Zeroable, only for Rust-defined ones; classes defined in C
rust: qom: fix TODO about zeroability of classes
The proposed suggestion is not correct. First it is not necessary for *all* classes to be Zeroable, only for Rust-defined ones; classes defined in C never implement ObjectImpl.
Second, the parent class field need not be Zeroable. For example, ChardevClass's chr_write and chr_be_event fields cannot be NULL, therefore ChardevClass cannot be Zeroable. However, char_class_init() initializes them, therefore ChardevClass could be subclassed by Rust code.
Reviewed-by: Manos Pitsidianakis <manos.pitsidianakis@linaro.org> Reviewed-by: Zhao Liu <zhao1.liu@intel.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
show more ...
|
8d9502b4 | 14-Apr-2025 |
Zhao Liu <zhao1.liu@intel.com> |
rust/timer: Define NANOSECONDS_PER_SECOND binding as u64
NANOSECONDS_PER_SECOND is often used in operations with get_ns(), which currently returns a u64.
Therefore, define a new NANOSECONDS_PER_SEC
rust/timer: Define NANOSECONDS_PER_SECOND binding as u64
NANOSECONDS_PER_SECOND is often used in operations with get_ns(), which currently returns a u64.
Therefore, define a new NANOSECONDS_PER_SECOND binding is with u64 type to eliminate unnecessary type conversions (from u32 to u64).
Signed-off-by: Zhao Liu <zhao1.liu@intel.com> Link: https://lore.kernel.org/r/20250414144943.1112885-6-zhao1.liu@intel.com Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
show more ...
|
fff99a88 | 02-May-2025 |
Paolo Bonzini <pbonzini@redhat.com> |
rust: assertions: Support index field wrapped in BqlCell
Currently, if the `num` field of a varray is not a numeric type, such as being placed in a wrapper, the array variant of assert_field_type wi
rust: assertions: Support index field wrapped in BqlCell
Currently, if the `num` field of a varray is not a numeric type, such as being placed in a wrapper, the array variant of assert_field_type will fail the check.
HPET currently wraps num_timers in BqlCell<>. Although BqlCell<> is not necessary from strictly speaking, it makes sense for vmstate to respect BqlCell.
The failure of assert_field_type is because it cannot convert BqlCell<T> into usize for use as the index. Use a constant 0 instead for the index, by avoiding $(...)? and extracting the common parts of assert_field_type! into an internal case.
Commit message based on a patch by Zhao Liu <zhao1.liu@intel.com>.
Link: https://lore.kernel.org/r/20250414144943.1112885-3-zhao1.liu@intel.com Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
show more ...
|
756ea88f | 02-May-2025 |
Paolo Bonzini <pbonzini@redhat.com> |
vmstate: support varray for vmstate_clock!
Make vmstate_struct and vmstate_clock more similar; they are basically the same thing, except for the clock case having a built-in VMStateDescription.
Sig
vmstate: support varray for vmstate_clock!
Make vmstate_struct and vmstate_clock more similar; they are basically the same thing, except for the clock case having a built-in VMStateDescription.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
show more ...
|