KVM call minutes for 2022-01-25

KVM call minutes for 2022-01-25

[Juan Quintela]

Hi

Today we have the KVM devel call.  We discussed how to create machines
from QMP without needing to recompile QEMU.


Three different problems:
- startup QMP (*)
  not discussed today
- one binary or two
  not discussed today
- being able to create machines dynamically.
  everybody agrees that we want this. Problem is how.
- current greensocs approach
- interested for all architectures, they need a couple of them

what greensocs have:
- python program that is able to read a blob that have a device tree from the blob
- basically the machine type is empty and is configured from there
- 100 machines around 400 devices models
- Need to do the configuration before the machine construction happens
- different hotplug/coldplug
- How to describe devices that have multiple connections

As the discussion is quite complicated, here is the recording of it.

Later, Juan.


https://redhat.bluejeans.com/m/TFyaUsLqt3T/?share=True

*: We will talk about this on the next call

Re: KVM call minutes for 2022-01-25

[Juan Quintela]

Juan Quintela <quintela@redhat.com> wrote:
> Hi
>
> Today we have the KVM devel call.  We discussed how to create machines
> from QMP without needing to recompile QEMU.
>
>
> Three different problems:
> - startup QMP (*)
>   not discussed today
> - one binary or two
>   not discussed today
> - being able to create machines dynamically.
>   everybody agrees that we want this. Problem is how.
> - current greensocs approach
> - interested for all architectures, they need a couple of them
>
> what greensocs have:
> - python program that is able to read a blob that have a device tree from the blob
> - basically the machine type is empty and is configured from there
> - 100 machines around 400 devices models
> - Need to do the configuration before the machine construction happens
> - different hotplug/coldplug
> - How to describe devices that have multiple connections
>
> As the discussion is quite complicated, here is the recording of it.
>
> Later, Juan.
>
>
> https://redhat.bluejeans.com/m/TFyaUsLqt3T/?share=True

And now the link that works without a login.

https://bluejeans.com/s/KetOlwoxLa3

Later, Juan.

Re: KVM call minutes for 2022-01-25

[Markus Armbruster]

Juan Quintela <quintela@redhat.com> writes:

> Juan Quintela <quintela@redhat.com> wrote:
>> Hi
>>
>> Today we have the KVM devel call.  We discussed how to create machines
>> from QMP without needing to recompile QEMU.
>>
>>
>> Three different problems:
>> - startup QMP (*)
>>   not discussed today
>> - one binary or two
>>   not discussed today
>> - being able to create machines dynamically.
>>   everybody agrees that we want this. Problem is how.
>> - current greensocs approach
>> - interested for all architectures, they need a couple of them
>>
>> what greensocs have:
>> - python program that is able to read a blob that have a device tree from the blob
>> - basically the machine type is empty and is configured from there
>> - 100 machines around 400 devices models
>> - Need to do the configuration before the machine construction happens
>> - different hotplug/coldplug
>> - How to describe devices that have multiple connections

Nice demo, by the way!  I assume you're going to post patches.  Feel
free to post as RFC when the work isn't ready for merge, but could use
review, or could make our discussions more productive.

[...]

Re: KVM call minutes for 2022-01-25

[Philippe Mathieu-Daudé]

On 25/1/22 17:39, Juan Quintela wrote:
> 
> Hi
> 
> Today we have the KVM devel call.  We discussed how to create machines
> from QMP without needing to recompile QEMU.
> 
> 
> Three different problems:
> - startup QMP (*)
>    not discussed today
> - one binary or two
>    not discussed today
> - being able to create machines dynamically.
>    everybody agrees that we want this. Problem is how.
> - current greensocs approach
> - interested for all architectures, they need a couple of them
> 
> what greensocs have:
> - python program that is able to read a blob that have a device tree from the blob
> - basically the machine type is empty and is configured from there
> - 100 machines around 400 devices models
> - Need to do the configuration before the machine construction happens
> - different hotplug/coldplug
> - How to describe devices that have multiple connections

- problem realizing objects that have inter-dependent link properties

Mirela, you mention an issue with TYPE_CPU_CLUSTER / TYPE_CPU, is that
an example of this qom inter-link problem?

> As the discussion is quite complicated, here is the recording of it.
> 
> Later, Juan.
> 
> 
> https://redhat.bluejeans.com/m/TFyaUsLqt3T/?share=True
> 
> *: We will talk about this on the next call
> 
> 

Re: KVM call minutes for 2022-01-25

[Mirela Grujic]

On 1/25/22 5:54 PM, Philippe Mathieu-Daudé wrote:
> On 25/1/22 17:39, Juan Quintela wrote:
>>
>> Hi
>>
>> Today we have the KVM devel call.  We discussed how to create machines
>> from QMP without needing to recompile QEMU.
>>
>>
>> Three different problems:
>> - startup QMP (*)
>>    not discussed today
>> - one binary or two
>>    not discussed today
>> - being able to create machines dynamically.
>>    everybody agrees that we want this. Problem is how.
>> - current greensocs approach
>> - interested for all architectures, they need a couple of them
>>
>> what greensocs have:
>> - python program that is able to read a blob that have a device tree 
>> from the blob
>> - basically the machine type is empty and is configured from there
>> - 100 machines around 400 devices models
>> - Need to do the configuration before the machine construction happens
>> - different hotplug/coldplug
>> - How to describe devices that have multiple connections
>
> - problem realizing objects that have inter-dependent link properties
>
> Mirela, you mention an issue with TYPE_CPU_CLUSTER / TYPE_CPU, is that
> an example of this qom inter-link problem?
>

Yes, for cluster/cpu specifically it is the parent-child relationship 
between objects.


>> As the discussion is quite complicated, here is the recording of it.
>>
>> Later, Juan.
>>
>>
>> https://redhat.bluejeans.com/m/TFyaUsLqt3T/?share=True
>>
>> *: We will talk about this on the next call
>>
>>
>