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