Re: [Qemu-devel] Hot unplug of pci-serial-2x fails assertion

[Markus Armbruster]

Peter Crosthwaite <address@hidden> writes:

> On Mon, Jul 14, 2014 at 9:10 PM, Markus Armbruster <address@hidden> wrote:
>> Watch this:
>>
>>     (qemu) chardev-add file,path=foo2,id=foo2
>>     (qemu) chardev-add file,path=foo3,id=foo3
>>     (qemu) device_add id=gg,driver=pci-serial-2x,chardev1=foo2,chardev2=foo3
>>     (qemu) device_del gg
>>     (qemu) upstream-qemu: /work/armbru/qemu/memory.c:1259:
>> memory_region_finalize: Assertion `((&mr->subregions)->tqh_first ==
>> ((void *)0))' failed.
>>
>
> Are there more specifics to reproduction? I'm struggling and I've
> tried a few variants.
>
> Curiously I can device_del gg repeatedly with seemingly no effect however:
>
> address@hidden:~/qemu$ ./x86_64-softmmu/qemu-system-x86_64  -nographic
> QEMU 2.0.91 monitor - type 'help' for more information
> (qemu)  chardev-add file,path=foo2,id=foo2
> (qemu)  chardev-add file,path=foo3,id=foo3
> (qemu) device_add id=gg,driver=pci-serial-2x,chardev1=foo2,chardev2=foo3
> (qemu) device_del gg
> (qemu) device_del gg
> (qemu) device_del gg
> (qemu) info qtree
> bus: main-system-bus
>   type System
>   dev: hpet, id ""
>     gpio-in "" 2
>     gpio-out "" 1
>     timers = 3 (0x3)
>     msi = false
>     hpet-intcap = 4 (0x4)
>     irq 32
>     mmio 00000000fed00000/0000000000000400
>   dev: ioapic, id ""
>     gpio-in "" 24
>     irq 0
>     mmio 00000000fec00000/0000000000001000
>   dev: i440FX-pcihost, id ""
>     pci-hole64-size = 18446744073709551615 (16 EiB)
>     short_root_bus = 0 (0x0)
>     irq 0
>     bus: pci.0
>       type PCI
>       dev: pci-serial-2x, id "gg"
>         chardev1 = "foo2"
>         chardev2 = "foo3"
>         prog_if = 2 (0x2)
>         addr = 04.0
>         romfile = ""
>         rombar = 1 (0x1)
>         multifunction = false
>         command_serr_enable = true
>         class Serial port, addr 00:04.0, pci id 1b36:0003 (sub 1af4:1100)
>         bar 0: i/o at 0xffffffffffffffff [0xe]
>
> Am I missing something?

Is your guest running and honoring ACPI unplug requests?

See also Paolo's reply, which points to a patch.