rust/hw/char/pl011: Extract extract DR read logic into separate function

- Split `read()` DR case into `read_data_register()`

Signed-off-by: Rakesh Jeyasingh <rakeshjb010@gmail.com>
Link: https://l

rust/hw/char/pl011: Extract extract DR read logic into separate function

- Split `read()` DR case into `read_data_register()`

Signed-off-by: Rakesh Jeyasingh <rakeshjb010@gmail.com>
Link: https://lore.kernel.org/r/20250407181327.171563-2-rakeshjb010@gmail.com
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>

show more ...

rust/hpet: Fix a clippy error

Carge clippy complained about:

error: casts from `u8` to `u32` can be expressed infallibly using `From`

So use `From` to convert `u8` to `u32`.

Signed-off-by: Zhao L

rust/hpet: Fix a clippy error

Carge clippy complained about:

error: casts from `u8` to `u32` can be expressed infallibly using `From`

So use `From` to convert `u8` to `u32`.

Signed-off-by: Zhao Liu <zhao1.liu@intel.com>
Link: https://lore.kernel.org/r/20250414144943.1112885-10-zhao1.liu@intel.com
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>

show more ...

rust/hpet: convert HPETTimer index to u8 type

The C version of HPET uses the uint8_t type for timer index ("tn"), and
usize type in Rust version will break migration between the C and Rust
versions.

rust/hpet: convert HPETTimer index to u8 type

The C version of HPET uses the uint8_t type for timer index ("tn"), and
usize type in Rust version will break migration between the C and Rust
versions.

So convert HPETTimer index' type to u8 (consistent with the C version of
HPET) to make it friendly for vmstate support.

Signed-off-by: Zhao Liu <zhao1.liu@intel.com>
Link: https://lore.kernel.org/r/20250414144943.1112885-8-zhao1.liu@intel.com
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>

show more ...

rust/hpet: convert num_timers to u8 type

The C version of HPET uses the uint8_t type for num_timers, and usize
type in Rust version will break migration between the C and Rust
versions.

So convert

rust/hpet: convert num_timers to u8 type

The C version of HPET uses the uint8_t type for num_timers, and usize
type in Rust version will break migration between the C and Rust
versions.

So convert num_timers' type to u8 (consistent with the C version of
HPET) to make it friendly for vmstate support.

Note the commit 7bda68e8e2b0 ("qdev, rust/hpet: fix type of HPET
'timers property") supports the usize type property, but the uint8
property has to be re-supported now.

Signed-off-by: Zhao Liu <zhao1.liu@intel.com>
Link: https://lore.kernel.org/r/20250414144943.1112885-7-zhao1.liu@intel.com
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>

show more ...

rust: hpet: fix decoding of timer registers

Due to a missing "& 0x18", timer registers are not decoded correctly.
This breaks the tests/functional/test_x86_64_tuxrun.py functional
test.

Fixes: 5190

rust: hpet: fix decoding of timer registers

Due to a missing "& 0x18", timer registers are not decoded correctly.
This breaks the tests/functional/test_x86_64_tuxrun.py functional
test.

Fixes: 519088b7cf6 ("rust: hpet: decode HPET registers into enums", 2025-03-06)
Reported-by: Peter Maydell <peter.maydell@linaro.org>
Tested-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>

show more ...

rust/vmstate: Include complete crate path of VMStateFlags in vmstate_clock

The use of "bindings::*" masks incomplete path of VMStateFlags.

Include complete crate path of VMStateFlags in vmstate_clo

rust/vmstate: Include complete crate path of VMStateFlags in vmstate_clock

The use of "bindings::*" masks incomplete path of VMStateFlags.

Include complete crate path of VMStateFlags in vmstate_clock, and clean
up "bindings::*" in device_class.rs of pl011.

Signed-off-by: Zhao Liu <zhao1.liu@intel.com>
Link: https://lore.kernel.org/r/20250318130219.1799170-16-zhao1.liu@intel.com
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>

show more ...

rust: pl011: Check size of state struct at compile time

The PL011 device's C implementation exposes its PL011State struct to
users of the device, and one common usage pattern is to embed that
struct

rust: pl011: Check size of state struct at compile time

The PL011 device's C implementation exposes its PL011State struct to
users of the device, and one common usage pattern is to embed that
struct into the user's own state struct. (The internals of the
struct are technically visible to the C user of the device, but in
practice are treated as implementation details.)

This means that the Rust version of the state struct must not be
larger than the C version's struct; otherwise it will trip a runtime
assertion in object_initialize_type() when the C user attempts to
in-place initialize the type.

Add a compile-time assertion on the Rust side, so that if we
accidentally make the Rust device state larger we know immediately
that we need to expand the padding in the C version of the struct.

Reviewed-by: Zhao Liu <zhao1.liu@intel.com>
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Link: https://lore.kernel.org/r/20250321112523.1774131-4-peter.maydell@linaro.org
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>

show more ...

qdev, rust/hpet: fix type of HPET "timers" property

Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>

rust: Kconfig: Factor out whether HPET is Rust or C

Currently we require everywhere that wants to know if there
is an HPET device to check for "CONFIG_HPET || CONFIG_X_HPET_RUST".
Factor out whether

rust: Kconfig: Factor out whether HPET is Rust or C

