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