Context:
  https://gitlab.com/qemu-project/qemu/-/issues/285

So far the only fix that we have had posted on the list is
  https://lists.gnu.org/archive/html/qemu-devel/2022-10/msg00391.html
by Daniel. The approach that I'm following here should have
the same outcome, except that it doesn't change the guest's
environment. The approach is to import GTree (sans GSlice)
into QEMU, and use that for TCG.

Daniel: what is the testing that you're using? Could you test
these patches to confirm they fix the issue?

Regarding performance, it looks like GSlice does buy us
something, which might explain why GLib's maintainers don't
want to change it. But I'd put correctness over performance
any day. Furthermore, we could use an alternative tree
implementation; I've tried CCAN's AVL and the performance impact
is lower (I believe due to faster traversals), although I'm
going with a straight import of GTree here to keep the API
identical (and also avoid any potential correctness concerns).

Thanks,
		Emilio

On Tue, Jan 10, 2023 at 10:55:34PM -0500, Emilio Cota wrote:
> Context:
>   https://gitlab.com/qemu-project/qemu/-/issues/285
> 
> So far the only fix that we have had posted on the list is
>   https://lists.gnu.org/archive/html/qemu-devel/2022-10/msg00391.html
> by Daniel. The approach that I'm following here should have
> the same outcome, except that it doesn't change the guest's
> environment. The approach is to import GTree (sans GSlice)
> into QEMU, and use that for TCG.
> 
> Daniel: what is the testing that you're using? Could you test
> these patches to confirm they fix the issue?

I used the demo program in the bug report. With your patches applied,
that appears to run without hangs for a decent amount of time.

With regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|