qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: modular tcg


From: Claudio Fontana
Subject: Re: modular tcg
Date: Thu, 29 Jul 2021 18:35:32 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0

On 7/29/21 4:59 PM, Philippe Mathieu-Daudé wrote:
> On 7/29/21 4:22 PM, Claudio Fontana wrote:
>> On 7/29/21 1:34 PM, Philippe Mathieu-Daudé wrote:
>>> On 7/29/21 12:44 PM, Claudio Fontana wrote:
>>>> On 7/29/21 12:29 PM, Gerd Hoffmann wrote:
>>>>>   Hi,
>>>>>
>>>>>> And another comment: I think we should have some progress on ARM with
>>>>>> the kvm/tcg split and with the KConfig of boards, before we continue
>>>>>> here.
>>>>>
>>>>> Why?  This can easily be tacked in parallel.  We can flip the switch
>>>>> for modular tcg per target in meson.build.
>>>>>
>>>>> take care,
>>>>>   Gerd
>>>>>
>>>>
>>>> Because in the end we need to do this for ARM too and for the other archs 
>>>> too (s390 is already ok),
>>>>
>>>> and in order to be sure not to end up in a dead-end, I think it would be 
>>>> good to have at least a sketch for the other archs as well..
>>>>
>>>> Just my 2c ofc, I think really here still ARM is behind, and we should 
>>>> help it catch up.
>>>>
>>>> If I had more time I would have pushed more on the ARM series, but.. yeah.
>>>
>>> IIUC Alex is waiting 6.2 release to respin.
>>>
>>
>> How does the Kconfig for ARM improvements go? I mean I think those 
>> improvements (enabling only compatible boards with the chosen accelerators) 
>> are important for both tcg-kvm split and possibly for modularization of ARM 
>> accelerators too right?
> 
> I think we all (Alex/you/me) reached the same point where builds work
> but current the testing framework isn't ready for non-TCG or
> modularized-TCG so the CI ends failing.
> 
> I don't want to push for 'CI build-only' because most of the annoying
> problems were from runtime (interfaces not resolved, ... which are
> important when using modules or board with unavailable devices).
> 
> I tried to address that with a QMP command to query accelerators but
> there is a disagreement whether we should query for available/built-in/
> loaded/modularized-but-not-installed/...). At this point I think I
> fairly understand the technical problems but misunderstand the big
> picture here, in particular w.r.t. management apps. I spent too many
> time on this to appear enthusiastic, sorry.
> 

The Kconfig thing also depended on the querying the accelerator part, or not?

I mean, was there the idea was "I want to build only the ARM boards that are 
compatible with the accel options I chose",
which is totally sensible, and removes all the need for workarounds in the 
tcg/kvm split series Alex is now maintaining.

I think you actually had a solution for quering the accelerators btw, and the 
problem was just caching the result to improve the performance?

Thanks,

Claudio








reply via email to

[Prev in Thread] Current Thread [Next in Thread]