Re: [Qemu-devel] [PATCH] secondary-vga: unregister vram on unplug.

[Remy NOEL]

Hi

On 8/30/18 1:28 PM, Gerd Hoffmann wrote:

> > I'll take a look...
> Ping, any results?
>
> I'm wondering whenever we should just revert
> 93abfc88bd649de1933588bfc7175605331b3ea9.
>
> Retested hotplug with 93abfc88bd649de1933588bfc7175605331b3ea9 reverted.
> Works just fine with guest kernel loaded.  Doesn't work without guest
> booted (grub prompt for example), but pci hotplug requires guest
> cooperation so this isn't a bug in secondary-vga ...
>
> cheers,
>    Gerd

I finally got the time to get back on this issue.

Just deleting the 3 subregions from the mmio in the exit callback does 
the job and everything works fine. I'll re-submit the patch in a new thread.

Reverting 93abfc88bd649de1933588bfc7175605331b3ea9 indeed frees the 
object but the hanging memory regions seems to cause some problems upon 
reset::

  - After deleting a device and adding it back, i get a segfault when 
calling system_reset:

                #0  0x00007f90611acab8 g_hash_table_iter_next 
(libglib-2.0.so.0)
                #1  0x000055a631e7aa39 object_resolve_partial_path 
(qemu-system-x86_64)
                #2  0x000055a631e7a9ea object_resolve_partial_path 
(qemu-system-x86_64)
                #3  0x000055a631e7a9ea object_resolve_partial_path 
(qemu-system-x86_64)
                #4  0x000055a631e7a9ea object_resolve_partial_path 
(qemu-system-x86_64)
                #5  0x000055a631e7aafd object_resolve_path_type 
(qemu-system-x86_64)
                #6  0x000055a631c29879 piix4_pm_find (qemu-system-x86_64)
                #7  0x000055a631b2d4ed acpi_get_pm_info 
(qemu-system-x86_64)
                #8  0x000055a631b35903 acpi_build (qemu-system-x86_64)
                #9  0x000055a631b3618d acpi_build_update 
(qemu-system-x86_64)
                #10 0x000055a631d27cb3 fw_cfg_select (qemu-system-x86_64)
                #11 0x000055a631d2848c fw_cfg_comb_write 
(qemu-system-x86_64)
                #12 0x000055a631a5ebd7 memory_region_write_accessor 
(qemu-system-x86_64)
                #13 0x000055a631a5edec access_with_adjusted_size 
(qemu-system-x86_64)
                #14 0x000055a631a61ac2 memory_region_dispatch_write 
(qemu-system-x86_64)
                #15 0x000055a6319fcbf9 flatview_write_continue 
(qemu-system-x86_64)
                #16 0x000055a6319fcd43 flatview_write (qemu-system-x86_64)
                #17 0x000055a6319fd049 address_space_write 
(qemu-system-x86_64)
                #18 0x000055a6319fd09a address_space_rw 
(qemu-system-x86_64)
                #19 0x000055a631a7cd66 kvm_handle_io (qemu-system-x86_64)
                #20 0x000055a631a7d499 kvm_cpu_exec (qemu-system-x86_64)
                #21 0x000055a631a43cb7 qemu_kvm_cpu_thread_fn 
(qemu-system-x86_64)
                #22 0x000055a631fbbadd qemu_thread_start 
(qemu-system-x86_64)
                #23 0x00007f905c851a9d start_thread (libpthread.so.0)
                #24 0x00007f905c781a43 __clone (libc.so.6)

  - When calling system_reset just after removing a device, we get a 
bunch of:

        GLib-CRITICAL **: 10:16:29.020: g_hash_table_iter_init: 
assertion 'hash_table != NULL' failed

        GLib-CRITICAL **: 10:16:29.023: g_hash_table_iter_next: 
assertion 'ri->version == ri->hash_table->version' failed


I did not inquiry those further though as the subregions removal did 
lead to a clean state.


Remy Noel