| Message ID | 20210103205021.2837760-1-f4bug@amsat.org (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Sun, 3 Jan 2021 at 20:53, Philippe Mathieu-Daudé <f4bug@amsat.org> wrote: > > The following changes since commit 83734919c408ba02adb6ea616d68cd1a72837fbe: > > Merge remote-tracking branch 'remotes/cohuck-gitlab/tags/s390x-20201222' into staging (2021-01-01 18:19:44 +0000) > > are available in the Git repository at: > > https://gitlab.com/philmd/qemu.git tags/mips-20210103 > > for you to fetch changes up to 9c592996981fcb37fef011d7e9603cb31f8ef29f: > > tests/acceptance: Test boot_linux_console for fuloong2e (2021-01-03 21:41:03 +0100) > > ---------------------------------------------------------------- > MIPS patches queue > > - Use PCI macros (Philippe Mathieu-Daudé) > - Clean up VT82C686B south bridge (BALATON Zoltan) > - Introduce clock_ticks_to_ns() (Peter Maydell) > - Add Loongson-3 machine (Huacai Chen) > - Make addresses used by bootloader unsigned (Jiaxun Yang) > - Clean fuloong2e PROM environment (Jiaxun Yang) > - Add integration test of fuloong2e booting Linux (Jiaxun Yang) This fails 'make check' (consistently) on the aarch32-chroot-on-aarch64 host: PASS 51 qtest-mips64el/qmp-cmd-test /mips64el/qmp/query-command-line-options PASS 52 qtest-mips64el/qmp-cmd-test /mips64el/qmp/query-acpi-ospm-status PASS 53 qtest-mips64el/qmp-cmd-test /mips64el/qmp/object-add-failure-modes MALLOC_PERTURB_=${MALLOC_PERTURB_:-$(( ${RANDOM:-0} % 255 + 1))} QTEST_QEMU_IMG=./qemu-img G_TEST_DBUS_DAEMON=/home/peter.maydell/qemu/tests/dbus-vmstate-daemon.sh QTEST_QEMU_BINARY=./qemu-system-mips64el tests/qtest/qom-test --tap -k double free or corruption (out) ../../tests/qtest/libqtest.c:181: kill_qemu() detected QEMU death from signal 6 (Aborted) ERROR qtest-mips64el/qom-test - too few tests run (expected 8, got 0) Makefile.mtest:2249: recipe for target 'run-test-279' failed make: *** [run-test-279] Error 1 thanks -- PMM
On Mon, 4 Jan 2021 at 11:41, Peter Maydell <peter.maydell@linaro.org> wrote: > > On Sun, 3 Jan 2021 at 20:53, Philippe Mathieu-Daudé <f4bug@amsat.org> wrote: > > > > The following changes since commit 83734919c408ba02adb6ea616d68cd1a72837fbe: > > > > Merge remote-tracking branch 'remotes/cohuck-gitlab/tags/s390x-20201222' into staging (2021-01-01 18:19:44 +0000) > > > > are available in the Git repository at: > > > > https://gitlab.com/philmd/qemu.git tags/mips-20210103 > > > > for you to fetch changes up to 9c592996981fcb37fef011d7e9603cb31f8ef29f: > > > > tests/acceptance: Test boot_linux_console for fuloong2e (2021-01-03 21:41:03 +0100) > > > > ---------------------------------------------------------------- > > MIPS patches queue > > > > - Use PCI macros (Philippe Mathieu-Daudé) > > - Clean up VT82C686B south bridge (BALATON Zoltan) > > - Introduce clock_ticks_to_ns() (Peter Maydell) > > - Add Loongson-3 machine (Huacai Chen) > > - Make addresses used by bootloader unsigned (Jiaxun Yang) > > - Clean fuloong2e PROM environment (Jiaxun Yang) > > - Add integration test of fuloong2e booting Linux (Jiaxun Yang) > > > This fails 'make check' (consistently) on the aarch32-chroot-on-aarch64 > host: > > PASS 51 qtest-mips64el/qmp-cmd-test /mips64el/qmp/query-command-line-options > PASS 52 qtest-mips64el/qmp-cmd-test /mips64el/qmp/query-acpi-ospm-status > PASS 53 qtest-mips64el/qmp-cmd-test /mips64el/qmp/object-add-failure-modes > MALLOC_PERTURB_=${MALLOC_PERTURB_:-$(( ${RANDOM:-0} % 255 + 1))} > QTEST_QEMU_IMG=./qemu-img > G_TEST_DBUS_DAEMON=/home/peter.maydell/qemu/tests/dbus-vmstate-daemon.sh > QTEST_QEMU_BINARY=./qemu-system-mips64el tests/qtest/qom-test --tap -k > double free or corruption (out) > ../../tests/qtest/libqtest.c:181: kill_qemu() detected QEMU death from > signal 6 (Aborted) > ERROR qtest-mips64el/qom-test - too few tests run (expected 8, got 0) > Makefile.mtest:2249: recipe for target 'run-test-279' failed > make: *** [run-test-279] Error 1 Also on OSX, likely the same bug: Broken pipe ../../tests/qtest/libqtest.c:181: kill_qemu() detected QEMU death from signal 11 (Segmentation fault: 11) ERROR qtest-mips64el/qom-test - too few tests run (expected 8, got 1) thanks -- PMM
Hi Peter, On 1/4/21 12:50 PM, Peter Maydell wrote: > On Mon, 4 Jan 2021 at 11:41, Peter Maydell <peter.maydell@linaro.org> wrote: >> >> On Sun, 3 Jan 2021 at 20:53, Philippe Mathieu-Daudé <f4bug@amsat.org> wrote: >>> >>> The following changes since commit 83734919c408ba02adb6ea616d68cd1a72837fbe: >>> >>> Merge remote-tracking branch 'remotes/cohuck-gitlab/tags/s390x-20201222' into staging (2021-01-01 18:19:44 +0000) >>> >>> are available in the Git repository at: >>> >>> https://gitlab.com/philmd/qemu.git tags/mips-20210103 >>> >>> for you to fetch changes up to 9c592996981fcb37fef011d7e9603cb31f8ef29f: >>> >>> tests/acceptance: Test boot_linux_console for fuloong2e (2021-01-03 21:41:03 +0100) >>> >>> ---------------------------------------------------------------- >>> MIPS patches queue >>> >>> - Use PCI macros (Philippe Mathieu-Daudé) >>> - Clean up VT82C686B south bridge (BALATON Zoltan) >>> - Introduce clock_ticks_to_ns() (Peter Maydell) >>> - Add Loongson-3 machine (Huacai Chen) >>> - Make addresses used by bootloader unsigned (Jiaxun Yang) >>> - Clean fuloong2e PROM environment (Jiaxun Yang) >>> - Add integration test of fuloong2e booting Linux (Jiaxun Yang) >> >> >> This fails 'make check' (consistently) on the aarch32-chroot-on-aarch64 >> host: >> >> PASS 51 qtest-mips64el/qmp-cmd-test /mips64el/qmp/query-command-line-options >> PASS 52 qtest-mips64el/qmp-cmd-test /mips64el/qmp/query-acpi-ospm-status >> PASS 53 qtest-mips64el/qmp-cmd-test /mips64el/qmp/object-add-failure-modes >> MALLOC_PERTURB_=${MALLOC_PERTURB_:-$(( ${RANDOM:-0} % 255 + 1))} >> QTEST_QEMU_IMG=./qemu-img >> G_TEST_DBUS_DAEMON=/home/peter.maydell/qemu/tests/dbus-vmstate-daemon.sh >> QTEST_QEMU_BINARY=./qemu-system-mips64el tests/qtest/qom-test --tap -k >> double free or corruption (out) >> ../../tests/qtest/libqtest.c:181: kill_qemu() detected QEMU death from >> signal 6 (Aborted) >> ERROR qtest-mips64el/qom-test - too few tests run (expected 8, got 0) >> Makefile.mtest:2249: recipe for target 'run-test-279' failed >> make: *** [run-test-279] Error 1 > > Also on OSX, likely the same bug: > > Broken pipe > ../../tests/qtest/libqtest.c:181: kill_qemu() detected QEMU death from > signal 11 (Segmentation fault: 11) > ERROR qtest-mips64el/qom-test - too few tests run (expected 8, got 1) Thanks. I am using the ubuntu-i386-guestcan not reproduce with the > > thanks > -- PMM >
On Mon, Jan 4, 2021 at 2:53 PM Philippe Mathieu-Daudé <f4bug@amsat.org> wrote: > > Hi Peter, > > On 1/4/21 12:50 PM, Peter Maydell wrote: > > On Mon, 4 Jan 2021 at 11:41, Peter Maydell <peter.maydell@linaro.org> wrote: > >> > >> On Sun, 3 Jan 2021 at 20:53, Philippe Mathieu-Daudé <f4bug@amsat.org> wrote: > >>> > >>> The following changes since commit 83734919c408ba02adb6ea616d68cd1a72837fbe: > >>> > >>> Merge remote-tracking branch 'remotes/cohuck-gitlab/tags/s390x-20201222' into staging (2021-01-01 18:19:44 +0000) > >>> > >>> are available in the Git repository at: > >>> > >>> https://gitlab.com/philmd/qemu.git tags/mips-20210103 > >>> > >>> for you to fetch changes up to 9c592996981fcb37fef011d7e9603cb31f8ef29f: > >>> > >>> tests/acceptance: Test boot_linux_console for fuloong2e (2021-01-03 21:41:03 +0100) > >>> > >>> ---------------------------------------------------------------- > >>> MIPS patches queue > >>> > >>> - Use PCI macros (Philippe Mathieu-Daudé) > >>> - Clean up VT82C686B south bridge (BALATON Zoltan) > >>> - Introduce clock_ticks_to_ns() (Peter Maydell) > >>> - Add Loongson-3 machine (Huacai Chen) > >>> - Make addresses used by bootloader unsigned (Jiaxun Yang) > >>> - Clean fuloong2e PROM environment (Jiaxun Yang) > >>> - Add integration test of fuloong2e booting Linux (Jiaxun Yang) > >> > >> > >> This fails 'make check' (consistently) on the aarch32-chroot-on-aarch64 > >> host: > >> > >> PASS 51 qtest-mips64el/qmp-cmd-test /mips64el/qmp/query-command-line-options > >> PASS 52 qtest-mips64el/qmp-cmd-test /mips64el/qmp/query-acpi-ospm-status > >> PASS 53 qtest-mips64el/qmp-cmd-test /mips64el/qmp/object-add-failure-modes > >> MALLOC_PERTURB_=${MALLOC_PERTURB_:-$(( ${RANDOM:-0} % 255 + 1))} > >> QTEST_QEMU_IMG=./qemu-img > >> G_TEST_DBUS_DAEMON=/home/peter.maydell/qemu/tests/dbus-vmstate-daemon.sh > >> QTEST_QEMU_BINARY=./qemu-system-mips64el tests/qtest/qom-test --tap -k > >> double free or corruption (out) > >> ../../tests/qtest/libqtest.c:181: kill_qemu() detected QEMU death from > >> signal 6 (Aborted) > >> ERROR qtest-mips64el/qom-test - too few tests run (expected 8, got 0) > >> Makefile.mtest:2249: recipe for target 'run-test-279' failed > >> make: *** [run-test-279] Error 1 > > > > Also on OSX, likely the same bug: > > > > Broken pipe > > ../../tests/qtest/libqtest.c:181: kill_qemu() detected QEMU death from > > signal 11 (Segmentation fault: 11) > > ERROR qtest-mips64el/qom-test - too few tests run (expected 8, got 1) > > Thanks. I am using the ubuntu-i386-guestcan not reproduce with the I just discovered some magic combination of keys send an email without asking for confirmation =) So, I am using the ubuntu-i386 VM for 32-bit guest testing, and can not reproduce (this tag, or /staging - 42a37b6289d - with ehabkost patches). I don't have access to OSX host. I'll see to install an aarch32 chroot and keep testing (not sure what can differ from an i386 guest). If I can't find anything I'll resend the same series without the Loongson-3 machine, which is the single part adding QOM objects. Thanks, Phil.
On Mon, 4 Jan 2021 at 13:59, Philippe Mathieu-Daudé <f4bug@amsat.org> wrote: > I don't have access to OSX host. I'll see to install an aarch32 chroot and > keep testing (not sure what can differ from an i386 guest). > If I can't find anything I'll resend the same series without the Loongson-3 > machine, which is the single part adding QOM objects. You might also try using valgrind/address-sanitizer/etc, which can sometimes flag up this kind of bug on x86-64 even if by default it happens to work. thanks -- PMM
On 1/4/21 4:01 PM, Peter Maydell wrote: > On Mon, 4 Jan 2021 at 13:59, Philippe Mathieu-Daudé <f4bug@amsat.org> wrote: >> I don't have access to OSX host. I'll see to install an aarch32 chroot and >> keep testing (not sure what can differ from an i386 guest). >> If I can't find anything I'll resend the same series without the Loongson-3 >> machine, which is the single part adding QOM objects. > > You might also try using valgrind/address-sanitizer/etc, which can > sometimes flag up this kind of bug on x86-64 even if by default > it happens to work. On 32-bit I hit https://github.com/google/sanitizers/issues/954: $ qemu-system-mips64el AddressSanitizer:DEADLYSIGNAL ================================================================= ==18063==ERROR: AddressSanitizer: SEGV on unknown address 0xb7f20e40 (pc 0xb7f20e54 bp 0xbf86556c sp 0xbf86552c T16777215) ==18063==The signal is caused by a WRITE memory access. #0 0xb7f20e53 (/lib/ld-linux.so.2+0x11e53) #1 0xeb9b59 (/tmp/build/qemu-system-mips64el+0xa86b59) #2 0xe9c1c2 (/tmp/build/qemu-system-mips64el+0xa691c2) #3 0xb7f1e8ea (/lib/ld-linux.so.2+0xf8ea) #4 0xb7f0fcb9 (/lib/ld-linux.so.2+0xcb9) AddressSanitizer can not provide additional info. SUMMARY: AddressSanitizer: SEGV (/lib/ld-linux.so.2+0x11e53) ==18063==ABORTING What is funny is Aurelien is mentioned in the GCC BZ =) https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84761 What libc do you use? I'll try to downgrade or reinstall an old distrib...
On 1/4/21 6:39 PM, Philippe Mathieu-Daudé wrote: > On 1/4/21 4:01 PM, Peter Maydell wrote: >> On Mon, 4 Jan 2021 at 13:59, Philippe Mathieu-Daudé <f4bug@amsat.org> wrote: >>> I don't have access to OSX host. I'll see to install an aarch32 chroot and >>> keep testing (not sure what can differ from an i386 guest). >>> If I can't find anything I'll resend the same series without the Loongson-3 >>> machine, which is the single part adding QOM objects. OK I guess I found the problem, we have: struct LoongsonMachineState { MachineState parent_obj; MemoryRegion *pio_alias; MemoryRegion *mmio_alias; MemoryRegion *ecam_alias; }; Then: static inline void loongson3_virt_devices_init(MachineState *machine, DeviceState *pic) { int i; qemu_irq irq; PCIBus *pci_bus; DeviceState *dev; MemoryRegion *mmio_reg, *ecam_reg; LoongsonMachineState *s = LOONGSON_MACHINE(machine); LoongsonMachineState is never allocated... Accessing its MR lead to BOF.
On 1/4/21 7:24 PM, Philippe Mathieu-Daudé wrote: > On 1/4/21 6:39 PM, Philippe Mathieu-Daudé wrote: >> On 1/4/21 4:01 PM, Peter Maydell wrote: >>> On Mon, 4 Jan 2021 at 13:59, Philippe Mathieu-Daudé <f4bug@amsat.org> wrote: >>>> I don't have access to OSX host. I'll see to install an aarch32 chroot and >>>> keep testing (not sure what can differ from an i386 guest). >>>> If I can't find anything I'll resend the same series without the Loongson-3 >>>> machine, which is the single part adding QOM objects. > > OK I guess I found the problem, we have: > > struct LoongsonMachineState { > MachineState parent_obj; > MemoryRegion *pio_alias; > MemoryRegion *mmio_alias; > MemoryRegion *ecam_alias; > }; > > Then: > > static inline void loongson3_virt_devices_init(MachineState *machine, > DeviceState *pic) > { > int i; > qemu_irq irq; > PCIBus *pci_bus; > DeviceState *dev; > MemoryRegion *mmio_reg, *ecam_reg; > LoongsonMachineState *s = LOONGSON_MACHINE(machine); > > LoongsonMachineState is never allocated... Accessing its MR lead > to BOF. I'm going to respin with this (pass 32-bit tests): -- >8 -- diff --git a/hw/mips/loongson3_virt.c b/hw/mips/loongson3_virt.c index e3723d3dd0f..d4a82fa5367 100644 --- a/hw/mips/loongson3_virt.c +++ b/hw/mips/loongson3_virt.c @@ -612,8 +612,10 @@ static void mips_loongson3_virt_init(MachineState *machine) loongson3_virt_devices_init(machine, liointc); } -static void mips_loongson3_virt_machine_init(MachineClass *mc) +static void loongson3v_machine_class_init(ObjectClass *oc, void *data) { + MachineClass *mc = MACHINE_CLASS(oc); + mc->desc = "Loongson-3 Virtualization Platform"; mc->init = mips_loongson3_virt_init; mc->block_default_type = IF_IDE; @@ -624,4 +626,13 @@ static void mips_loongson3_virt_machine_init(MachineClass *mc) mc->minimum_page_bits = 14; } -DEFINE_MACHINE("loongson3-virt", mips_loongson3_virt_machine_init) +static const TypeInfo loongson3_machine_types[] = { + { + .name = TYPE_LOONGSON_MACHINE, + .parent = TYPE_MACHINE, + .instance_size = sizeof(LoongsonMachineState), + .class_init = loongson3v_machine_class_init, + } +}; + +DEFINE_TYPES(loongson3_machine_types) --- Thanks Peter for catching this (we really need a 32-bit host runner on GitLab...). Phil.
Hi, Philippe and Peter, On Tue, Jan 5, 2021 at 2:30 AM Philippe Mathieu-Daudé <f4bug@amsat.org> wrote: > > On 1/4/21 7:24 PM, Philippe Mathieu-Daudé wrote: > > On 1/4/21 6:39 PM, Philippe Mathieu-Daudé wrote: > >> On 1/4/21 4:01 PM, Peter Maydell wrote: > >>> On Mon, 4 Jan 2021 at 13:59, Philippe Mathieu-Daudé <f4bug@amsat.org> wrote: > >>>> I don't have access to OSX host. I'll see to install an aarch32 chroot and > >>>> keep testing (not sure what can differ from an i386 guest). > >>>> If I can't find anything I'll resend the same series without the Loongson-3 > >>>> machine, which is the single part adding QOM objects. > > > > OK I guess I found the problem, we have: > > > > struct LoongsonMachineState { > > MachineState parent_obj; > > MemoryRegion *pio_alias; > > MemoryRegion *mmio_alias; > > MemoryRegion *ecam_alias; > > }; > > > > Then: > > > > static inline void loongson3_virt_devices_init(MachineState *machine, > > DeviceState *pic) > > { > > int i; > > qemu_irq irq; > > PCIBus *pci_bus; > > DeviceState *dev; > > MemoryRegion *mmio_reg, *ecam_reg; > > LoongsonMachineState *s = LOONGSON_MACHINE(machine); > > > > LoongsonMachineState is never allocated... Accessing its MR lead > > to BOF. > > I'm going to respin with this (pass 32-bit tests): > > -- >8 -- > diff --git a/hw/mips/loongson3_virt.c b/hw/mips/loongson3_virt.c > index e3723d3dd0f..d4a82fa5367 100644 > --- a/hw/mips/loongson3_virt.c > +++ b/hw/mips/loongson3_virt.c > @@ -612,8 +612,10 @@ static void mips_loongson3_virt_init(MachineState > *machine) > loongson3_virt_devices_init(machine, liointc); > } > > -static void mips_loongson3_virt_machine_init(MachineClass *mc) > +static void loongson3v_machine_class_init(ObjectClass *oc, void *data) > { > + MachineClass *mc = MACHINE_CLASS(oc); > + > mc->desc = "Loongson-3 Virtualization Platform"; > mc->init = mips_loongson3_virt_init; > mc->block_default_type = IF_IDE; > @@ -624,4 +626,13 @@ static void > mips_loongson3_virt_machine_init(MachineClass *mc) > mc->minimum_page_bits = 14; > } > > -DEFINE_MACHINE("loongson3-virt", mips_loongson3_virt_machine_init) > +static const TypeInfo loongson3_machine_types[] = { > + { > + .name = TYPE_LOONGSON_MACHINE, > + .parent = TYPE_MACHINE, > + .instance_size = sizeof(LoongsonMachineState), > + .class_init = loongson3v_machine_class_init, > + } > +}; > + > +DEFINE_TYPES(loongson3_machine_types) > --- > > Thanks Peter for catching this (we really need a 32-bit host runner > on GitLab...). > Should I send a new version? Huacai > Phil.
On 1/5/21 2:53 AM, Huacai Chen wrote: > Hi, Philippe and Peter, > > On Tue, Jan 5, 2021 at 2:30 AM Philippe Mathieu-Daudé <f4bug@amsat.org> wrote: >> >> On 1/4/21 7:24 PM, Philippe Mathieu-Daudé wrote: >>> On 1/4/21 6:39 PM, Philippe Mathieu-Daudé wrote: >>>> On 1/4/21 4:01 PM, Peter Maydell wrote: >>>>> On Mon, 4 Jan 2021 at 13:59, Philippe Mathieu-Daudé <f4bug@amsat.org> wrote: >>>>>> I don't have access to OSX host. I'll see to install an aarch32 chroot and >>>>>> keep testing (not sure what can differ from an i386 guest). >>>>>> If I can't find anything I'll resend the same series without the Loongson-3 >>>>>> machine, which is the single part adding QOM objects. >>> >>> OK I guess I found the problem, we have: >>> >>> struct LoongsonMachineState { >>> MachineState parent_obj; >>> MemoryRegion *pio_alias; >>> MemoryRegion *mmio_alias; >>> MemoryRegion *ecam_alias; >>> }; >>> >>> Then: >>> >>> static inline void loongson3_virt_devices_init(MachineState *machine, >>> DeviceState *pic) >>> { >>> int i; >>> qemu_irq irq; >>> PCIBus *pci_bus; >>> DeviceState *dev; >>> MemoryRegion *mmio_reg, *ecam_reg; >>> LoongsonMachineState *s = LOONGSON_MACHINE(machine); >>> >>> LoongsonMachineState is never allocated... Accessing its MR lead >>> to BOF. >> >> I'm going to respin with this (pass 32-bit tests): >> >> -- >8 -- >> diff --git a/hw/mips/loongson3_virt.c b/hw/mips/loongson3_virt.c >> index e3723d3dd0f..d4a82fa5367 100644 >> --- a/hw/mips/loongson3_virt.c >> +++ b/hw/mips/loongson3_virt.c >> @@ -612,8 +612,10 @@ static void mips_loongson3_virt_init(MachineState >> *machine) >> loongson3_virt_devices_init(machine, liointc); >> } >> >> -static void mips_loongson3_virt_machine_init(MachineClass *mc) >> +static void loongson3v_machine_class_init(ObjectClass *oc, void *data) >> { >> + MachineClass *mc = MACHINE_CLASS(oc); >> + >> mc->desc = "Loongson-3 Virtualization Platform"; >> mc->init = mips_loongson3_virt_init; >> mc->block_default_type = IF_IDE; >> @@ -624,4 +626,13 @@ static void >> mips_loongson3_virt_machine_init(MachineClass *mc) >> mc->minimum_page_bits = 14; >> } >> >> -DEFINE_MACHINE("loongson3-virt", mips_loongson3_virt_machine_init) >> +static const TypeInfo loongson3_machine_types[] = { >> + { >> + .name = TYPE_LOONGSON_MACHINE, >> + .parent = TYPE_MACHINE, >> + .instance_size = sizeof(LoongsonMachineState), >> + .class_init = loongson3v_machine_class_init, >> + } >> +}; >> + >> +DEFINE_TYPES(loongson3_machine_types) >> --- >> >> Thanks Peter for catching this (we really need a 32-bit host runner >> on GitLab...). >> > Should I send a new version? No, I'll squash that in and resend (preparing MIPS pull requests involve some manual testing, I couldn't automate all the steps yet, so it takes me some time). Regards, Phil.
On 1/4/21 6:39 PM, Philippe Mathieu-Daudé wrote: > On 1/4/21 4:01 PM, Peter Maydell wrote: >> On Mon, 4 Jan 2021 at 13:59, Philippe Mathieu-Daudé <f4bug@amsat.org> wrote: >>> I don't have access to OSX host. I'll see to install an aarch32 chroot and >>> keep testing (not sure what can differ from an i386 guest). >>> If I can't find anything I'll resend the same series without the Loongson-3 >>> machine, which is the single part adding QOM objects. >> >> You might also try using valgrind/address-sanitizer/etc, which can >> sometimes flag up this kind of bug on x86-64 even if by default >> it happens to work. > > On 32-bit I hit https://github.com/google/sanitizers/issues/954: > > $ qemu-system-mips64el > AddressSanitizer:DEADLYSIGNAL > ================================================================= > ==18063==ERROR: AddressSanitizer: SEGV on unknown address 0xb7f20e40 (pc > 0xb7f20e54 bp 0xbf86556c sp 0xbf86552c T16777215) > ==18063==The signal is caused by a WRITE memory access. > #0 0xb7f20e53 (/lib/ld-linux.so.2+0x11e53) > #1 0xeb9b59 (/tmp/build/qemu-system-mips64el+0xa86b59) > #2 0xe9c1c2 (/tmp/build/qemu-system-mips64el+0xa691c2) > #3 0xb7f1e8ea (/lib/ld-linux.so.2+0xf8ea) > #4 0xb7f0fcb9 (/lib/ld-linux.so.2+0xcb9) > > AddressSanitizer can not provide additional info. > SUMMARY: AddressSanitizer: SEGV (/lib/ld-linux.so.2+0x11e53) > ==18063==ABORTING Let's resume what I learned here before I forget. I'll send corresponding patches later. 1/ glibc bug Ubuntu 18.04 released on 20191114 (the one used in tests/vm/) is affected. Release from 20201211.1 is fixed. -- >8 -- diff --git a/tests/vm/ubuntu.i386 b/tests/vm/ubuntu.i386 index 47681b6f87d..608514b2d3e 100755 --- a/tests/vm/ubuntu.i386 +++ b/tests/vm/ubuntu.i386 @@ -24,9 +24,9 @@ DEFAULT_CONFIG = { class UbuntuX86VM(ubuntuvm.UbuntuVM): name = "ubuntu.i386" arch = "i386" - image_link="https://cloud-images.ubuntu.com/releases/bionic/"\ - "release-20191114/ubuntu-18.04-server-cloudimg-i386.img" - image_sha256="28969840626d1ea80bb249c08eef1a4533e8904aa51a327b40f37ac4b4ff04ef" + image_link="https://cloud-images.ubuntu.com/releases/bionic/" \ + "release-20201211.1/ubuntu-18.04-server-cloudimg-i386.img" + image_sha256="94b83507f1a963779b01310f56f7e9df3c04628afead878c9555bb61f17aafc1" BUILD_SCRIPT = """ set -e; cd $(mktemp -d); --- 2/ Avoid rebuilding VM everytime Brainless kludge: -- >8 -- diff --git a/tests/vm/Makefile.include b/tests/vm/Makefile.include index e94d95ec541..224ed4c0d57 100644 --- a/tests/vm/Makefile.include +++ b/tests/vm/Makefile.include @@ -5,12 +5,12 @@ EFI_AARCH64 = $(wildcard $(BUILD_DIR)/pc-bios/edk2-aarch64-code.fd) IMAGES := freebsd netbsd openbsd centos fedora haiku.x86_64 -ifneq ($(GENISOIMAGE),) +#ifneq ($(GENISOIMAGE),) IMAGES += ubuntu.i386 centos ifneq ($(EFI_AARCH64),) IMAGES += ubuntu.aarch64 centos.aarch64 endif -endif +#endif IMAGES_DIR := $(HOME)/.cache/qemu-vm/images IMAGE_FILES := $(patsubst %, $(IMAGES_DIR)/%.img, $(IMAGES)) --- This is because if GENISOIMAGE is set by Meson, but the 'make vm-build' rules don't use Meson... So the ubuntu/centos images are trashed after each use because they are not marked .PRECIOUS. 3/ -Watomic-alignment on some 32-bit host (i386 at least) There are plenty of atomic-alignment warnings on i386: [139/675] Compiling C object softmmu.fa.p/softmmu_icount.c.o In file included from ../softmmu/icount.c:31: In file included from include/exec/exec-all.h:23: In file included from ../target/mips/cpu.h:4: In file included from ../target/mips/cpu-qom.h:23: In file included from include/hw/core/cpu.h:23: In file included from include/hw/qdev-core.h:5: In file included from include/qemu/bitmap.h:16: In file included from include/qemu/bitops.h:17: include/qemu/atomic.h:463:12: warning: misaligned atomic operation may incur significant performance penalty [-Watomic-alignment] return qatomic_read__nocheck(ptr); ^ include/qemu/atomic.h:129:5: note: expanded from macro 'qatomic_read__nocheck' __atomic_load_n(ptr, __ATOMIC_RELAXED) ^ include/qemu/atomic.h:473:5: warning: misaligned atomic operation may incur significant performance penalty [-Watomic-alignment] qatomic_set__nocheck(ptr, val); ^ include/qemu/atomic.h:138:5: note: expanded from macro 'qatomic_set__nocheck' __atomic_store_n(ptr, i, __ATOMIC_RELAXED) ^ 2 warnings generated. [...] If I use '--extra-cflags=-Wno-atomic-alignment' I get: ERROR: Your compiler does not support the __thread specifier for Thread-Local Storage (TLS). Please upgrade to a version that does. So ignoring these warnings for now. 4/ libatomic on 32-bit hosts (i386, riscv32? arm?) While compiling succeed, linking fails: [850/2216] Linking target tests/test-hbitmap FAILED: tests/test-hbitmap clang -o tests/test-hbitmap tests/test-hbitmap.p/test-hbitmap.c.o tests/test-hbitmap.p/iothread.c.o -Wl,--as-needed -Wl,--no-undefined -pie -Wl,--whole-archive libblock.fa libcrypto.fa libauthz.fa libqom.fa libio.fa -Wl,--no-whole-archive -Wl,--warn-common -fsanitize=undefined -fsanitize=address -Wl,-z,relro -Wl,-z,now -m32 -ggdb -fstack-protector-strong -Wl,--start-group libqemuutil.a subprojects/libvhost-user/libvhost-user-glib.a subprojects/libvhost-user/libvhost-user.a libblock.fa libcrypto.fa libauthz.fa libqom.fa libio.fa @block.syms -lgio-2.0 -lgobject-2.0 -lglib-2.0 -lgio-2.0 -lgobject-2.0 -lglib-2.0 -pthread -lutil -lgnutls -lm -lgthread-2.0 -lglib-2.0 /usr/lib/i386-linux-gnu/libglib-2.0.so -liscsi -lgthread-2.0 -lglib-2.0 -laio -lcurl /usr/lib/i386-linux-gnu/libz.so -lrbd -lrados -lnettle -lgnutls -Wl,--end-group libblock.fa(block_io.c.o): In function `stat64_max': include/qemu/stats64.h:58: undefined reference to `__atomic_load_8' include/qemu/stats64.h:60: undefined reference to `__atomic_compare_exchange_8' libblock.fa(block_qapi.c.o): In function `stat64_get': include/qemu/stats64.h:40: undefined reference to `__atomic_load_8' libqemuutil.a(util_qsp.c.o): In function `qatomic_set_u64': include/qemu/atomic.h:478: undefined reference to `__atomic_store_8' libqemuutil.a(util_qsp.c.o): In function `qatomic_read_u64': include/qemu/atomic.h:468: undefined reference to `__atomic_load_8' clang: error: linker command failed with exit code 1 (use -v to see invocation) Googling I found similar references on riscv32 and arm (not i386). Without understanding much, I tried that snippet which made linking succeed: -- >8 -- diff --git a/meson.build b/meson.build index 372576f82c5..1a5da5ee56b 100644 --- a/meson.build +++ b/meson.build @@ -161,6 +161,9 @@ error('Multipath is supported only on Linux') endif +if 'CONFIG_ATOMIC64' in config_host + atomic = cc.find_library('atomic', required: config_host['ARCH'] in ['i386', 'arm', 'riscv32']) +endif m = cc.find_library('m', required: false) util = cc.find_library('util', required: false) winmm = [] @@ -1534,7 +1537,7 @@ util_ss = util_ss.apply(config_all, strict: false) libqemuutil = static_library('qemuutil', sources: util_ss.sources() + stub_ss.sources() + genh, - dependencies: [util_ss.dependencies(), m, glib, socket, malloc]) + dependencies: [util_ss.dependencies(), atomic, m, glib, socket, malloc]) qemuutil = declare_dependency(link_with: libqemuutil, sources: genh + version_res) --- 5/ DEADLYSIGNAL with Clang 6 Running test check-qstring AddressSanitizer:DEADLYSIGNAL ================================================================= ==10041==ERROR: AddressSanitizer: SEGV on unknown address 0xb7f6be40 (pc 0xb7f6be54 bp 0xbff08ebc sp 0xbff08e7c T16777215) ==10041==The signal is caused by a WRITE memory access. #0 0xb7f6be53 (/lib/ld-linux.so.2+0x11e53) #1 0x5e26c9 (/build/tests/check-qstring+0x1156c9) #2 0x5c4d32 (/build/tests/check-qstring+0xf7d32) #3 0xb7f698ea (/lib/ld-linux.so.2+0xf8ea) #4 0xb7f5acb9 (/lib/ld-linux.so.2+0xcb9) $ clang -v clang version 6.0.0-1ubuntu2 (tags/RELEASE_600/final) Using clang-10 works: -- >8 -- --- a/tests/vm/ubuntu.i386 +++ b/tests/vm/ubuntu.i386 @@ -18,7 +18,7 @@ import ubuntuvm DEFAULT_CONFIG = { 'install_cmds' : "apt-get update,"\ "apt-get build-dep -y qemu,"\ - "apt-get install -y libfdt-dev language-pack-en ninja-build", + "apt-get install -y clang-10 libfdt-dev language-pack-en ninja-build", } class UbuntuX86VM(ubuntuvm.UbuntuVM): --- 6/ LeakSanitizer: detected memory leaks Apparently LeakSanitizer is only enabled by default on Linux hosts, which is why Peter's OSX succeed: Running test qtest-mips64el/display-vga-test ==9541==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases! ================================================================= ==9541==ERROR: LeakSanitizer: detected memory leaks Direct leak of 4 byte(s) in 1 object(s) allocated from: #0 0xe82f75 in malloc (/tmp/tmp.rYOegFC8Gl/build/qemu-system-mips64el+0xa0ef75) #1 0xb7adf4a8 in g_malloc (/usr/lib/i386-linux-gnu/libglib-2.0.so.0+0x4e4a8) #2 0x3a870c0 in qemu_allocate_irqs hw/core/irq.c:66:12 #3 0x1e5fafa in piix4_realize hw/isa/piix4.c:171:21 #4 0xee0d52 in pci_qdev_realize hw/pci/pci.c:2125:9 #5 0x3a79c69 in device_set_realized hw/core/qdev.c:761:13 #6 0x33838ea in property_set_bool qom/object.c:2254:5 #7 0x337b093 in object_property_set qom/object.c:1399:5 #8 0x3392272 in object_property_set_qobject qom/qom-qobject.c:28:10 #9 0x337c040 in object_property_set_bool qom/object.c:1469:15 #10 0x3a6d628 in qdev_realize hw/core/qdev.c:389:12 #11 0x3a6d685 in qdev_realize_and_unref hw/core/qdev.c:396:11 #12 0xec73c2 in pci_realize_and_unref hw/pci/pci.c:2192:12 #13 0xec7bc4 in pci_create_simple_multifunction hw/pci/pci.c:2200:5 #14 0x1e5ecad in piix4_create hw/isa/piix4.c:245:11 #15 0x2414e9d in mips_malta_init hw/mips/malta.c:1407:11 #16 0x1ec1c82 in machine_run_board_init hw/core/machine.c:1169:5 #17 0x310a8ab in qemu_init_board softmmu/vl.c:2455:5 #18 0x3109eca in qmp_x_exit_preconfig softmmu/vl.c:2526:5 #19 0x31150c9 in qemu_init softmmu/vl.c:3534:9 #20 0xeb6bcc in main softmmu/main.c:49:5 #21 0xb6c16f20 in __libc_start_main (/lib/i386-linux-gnu/libc.so.6+0x18f20) SUMMARY: AddressSanitizer: 4 byte(s) leaked in 1 allocation(s). ../tests/qtest/libqtest.c:172: kill_qemu() tried to terminate QEMU process but encountered exit status 1 (expected 0) ERROR qtest-mips64el/display-vga-test - too few tests run (expected 4, got 0) Makefile.mtest:897: recipe for target 'run-test-110' failed We can ignore by passing ASAN_OPTIONS=detect_leaks=0 to the environment: -- >8 --- diff --git a/tests/vm/basevm.py b/tests/vm/basevm.py index 00f1d5ca8da..12ba39fcf2b 100644 --- a/tests/vm/basevm.py +++ b/tests/vm/basevm.py @@ -71,6 +71,7 @@ class BaseVM(object): "http_proxy", "ftp_proxy", "no_proxy", + "ASAN_OPTIONS", ] # The script to run in the guest that builds QEMU --- 7/ Reproducer, finally! I could finally reproduce Peter's report with this command (and all the previous snippet applied): $ make vm-build-ubuntu.i386 EXTRA_CONFIGURE_OPTS='--extra-cflags=-ggdb --disable-docs --disable-tools --enable-debug --cc=clang-10 --cxx=clang++-10 --enable-sanitizers' TARGET_LIST=mips64el-softmmu DEBUG=1 ASAN_OPTIONS=detect_leaks=0 [...] /mips64el/qom/loongson3-virt: ==9671==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases! ================================================================= ==9671==ERROR: AddressSanitizer: heap-buffer-overflow on address 0xacc001c8 at pc 0x023f47e2 bp 0xbfcdfad8 sp 0xbfcdfad0 WRITE of size 4 at 0xacc001c8 thread T0 #0 0x23f47e1 in loongson3_virt_devices_init hw/mips/loongson3_virt.c:420:19 #1 0x23f1a75 in mips_loongson3_virt_init hw/mips/loongson3_virt.c:612:5 #2 0x1e84c82 in machine_run_board_init hw/core/machine.c:1169:5 #3 0x30cd8ab in qemu_init_board softmmu/vl.c:2455:5 #4 0x30cceca in qmp_x_exit_preconfig softmmu/vl.c:2526:5 #5 0x30d80c9 in qemu_init softmmu/vl.c:3534:9 #6 0xe79bcc in main softmmu/main.c:49:5 #7 0xb6c5af20 in __libc_start_main (/lib/i386-linux-gnu/libc.so.6+0x18f20) #8 0xdce738 in _start (qemu-system-mips64el+0x997738) 0xacc001c8 is located 8 bytes to the right of 160-byte region [0xacc00120,0xacc001c0) allocated by thread T0 here: #0 0xe45f75 in malloc (qemu-system-mips64el+0xa0ef75) #1 0xb7b234a8 in g_malloc (/usr/lib/i386-linux-gnu/libglib-2.0.so.0+0x4e4a8) #2 0x3332137 in object_new_with_class qom/object.c:737:12 #3 0x30e3fbe in qemu_create_machine softmmu/vl.c:2008:31 #4 0x30d7714 in qemu_init softmmu/vl.c:3469:5 #5 0xe79bcc in main softmmu/main.c:49:5 #6 0xb6c5af20 in __libc_start_main (/lib/i386-linux-gnu/libc.so.6+0x18f20) SUMMARY: AddressSanitizer: heap-buffer-overflow hw/mips/loongson3_virt.c:420:19 in loongson3_virt_devices_init Shadow bytes around the buggy address: 0x3597ffe0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x3597fff0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x35980000: fa fa fa fa fa fa fa fa 00 00 00 00 00 00 00 00 0x35980010: 00 00 00 00 00 00 00 00 00 00 04 fa fa fa fa fa 0x35980020: fa fa fa fa 00 00 00 00 00 00 00 00 00 00 00 00 =>0x35980030: 00 00 00 00 00 00 00 00 fa[fa]fa fa fa fa fa fa 0x35980040: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x35980050: 00 00 00 fa fa fa fa fa fa fa fa fa 00 00 00 00 0x35980060: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 fa 0x35980070: fa fa fa fa fa fa fa fa 00 00 00 00 00 00 00 00 0x35980080: 00 00 00 00 00 00 00 00 00 00 00 fa fa fa fa fa Shadow byte legend (one shadow byte represents 8 application bytes): Addressable: 00 Partially addressable: 01 02 03 04 05 06 07 Heap left redzone: fa Freed heap region: fd Stack left redzone: f1 Stack mid redzone: f2 Stack right redzone: f3 Stack after return: f5 Stack use after scope: f8 Global redzone: f9 Global init order: f6 Poisoned by user: f7 Container overflow: fc Array cookie: ac Intra object redzone: bb ASan internal: fe Left alloca redzone: ca Right alloca redzone: cb Shadow gap: cc ==9671==ABORTING Broken pipe ../tests/qtest/libqtest.c:172: kill_qemu() tried to terminate QEMU process but encountered exit status 1 (expected 0) Aborted (core dumped) Regards, Phil.
On Tue, 5 Jan 2021 at 09:36, Philippe Mathieu-Daudé <f4bug@amsat.org> wrote: > 4/ libatomic on 32-bit hosts (i386, riscv32? arm?) > > While compiling succeed, linking fails: > > [850/2216] Linking target tests/test-hbitmap > FAILED: tests/test-hbitmap > clang -o tests/test-hbitmap tests/test-hbitmap.p/test-hbitmap.c.o > tests/test-hbitmap.p/iothread.c.o -Wl,--as-needed -Wl,--no-undefined > -pie -Wl,--whole-archive libblock.fa libcrypto.fa libauthz.fa libqom.fa > libio.fa -Wl,--no-whole-archive -Wl,--warn-common -fsanitize=undefined > -fsanitize=address -Wl,-z,relro -Wl,-z,now -m32 -ggdb > -fstack-protector-strong -Wl,--start-group libqemuutil.a > subprojects/libvhost-user/libvhost-user-glib.a > subprojects/libvhost-user/libvhost-user.a libblock.fa libcrypto.fa > libauthz.fa libqom.fa libio.fa @block.syms -lgio-2.0 -lgobject-2.0 > -lglib-2.0 -lgio-2.0 -lgobject-2.0 -lglib-2.0 -pthread -lutil -lgnutls > -lm -lgthread-2.0 -lglib-2.0 /usr/lib/i386-linux-gnu/libglib-2.0.so > -liscsi -lgthread-2.0 -lglib-2.0 -laio -lcurl > /usr/lib/i386-linux-gnu/libz.so -lrbd -lrados -lnettle -lgnutls > -Wl,--end-group > libblock.fa(block_io.c.o): In function `stat64_max': > include/qemu/stats64.h:58: undefined reference to `__atomic_load_8' > include/qemu/stats64.h:60: undefined reference to > `__atomic_compare_exchange_8' > libblock.fa(block_qapi.c.o): In function `stat64_get': > include/qemu/stats64.h:40: undefined reference to `__atomic_load_8' > libqemuutil.a(util_qsp.c.o): In function `qatomic_set_u64': > include/qemu/atomic.h:478: undefined reference to `__atomic_store_8' > libqemuutil.a(util_qsp.c.o): In function `qatomic_read_u64': > include/qemu/atomic.h:468: undefined reference to `__atomic_load_8' > clang: error: linker command failed with exit code 1 (use -v to see > invocation) Historically we have not linked against libatomic on purpose, on the theory that QEMU should not be trying to use atomic operations that the compiler cannot directly open-code as native atomic instructions. (This is because we want things to work even if the code in another thread that might also be doing atomic operations on the data is TCG.) libatomic might choose to use a mutex under the hood, if my understanding/memory is correct, which obviously TCG won't. In particular this means that code that can run on 32-bit hosts is not supposed to be doing 64-bit atomic operations. For the code in stat64_max/stat64_get, this is guarded by CONFIG_ATOMIC64, which configure should only be setting if we can do 64-bit atomics without libatomic, so looking at whether that got set and if the test is doing the wrong thing would be my first suggestion. thanks -- PMM
On 1/5/21 2:17 PM, Peter Maydell wrote: > On Tue, 5 Jan 2021 at 09:36, Philippe Mathieu-Daudé <f4bug@amsat.org> wrote: >> 4/ libatomic on 32-bit hosts (i386, riscv32? arm?) >> >> While compiling succeed, linking fails: >> >> [850/2216] Linking target tests/test-hbitmap >> FAILED: tests/test-hbitmap >> clang -o tests/test-hbitmap tests/test-hbitmap.p/test-hbitmap.c.o >> tests/test-hbitmap.p/iothread.c.o -Wl,--as-needed -Wl,--no-undefined >> -pie -Wl,--whole-archive libblock.fa libcrypto.fa libauthz.fa libqom.fa >> libio.fa -Wl,--no-whole-archive -Wl,--warn-common -fsanitize=undefined >> -fsanitize=address -Wl,-z,relro -Wl,-z,now -m32 -ggdb >> -fstack-protector-strong -Wl,--start-group libqemuutil.a >> subprojects/libvhost-user/libvhost-user-glib.a >> subprojects/libvhost-user/libvhost-user.a libblock.fa libcrypto.fa >> libauthz.fa libqom.fa libio.fa @block.syms -lgio-2.0 -lgobject-2.0 >> -lglib-2.0 -lgio-2.0 -lgobject-2.0 -lglib-2.0 -pthread -lutil -lgnutls >> -lm -lgthread-2.0 -lglib-2.0 /usr/lib/i386-linux-gnu/libglib-2.0.so >> -liscsi -lgthread-2.0 -lglib-2.0 -laio -lcurl >> /usr/lib/i386-linux-gnu/libz.so -lrbd -lrados -lnettle -lgnutls >> -Wl,--end-group >> libblock.fa(block_io.c.o): In function `stat64_max': >> include/qemu/stats64.h:58: undefined reference to `__atomic_load_8' >> include/qemu/stats64.h:60: undefined reference to >> `__atomic_compare_exchange_8' >> libblock.fa(block_qapi.c.o): In function `stat64_get': >> include/qemu/stats64.h:40: undefined reference to `__atomic_load_8' >> libqemuutil.a(util_qsp.c.o): In function `qatomic_set_u64': >> include/qemu/atomic.h:478: undefined reference to `__atomic_store_8' >> libqemuutil.a(util_qsp.c.o): In function `qatomic_read_u64': >> include/qemu/atomic.h:468: undefined reference to `__atomic_load_8' >> clang: error: linker command failed with exit code 1 (use -v to see >> invocation) > > Historically we have not linked against libatomic on purpose, > on the theory that QEMU should not be trying to use atomic > operations that the compiler cannot directly open-code as > native atomic instructions. (This is because we want things > to work even if the code in another thread that might also be > doing atomic operations on the data is TCG.) libatomic might > choose to use a mutex under the hood, if my understanding/memory > is correct, which obviously TCG won't. > > In particular this means that code that can run on 32-bit hosts > is not supposed to be doing 64-bit atomic operations. For the > code in stat64_max/stat64_get, this is guarded by CONFIG_ATOMIC64, > which configure should only be setting if we can do 64-bit atomics > without libatomic, so looking at whether that got set and if the > test is doing the wrong thing would be my first suggestion. That makes sense. So on a Ubuntu 18.04 i386 host, "configure --cc=clang-10 --enable-sanitizers' sets atomic64=yes (__ATOMIC_RELAXED is also defined). The ./configure check is simple. There is a lot of ifdef'ry to follow in "qemu/osdep.h" and "qemu/compiler.h" so it is hard to figure out what changes "qemu/atomic.h" that it doesn't match with ./configure. Maybe a issue with the sanitizer code? Cc'ing Stefan, Emilio & Marc-André too :)
The following changes since commit 83734919c408ba02adb6ea616d68cd1a72837fbe: Merge remote-tracking branch 'remotes/cohuck-gitlab/tags/s390x-20201222' into staging (2021-01-01 18:19:44 +0000) are available in the Git repository at: https://gitlab.com/philmd/qemu.git tags/mips-20210103 for you to fetch changes up to 9c592996981fcb37fef011d7e9603cb31f8ef29f: tests/acceptance: Test boot_linux_console for fuloong2e (2021-01-03 21:41:03 +0100) ---------------------------------------------------------------- MIPS patches queue - Use PCI macros (Philippe Mathieu-Daudé) - Clean up VT82C686B south bridge (BALATON Zoltan) - Introduce clock_ticks_to_ns() (Peter Maydell) - Add Loongson-3 machine (Huacai Chen) - Make addresses used by bootloader unsigned (Jiaxun Yang) - Clean fuloong2e PROM environment (Jiaxun Yang) - Add integration test of fuloong2e booting Linux (Jiaxun Yang) ---------------------------------------------------------------- BALATON Zoltan (12): vt82c686: Rename AC97/MC97 parts from VT82C686B to VIA vt82c686: Remove unnecessary _DEVICE suffix from type macros vt82c686: Rename VT82C686B to VT82C686B_ISA vt82c686: Remove vt82c686b_[am]c97_init() functions vt82c686: Split off via-[am]c97 into separate file in hw/audio audio/via-ac97: Simplify code and set user_creatable to false vt82c686: Remove legacy vt82c686b_isa_init() function vt82c686: Remove legacy vt82c686b_pm_init() function vt82c686: Convert debug printf to trace points vt82c686: Remove unneeded includes and defines vt82c686: Use shorter name for local variable holding object state vt82c686: Rename superio config related parts Huacai Chen (5): hw/intc: Rework Loongson LIOINTC hw/mips: Implement fw_cfg_arch_key_name() hw/mips: Add Loongson-3 boot parameter helpers hw/mips: Add Loongson-3 machine support docs/system: Update MIPS machine documentation Jiaxun Yang (8): hw/mips: Make bootloader addresses unsigned hw/mips/malta: Use address translation helper to calculate bootloader_run_addr hw/mips: Use address translation helper to handle ENVP_ADDR hw/mips/fuloong2e: Remove define DEBUG_FULOONG2E_INIT hw/mips/fuloong2e: Replace faulty documentation links hw/mips/fuloong2e: Remove unused env entry hw/mips/fuloong2e: Correct cpuclock in PROM environment tests/acceptance: Test boot_linux_console for fuloong2e Peter Maydell (4): clock: Introduce clock_ticks_to_ns() target/mips: Don't use clock_get_ns() in clock period calculation clock: Remove clock_get_ns() clock: Define and use new clock_display_freq() Philippe Mathieu-Daudé (6): hw/pci-host: Use the PCI_BUILD_BDF() macro from 'hw/pci/pci.h' hw/pci-host/uninorth: Use the PCI_FUNC() macro from 'hw/pci/pci.h' hw: Use the PCI_SLOT() macro from 'hw/pci/pci.h' hw: Use the PCI_DEVFN() macro from 'hw/pci/pci.h' hw/pci-host/bonito: Display hexadecimal value with '0x' prefix hw/pci-host/bonito: Use pci_config_set_interrupt_pin() docs/devel/clocks.rst | 51 +- docs/system/target-mips.rst | 10 + default-configs/devices/mips64el-softmmu.mak | 1 + hw/mips/fw_cfg.h | 19 + hw/mips/loongson3_bootp.h | 241 +++++++ include/hw/clock.h | 53 +- include/hw/intc/loongson_liointc.h | 22 + include/hw/isa/vt82c686.h | 12 +- hw/arm/virt.c | 3 +- hw/audio/via-ac97.c | 93 +++ hw/core/clock.c | 6 + hw/hppa/dino.c | 2 +- hw/i386/xen/xen-hvm.c | 2 +- hw/intc/loongson_liointc.c | 36 +- hw/isa/piix3.c | 2 +- hw/isa/vt82c686.c | 267 ++------ hw/mips/fuloong2e.c | 69 +- hw/mips/fw_cfg.c | 35 ++ hw/mips/gt64xxx_pci.c | 2 +- hw/mips/loongson3_bootp.c | 151 +++++ hw/mips/loongson3_virt.c | 627 +++++++++++++++++++ hw/mips/malta.c | 88 +-- hw/mips/mipssim.c | 8 +- hw/pci-host/bonito.c | 14 +- hw/pci-host/pnv_phb4.c | 2 +- hw/pci-host/ppce500.c | 2 +- hw/pci-host/uninorth.c | 8 +- hw/ppc/ppc4xx_pci.c | 2 +- hw/sh4/sh_pci.c | 2 +- softmmu/qdev-monitor.c | 6 +- target/mips/cpu.c | 4 +- MAINTAINERS | 3 + hw/audio/meson.build | 1 + hw/isa/trace-events | 6 + hw/mips/Kconfig | 15 + hw/mips/meson.build | 2 + tests/acceptance/boot_linux_console.py | 21 + 37 files changed, 1526 insertions(+), 362 deletions(-) create mode 100644 hw/mips/fw_cfg.h create mode 100644 hw/mips/loongson3_bootp.h create mode 100644 include/hw/intc/loongson_liointc.h create mode 100644 hw/audio/via-ac97.c create mode 100644 hw/mips/fw_cfg.c create mode 100644 hw/mips/loongson3_bootp.c create mode 100644 hw/mips/loongson3_virt.c