On 7 August 2018 at 15:57, Dr. David Alan Gilbert <dgilb...@redhat.com> wrote: > * Gerd Hoffmann (kra...@redhat.com) wrote: >> On Fri, Jul 20, 2018 at 10:19:48AM +0200, remy.n...@blade-group.com wrote: >> > From: "Remy Noel" <remy.n...@blade-group.com> >> > >> > When removing a secondary-vga device and then adding it back (or adding >> > an other one), qemu aborts with: >> > "RAMBlock "0000:00:02.0/vga.vram" already registered, abort!". >> > >> > It is caused by the vram staying registered, preventing vga replugging. >> >> David? Does that look ok? >> >> This balances the >> >> vmstate_register_ram(&s->vram, s->global_vmstate ? NULL : DEVICE(obj)); >> >> call in vga_common_init(). I'm wondering whenever the manual cleanup is >> actually needed in case owner is not NULL? > > I can't see anyone who is calling unregister_ram or the functions it > calls as part of generic device cleanup, so I think it IS needed > to manually do it. > > Which is a bit worrying since we have vastly more register's than > unregister's.
Paolo suggested in an email last month that vmstate_unregister_ram() should simply not exist, because it doesn't actually do anything useful: https://lists.gnu.org/archive/html/qemu-devel/2018-07/msg01125.html (ie it was added in the first place because we'd ended up with two identically named ramblocks, but that only happened because a reference-counting bug meant we hadn't deleted the first one properly before creating the second.) So I think that the bug reported in this thread is similar: the problem is not that we're not calling vmstate_unregister_ram(), but that when the first instance of secondary-vga is removed it is not correctly destroying the ramblock. thanks -- PMM
