Your message dated Tue, 26 May 2020 16:47:58 +0300
with message-id <[email protected]>
and subject line Re: Bug#961574: QEMU 5.0 x86_64 regression: Could not allocate
dynamic translator buffer
has caused the Debian Bug report #961574,
regarding QEMU 5.0 x86_64 regression: Could not allocate dynamic translator
buffer
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
961574: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=961574
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: qemu-system-x86
Version: 1:5.0-5
In our latest Cockpit CI image refresh of debian-testing [1], all libvirt/QEMU
tests are broken:
| > warning: error: failed to get emulator capabilities
| error: invalid argument: unable to find any emulator to serve 'x86_64'
architecture
| ERROR Host does not support any virtualization options
libvirt version did not change (6.0.0-6), but QEMU updated from 4.2 to 5.0.
I'll send a bug against libvirt, but there is a regression with pure QEMU as
well:
With 4.2, a non-kvm (i. e. emulated) system VM works:
| $ qemu-system-x86_64 -nographic
| SeaBIOS (version 1.13.0-1)
| [...]
|
| iPXE 1.0.0+git-20190125.36a4c85-5 -- Open Source Network Boot Firmware --
http:/
| /ipxe.org
| Features: DNS HTTP iSCSI NFS TFTP AoE ELF MBOOT PXE bzImage Menu PXEXT
But with 5.0, not any more:
| $ admin@debian:~$ qemu-system-x86_64 -nographic
| Could not allocate dynamic translator buffer
The same error happens with e. g.
$ qemu-system-x86_64 -nographic -dump-vmstate ./state
which still works with 4.2, but not any more with 5.0. Maybe libvirt is using
something like that?
When I specify -enable-kvm with any of the commands above, things work with
5.0.
Thanks,
Martin
[1] https://github.com/cockpit-project/bots/pull/890
--- End Message ---
--- Begin Message ---
26.05.2020 13:26, Martin Pitt wrote:
> Hello Michael,
>
> I did some more experiments, and it seems it works if the host has just a
> little bit more than 1 GiB of RAM. With exactly 1 GiB it fails, with 1152MiB
> it
> works.
Ok, thank you for the information.
qemu 5.0 increased default dynamic translator buffer size for 64bit guests
in this commit:
commit 600e17b261555c56a048781b8dd5ba3985650013
Author: Alex Bennée <[email protected]>
Date: Fri Feb 28 19:24:15 2020 +0000
accel/tcg: increase default code gen buffer size for 64 bit
While 32mb is certainly usable a full system boot ends up flushing the
codegen buffer nearly 100 times. Increase the default on 64 bit hosts
to take advantage of all that spare memory. After this change I can
boot my tests system without any TB flushes.
(it was 32Mb, now it is 1Gb by default). This size can be controlled by
tb-size property of the accelerator, like this:
qemu-system-x86_64 -accel tcg,tb-size=32768
(this is an old default).
So this is not a regression per se, it is a.. well, a feature :)
But at least the error message produced by qemu when it can't allocate
the cg buffer cat definitely be improved, so that no strace'ing is
required to see what's going on.
Also, what can be improved too, is the information about changes in
such defaults. For fun, in the Changelog for 5.0 (which is available
at https://wiki.qemu.org/ChangeLog/5.0 ), there *is* a mention of tg-size,
but in a different context:
New deprecated options and features
The "-tb-size N" option has been deprecated. It is replaced by "-accel
tcg,tb-size=N".
but nothing is said about changing the default of it from 32M to 1G.
I'm closing both bugreports now (hopefully the bts will let me to do
so using single email).
Thank you!
/mjt
--- End Message ---
