Re: KVM/QEMU community call agenda items for 18/2/25

["Philippe Mathieu-Daudé" <philmd@linaro.org>]

On 18/2/25 16:52, Alex Bennée wrote:
> Alex Bennée <alex.bennee@linaro.org> writes:
> 
>> Hi,
>>
>> The KVM/QEMU community call is at:
>>
>> https://meet.jit.si/kvmcallmeeting
>> @
>> 18/02/2025 14:00 UTC
>>
>> Paolo is going to give another rust update along with an overview of
>> how a rust backend goes together.
> 
> You can view/download the video from:
> https://fileserver.linaro.org/s/zQzSmd92ecaT5dN

My notes and few questions for Paolo:

- w.r.t. endianness API, this form seems more natural to my
   C background:

     let hval: address_space_memory.load::<LE16>(hwaddr);

- w.r.t. VMState I understand we'll have machines with a mix of C
   and Rust device model implementations, so we'll have to stick to
   the C migration serialization, and can't take benefit of Rust one.

- Can the Fifo implementation in rust/hw/char/pl011/src/device.rs
   be extracted as "qemu/fifo32.h"?

- Can we remove native_endian() from rust/qemu-api/src/memory.rs,
   as we are trying to get rid of DEVICE_NATIVE_ENDIAN?

- About { embedded / heap allocated } QOM objects: In C developers
   don't want to give away the embedded model, as it offers free
   type checks (while heap-alloc must use runtime checks). IIUC with
   Rust it is the opposite, you mentioned is simpler to get build time
   checks with the heap-alloc version, is that right? (I didn't took
   particular notes about it). I'm interested because for declarative
   dynamic machines modelling, it is simpler to use the heap to allocate
   the objects, and I'd like to promote that more.

- I noticed trace event calls are commented, what is the plan?

Regards,

Phil.