QEMU/KVM Community Call (29/10/24) agenda items?

QEMU/KVM Community Call (29/10/24) agenda items?

[Alex Bennée]

Hi,

After a missing a few weeks due to travel and conferences the KVM/QEMU
community call is at:

https://meet.jit.si/kvmcallmeeting
@
29/10/2024 14:00 UTC

Are there any agenda items for the sync-up?

-- 
Alex Bennée
Virtualisation Tech Lead @ Linaro

Re: QEMU/KVM Community Call (29/10/24) agenda items?

[Paolo Bonzini]

On 10/29/24 08:24, Alex Bennée wrote:
> 
> Hi,
> 
> After a missing a few weeks due to travel and conferences the KVM/QEMU
> community call is at:
> 
> https://meet.jit.si/kvmcallmeeting
> @
> 29/10/2024 14:00 UTC
> 
> Are there any agenda items for the sync-up?

I would like to discuss the next steps for Rust bindings, but probably 
it's already too late to have a call today; we can have the discussion 
on the mailing list as well.

In particular I would like to understand:

- if it's desirable to have 
https://lore.kernel.org/qemu-devel/1d6034ef-9e41-4ef4-9a95-d03885b09b2b@redhat.com/ 
in QEMU 9.2.

- if we agree on (the plan of) bringing the Rust PL011 to feature 
completion in 10.0 and at the same time toggling the --enable-rust 
default from "disabled" to "auto"

I would also like to reach an agreement on how Rust patches enter 
qemu.git (that is, whether via my tree or a new one).

Paolo

Re: QEMU/KVM Community Call (29/10/24) agenda items?

[Alex Bennée]

Paolo Bonzini <pbonzini@redhat.com> writes:

> On 10/29/24 08:24, Alex Bennée wrote:
>> Hi,
>> After a missing a few weeks due to travel and conferences the
>> KVM/QEMU
>> community call is at:
>> https://meet.jit.si/kvmcallmeeting
>> @
>> 29/10/2024 14:00 UTC
>> Are there any agenda items for the sync-up?
>
> I would like to discuss the next steps for Rust bindings, but probably
> it's already too late to have a call today; we can have the discussion
> on the mailing list as well.

I was wondering if you'd been hit by the daylight saving shift ;-)

>
> In particular I would like to understand:
>
> - if it's desirable to have
>   https://lore.kernel.org/qemu-devel/1d6034ef-9e41-4ef4-9a95-d03885b09b2b@redhat.com/
>   in QEMU 9.2.

I shall have a look.

>
> - if we agree on (the plan of) bringing the Rust PL011 to feature
>   completion in 10.0 and at the same time toggling the --enable-rust
>   default from "disabled" to "auto"
>
> I would also like to reach an agreement on how Rust patches enter
> qemu.git (that is, whether via my tree or a new one).

Good idea. We can discuss on list and then review in 2 weeks at the next
sync meeting?

>
> Paolo

-- 
Alex Bennée
Virtualisation Tech Lead @ Linaro

Re: QEMU/KVM Community Call (29/10/24) agenda items?

[Mark Burton]

This is top of my list to discuss too….

Cheers
Mark.


> On 29 Oct 2024, at 14:44, Alex Bennée <alex.bennee@linaro.org> wrote:
> 
> WARNING: This email originated from outside of Qualcomm. Please be wary of any links or attachments, and do not enable macros.
> 
> Paolo Bonzini <pbonzini@redhat.com> writes:
> 
>> On 10/29/24 08:24, Alex Bennée wrote:
>>> Hi,
>>> After a missing a few weeks due to travel and conferences the
>>> KVM/QEMU
>>> community call is at:
>>> https://meet.jit.si/kvmcallmeeting
>>> @
>>> 29/10/2024 14:00 UTC
>>> Are there any agenda items for the sync-up?
>> 
>> I would like to discuss the next steps for Rust bindings, but probably
>> it's already too late to have a call today; we can have the discussion
>> on the mailing list as well.
> 
> I was wondering if you'd been hit by the daylight saving shift ;-)
> 
>> 
>> In particular I would like to understand:
>> 
>> - if it's desirable to have
>>  https://lore.kernel.org/qemu-devel/1d6034ef-9e41-4ef4-9a95-d03885b09b2b@redhat.com/
>>  in QEMU 9.2.
> 
> I shall have a look.
> 
>> 
>> - if we agree on (the plan of) bringing the Rust PL011 to feature
>>  completion in 10.0 and at the same time toggling the --enable-rust
>>  default from "disabled" to "auto"
>> 
>> I would also like to reach an agreement on how Rust patches enter
>> qemu.git (that is, whether via my tree or a new one).
> 
> Good idea. We can discuss on list and then review in 2 weeks at the next
> sync meeting?
> 
>> 
>> Paolo
> 
> --
> Alex Bennée
> Virtualisation Tech Lead @ Linaro

Re: QEMU/KVM Community Call (29/10/24) agenda items?

[Paolo Bonzini]

On 10/29/24 14:44, Alex Bennée wrote:
>> In particular I would like to understand:
>>
>> - if it's desirable to have
>>    https://lore.kernel.org/qemu-devel/1d6034ef-9e41-4ef4-9a95-d03885b09b2b@redhat.com/
>>    in QEMU 9.2.
> 
> I shall have a look.

Thanks!

>>
>> - if we agree on (the plan of) bringing the Rust PL011 to feature
>>    completion in 10.0 and at the same time toggling the --enable-rust
>>    default from "disabled" to "auto"
>>
>> I would also like to reach an agreement on how Rust patches enter
>> qemu.git (that is, whether via my tree or a new one).
> 
> Good idea. We can discuss on list and then review in 2 weeks at the next
> sync meeting?
Ok, in the meanwhile I'll keep on handling Rust patches for 9.2.

Paolo

Re: QEMU/KVM Community Call (29/10/24) agenda items?

[Daniel P. Berrangé]

On Tue, Oct 29, 2024 at 02:05:44PM +0100, Paolo Bonzini wrote:
> I would like to discuss the next steps for Rust bindings, but probably it's
> already too late to have a call today; we can have the discussion on the
> mailing list as well.
> 
> In particular I would like to understand:
> 
> - if it's desirable to have https://lore.kernel.org/qemu-devel/1d6034ef-9e41-4ef4-9a95-d03885b09b2b@redhat.com/
> in QEMU 9.2.
> 
> - if we agree on (the plan of) bringing the Rust PL011 to feature completion
> in 10.0 and at the same time toggling the --enable-rust default from
> "disabled" to "auto"

That sounds like reasonable goal. If PL011 work slips, then we just
punt the enable-rust default change to 10.1.

> I would also like to reach an agreement on how Rust patches enter qemu.git
> (that is, whether via my tree or a new one).

IIUC, we decided we ought to have a rust mailing list for QEMU, such that
Rust patches would be cc'd on qemu-devel & qemu-rust. Along with that it
probably makes sense to have a designated "rust staging" tree that people
can base their work against.

Initially I presume "rust staging" would be for all Rust related work to
flow through. At a later date, then we can devolve maintainership back
to the respective subsystem maintainers, and have "rust staging" solely
be for core rust infrastructure patches.

With regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|