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