[Qemu-devel] why qemu builds ACPI tables twice?

[Michael Tokarev]

When playing with W7 OEM activation again, I noticed that qemu
builds ACPI tables twice to feed seabios.

Here are the 2 stack traces from gdb taken at
hw/i386/acpi-build.c:build_header() when called to build RSDT:

#0  build_header (linker=0x5555562afcc0, table_data=0x5555562afc90,
    h=0x555556340d64, sig=0x5555559f438d "RSDT", len=56, rev=1 '\001')
    at hw/i386/acpi-build.c:232
#1  0x00005555558982c8 in build_rsdt (table_data=0x5555562afc90,
    linker=0x5555562afcc0, table_offsets=0x5555562afcf0)
    at hw/i386/acpi-build.c:1295
#2  0x00005555558989f5 in acpi_build (guest_info=0x5555562be6a0,
    tables=0x7fffffffe3c0) at hw/i386/acpi-build.c:1450
#3  0x0000555555898caa in acpi_setup (guest_info=0x5555562be6a0)
    at hw/i386/acpi-build.c:1541
#4  0x00005555558a6f17 in pc_guest_info_machine_done (notifier=0x5555562be6e8,
    data=0x0) at hw/i386/pc.c:1081
#5  0x0000555555999bec in notifier_list_notify (list=0x5555562112f0, data=0x0)
    at util/notify.c:39
#6  0x0000555555848888 in qemu_run_machine_init_done_notifiers ()
    at vl.c:2800
#7  0x000055555584c9aa in main (argc=4, argv=0x7fffffffe8c8,



#0  build_header (linker=0x555556404a00, table_data=0x5555562b0390,
    h=0x555556330d74, sig=0x5555559f438d "RSDT", len=56, rev=1 '\001')
    at hw/i386/acpi-build.c:232
#1  0x00005555558982c8 in build_rsdt (table_data=0x5555562b0390,
    linker=0x555556404a00, table_offsets=0x555556404a30)
    at hw/i386/acpi-build.c:1295
#2  0x00005555558989f5 in acpi_build (guest_info=0x5555562be6a0,
    tables=0x7fffe9425890) at hw/i386/acpi-build.c:1450
#3  0x0000555555898ae1 in acpi_build_update (build_opaque=0x55555636b010,
    offset=0) at hw/i386/acpi-build.c:1481
#4  0x00005555557384c2 in fw_cfg_read (s=0x5555562e1010)
    at hw/nvram/fw_cfg.c:255
#5  0x0000555555738687 in fw_cfg_comb_read (opaque=0x5555562e1010, addr=1,
    size=1) at hw/nvram/fw_cfg.c:291
#6  0x00005555558db440 in memory_region_read_accessor (mr=0x5555562e34c8,
    addr=1, value=0x7fffe9425a40, size=1, shift=0, mask=255)
    at memory.c:408
#7  0x00005555558db72e in access_with_adjusted_size (addr=1,
    value=0x7fffe9425a40, size=1, access_size_min=1, access_size_max=4,
    access=0x5555558db3e2 <memory_region_read_accessor>, mr=0x5555562e34c8)
    at memory.c:478
#8  0x00005555558dde50 in memory_region_dispatch_read1 (mr=0x5555562e34c8,
    addr=1, size=1) at memory.c:945
#9  0x00005555558ddf18 in memory_region_dispatch_read (mr=0x5555562e34c8,
    addr=1, pval=0x7fffe9425b18, size=1) at memory.c:967
#10 0x00005555558e1512 in io_mem_read (mr=0x5555562e34c8, addr=1,
    pval=0x7fffe9425b18, size=1) at memory.c:1738
#11 0x0000555555866115 in address_space_rw (as=0x555556212d20, addr=1297,
    buf=0x7ffff7ff1000 "%", len=1, is_write=false)
    at exec.c:2068
#12 0x00005555558d7d2a in kvm_handle_io (port=1297, data=0x7ffff7ff1000,
    direction=0, size=1, count=1024) at kvm-all.c:1558
#13 0x00005555558d8297 in kvm_cpu_exec (cpu=0x5555562c7dc0)
    at kvm-all.c:1695
#14 0x00005555558557f4 in qemu_kvm_cpu_thread_fn (arg=0x5555562c7dc0)
    at cpus.c:873
#15 0x00007ffff2760b50 in start_thread (arg=<optimized out>)
    at pthread_create.c:304
#16 0x00007ffff24ab0ed in clone ()
    at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112
#17 0x0000000000000000 in ?? ()


Should one of the two calls be suppressed?

Thanks,

/mjt