Currently we require everywhere that wants to know if there
is an HPET device to check for "CONFIG_HPET || CONFIG_X_HPET_RUST".
Factor out whether the HPET device is Rust or C into a separate
Kconfig stanza, so that CONFIG_HPET means "there is an HPET",
and whether this has pulled in CONFIG_X_HPET_RUST or CONFIG_HPET_C
is something the rest of QEMU can ignore.

Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Link: https://lore.kernel.org/r/20250319193110.1565578-3-peter.maydell@linaro.org
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>

show more ...

rust: pl011: Allow NULL chardev argument to pl011_create()

It's valid for the caller to pass a NULL chardev to pl011_create();
this means "don't set the chardev property on the device", which
in tur

rust: pl011: Allow NULL chardev argument to pl011_create()

It's valid for the caller to pass a NULL chardev to pl011_create();
this means "don't set the chardev property on the device", which
in turn means "act like there's no chardev". All the chardev
frontend APIs (in C, at least) accept a NULL pointer to mean
"do nothing".

This fixes some failures in 'make check-functional' when Rust support
is enabled.

Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Link: https://lore.kernel.org/r/20250307190051.3274226-1-peter.maydell@linaro.org
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>

show more ...

rust: hpet: decode HPET registers into enums

Generalize timer_and_addr() to decode all registers into a single enum
HPETRegister, and use the TryInto derive to separate valid and
invalid values.

Th

rust: hpet: decode HPET registers into enums

Generalize timer_and_addr() to decode all registers into a single enum
HPETRegister, and use the TryInto derive to separate valid and
invalid values.

The main advantage lies in checking that all registers are enumerated
in the "match" statements.

Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>

show more ...

rust: pl011: pass around registers::Data

The values stored in the Fifo are instances of the bitfield-struct
registers::Data. Convert as soon as possible the value written
into DR, and always refer

rust: pl011: pass around registers::Data

The values stored in the Fifo are instances of the bitfield-struct
registers::Data. Convert as soon as possible the value written
into DR, and always refer to the bitfield struct; it's generally
cleaner other than PL011State::receive having to do a double
conversion u8=>u32=>registers::Data.

Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>

show more ...

rust: pl011: switch to safe chardev operation

Switch bindings::CharBackend with chardev::CharBackend. This removes
occurrences of "unsafe" due to FFI and switches the wrappers for receive,
can_rece

rust: pl011: switch to safe chardev operation

Switch bindings::CharBackend with chardev::CharBackend. This removes
occurrences of "unsafe" due to FFI and switches the wrappers for receive,
can_receive and event callbacks to the common ones implemented by
chardev::CharBackend.

Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>

show more ...

rust: pl011: clean up visibilities of callbacks

Do not make callbacks unnecessarily "pub", they are only used
through function pointers.

Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>

rust: pl011: move register definitions out of lib.rs

Signed-off-by: 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 ...

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 ...

rust: hpet: embed Timer without the Option and Box indirection

This simplifies things for migration, since Option<Box<QEMUTimer>> does not
implement VMState.

This also shows a soundness issue becau

rust: hpet: embed Timer without the Option and Box indirection

This simplifies things for migration, since Option<Box<QEMUTimer>> does not
implement VMState.

This also shows a soundness issue because Timer::new() will leave a NULL
timer list pointer, which can then be dereferenced by Timer::modify(). It
will be fixed shortly.

Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>

show more ...

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 ...

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 ...

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 ...

rust: add SysBusDeviceImpl

The only function, right now, is to ensure that anything with a
SysBusDeviceClass class is a SysBusDevice.

Reviewed-by: Zhao Liu <zhao1.liu@intel.com>
Signed-off-by: Paol

rust: add SysBusDeviceImpl

The only function, right now, is to ensure that anything with a
SysBusDeviceClass class is a SysBusDevice.

Reviewed-by: Zhao Liu <zhao1.liu@intel.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>

show more ...

rust: prefer importing std::ptr over core::ptr

The std::ptr is same as core::ptr, but std has already been used in many
cases and there's no need to choose non-std library.

So, use std::ptr directl

rust: prefer importing std::ptr over core::ptr

The std::ptr is same as core::ptr, but std has already been used in many
cases and there's no need to choose non-std library.

So, use std::ptr directly to make the used ptr library as consistent as
possible.

Signed-off-by: Zhao Liu <zhao1.liu@intel.com>
Link: https://lore.kernel.org/r/20250218080835.3341082-1-zhao1.liu@intel.com
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>

show more ...

i386: Fix the missing Rust HPET configuration option

The configuration option of Rust HPET is missing, so that PC machine
can't boot with "hpet=on" when QEMU Rust support is enabled.

Add the Rust H

i386: Fix the missing Rust HPET configuration option

The configuration option of Rust HPET is missing, so that PC machine
can't boot with "hpet=on" when QEMU Rust support is enabled.

Add the Rust HPET configuration option.

Fixes: d128c341a744 ("i386: enable rust hpet for pc when rust is enabled")
Signed-off-by: Zhao Liu <zhao1.liu@intel.com>
Link: https://lore.kernel.org/r/20250217154416.3144571-1-zhao1.liu@intel.com
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>

show more ...

i386: enable rust hpet for pc when rust is enabled

Add HPET configuration in PC's Kconfig options, and select HPET device
(Rust version) if Rust is supported.

Signed-off-by: Zhao Liu <zhao1.liu@int

i386: enable rust hpet for pc when rust is enabled

Add HPET configuration in PC's Kconfig options, and select HPET device
(Rust version) if Rust is supported.

Signed-off-by: Zhao Liu <zhao1.liu@intel.com>
Link: https://lore.kernel.org/r/20250210030051.2562726-11-zhao1.liu@intel.com
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>

show more ...