On 6/23/23 15:12, Boris Fiuczynski wrote:
> On 6/21/23 6:54 PM, Jonathon Jongsma wrote:
>> On 6/13/23 10:42 AM, Boris Fiuczynski wrote:
>>> Update capabilities for QEMU 8.1 on s390x, add a new capability
>>> async-teardown and make use of it when running on s390x hosts to improve
>>> memory reclaiming.
>>
>> Is this really something that should be enabled unconditionally on all
>> s390x guests, or should it be configured with some domain xml? If
>> there's ever a case where an s390x domain would want this disabled, I
>> think it would have to be configurable. Also, if there is any
>> situation where a domain on a different architecture might want to
>> enable this, that would also require some kind of configurability. At
>> minimum it seems to me that the commit log should have a lot more
>> justification for why this approach is justified.
>>
>> Jonathon
>
> Jonathon,
> thanks for your feedback.
>
> I am unsure where to located such a configuration option in the gust
> domain XML.
>
> A few thoughts:
> 1) introduce a new emulator-options element in devices and a run-with
> child element with a parameter async-teardown, e.g.
> ...
> <devices>
> <emulator>/usr/lib/bin/qemu</emulator>
> <emulator-options>
> <run-with async-teardown='on'/>
> </emulator-options>
> </devices>
> ...
>
> 2) introduce a new run-with element with a parameter async-teardown in
> domain, e.g.
>
> <domain>
> ...
> <run-with async-teardown='on'/>
> ...
> </domain>
>
> Any ideas and suggestions are welcome.
We usually use domain <features/>, e.g.:
<domain>
<name>someName</name>
<uuid/>
...
<features>
<acpi/>
<tcg>
<tb-cache unit='KiB'>102400</tb-cache>
</tcg>
</features>
...
<devices/>
</domain>
This looks like a fit place if we want to expose this in the domain XML.
And from the qemu-options.hx file it doesn't look s390x specific, which
means, we don't need to make the new element arch specific. IOW we can have:
<features>
<async-teardown enabled='yes'/>
</features>
Michal
