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

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

[Alex Bennée]

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.

Are there any other agenda items for the sync-up?

-- 
Alex Bennée
Virtualisation Tech Lead @ Linaro

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

[Alex Bennée]

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

-- 
Alex Bennée
Virtualisation Tech Lead @ Linaro

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

[Philippe Mathieu-Daudé]

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.

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

[Peter Maydell]

On Tue, 18 Feb 2025 at 16:42, Philippe Mathieu-Daudé <philmd@linaro.org> wrote:
> - 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.

Mmm, I vaguely recall a discussion in a QEMU Summit a few years
back about this; we've got a mix of embedded-allocation and
the (older style) heap-alloc, but we aren't necessarily
completely wedded to embedded-allocation and for dynamic
machine creation heap-alloc is more natural.

-- PMM