Hi! I'm in somewhat doubt what to do with 8.1.1 release.
There are 2 compelling issues, fixing one discovers the other. https://gitlab.com/qemu-project/qemu/-/issues/1864 "x86 VM with TCG and SMP fails to start on 8.1.0" is fixed by 0d58c660689f "softmmu: Use async_run_on_cpu in tcg_commit" But this brings up https://gitlab.com/qemu-project/qemu/-/issues/1866 "mips/mip64 virtio broken on master (and 8.1.0 with tcg fix)" (which is actually more than mips, as I've shown down the line, https://gitlab.com/qemu-project/qemu/-/issues/1866#note_1558221926 ) Also, one commit alone, 86e4f93d827 "softmmu: Assert data in bounds in iotlb_to_section", when not followed with "async_run_on_cpu in tcg_commit", causes assertion failures, eg https://www.mail-archive.com/qemu-devel@nongnu.org/msg989846.html I don't know if "async_run_on_cpu in tcg_commit" was supposed to fix this assertion or not, or maybe some additional fix is needed, - but I haven't see this is triggered with 0d58c660689f applied. There were at least two attempts by Richard to fix issues after 0d58c660689f, one "accel/tcg: Always require can_do_io", which fixes both reproducers for #1866 but at a high cost, and another, "softmmu: Introduce cpu_address_space_sync", which addresses the mips regression but does not fix my reproducer with ovmf and none of the 2 landed on master so far. Right now I have a "which bug to keep?" situation for 8.1.1, and I'd love to have at least *some* comments about all this. I've got no replies to my earlier emails in this area. To mee, it *feels* like 0d58c660689f should be there. Note: the scheduled deadline for staging-8.1.1 is gone yesterday. But this stuff seems to be important enough to delay 8.1.1 further. Just some comments please? :) Thank you! /mjt
