On Mon, 22 Mar 2021 at 16:41, Peter Maydell <peter.mayd...@linaro.org> wrote:
>
> On Mon, 22 Mar 2021 at 15:44, Michael S. Tsirkin <m...@redhat.com> wrote:
> >
> > The following changes since commit f0f20022a0c744930935fdb7020a8c18347d391a:
> >
> > Merge remote-tracking branch
> > 'remotes/thuth-gitlab/tags/pull-request-2021-03-21' into staging
> > (2021-03-22 10:05:45 +0000)
> >
> > are available in the Git repository at:
> >
> > git://git.kernel.org/pub/scm/virt/kvm/mst/qemu.git tags/for_upstream
> >
> > for you to fetch changes up to 5971d4a968d51a80daaad53ddaec2b285115af62:
> >
> > acpi: Move setters/getters of oem fields to X86MachineState (2021-03-22
> > 11:39:02 -0400)
> >
> > ----------------------------------------------------------------
> > pc,virtio,pci: fixes, features
> >
> > Fixes all over the place.
> > ACPI index support.
> >
> > Signed-off-by: Michael S. Tsirkin <m...@redhat.com>
> >
>
> This triggers a new clang runtime sanitizer warning:
With a backtrace:
$ UBSAN_OPTIONS=print_stacktrace=1
QTEST_QEMU_BINARY=build/clang/qemu-system-mips64el
./build/clang/tests/qtest/endianness-test -p
/mips64el/endianness/fuloong2e
/mips64el/endianness/fuloong2e: ../../hw/pci/pci.c:252:30: runtime
error: shift exponent -1 is negative
#0 0x55a17bc17a1f in pci_irq_state
/home/petmay01/linaro/qemu-for-merges/build/clang/../../hw/pci/pci.c:252:30
#1 0x55a17bc17a1f in pci_irq_handler
/home/petmay01/linaro/qemu-for-merges/build/clang/../../hw/pci/pci.c:1453
#2 0x55a17b7ed0a5 in pm_update_sci
/home/petmay01/linaro/qemu-for-merges/build/clang/../../hw/isa/vt82c686.c:147:5
#3 0x55a17b7ecce3 in via_pm_reset
/home/petmay01/linaro/qemu-for-merges/build/clang/../../hw/isa/vt82c686.c:173:5
#4 0x55a17c546cc7 in resettable_phase_hold
/home/petmay01/linaro/qemu-for-merges/build/clang/../../hw/core/resettable.c:182:13
#5 0x55a17c53839a in bus_reset_child_foreach
/home/petmay01/linaro/qemu-for-merges/build/clang/../../hw/core/bus.c:97:13
#6 0x55a17c546bc2 in resettable_phase_hold
/home/petmay01/linaro/qemu-for-merges/build/clang/../../hw/core/resettable.c:173:5
#7 0x55a17c5435ca in device_reset_child_foreach
/home/petmay01/linaro/qemu-for-merges/build/clang/../../hw/core/qdev.c:366:9
#8 0x55a17c546bc2 in resettable_phase_hold
/home/petmay01/linaro/qemu-for-merges/build/clang/../../hw/core/resettable.c:173:5
#9 0x55a17c53839a in bus_reset_child_foreach
/home/petmay01/linaro/qemu-for-merges/build/clang/../../hw/core/bus.c:97:13
#10 0x55a17c546bc2 in resettable_phase_hold
/home/petmay01/linaro/qemu-for-merges/build/clang/../../hw/core/resettable.c:173:5
#11 0x55a17c545ee0 in resettable_assert_reset
/home/petmay01/linaro/qemu-for-merges/build/clang/../../hw/core/resettable.c:60:5
#12 0x55a17c545dbf in resettable_reset
/home/petmay01/linaro/qemu-for-merges/build/clang/../../hw/core/resettable.c:45:5
#13 0x55a17c545d68 in qemu_devices_reset
/home/petmay01/linaro/qemu-for-merges/build/clang/../../hw/core/reset.c:69:9
#14 0x55a17c47b3eb in qemu_system_reset
/home/petmay01/linaro/qemu-for-merges/build/clang/../../softmmu/runstate.c:444:9
#15 0x55a17ba225ee in qdev_machine_creation_done
/home/petmay01/linaro/qemu-for-merges/build/clang/../../hw/core/machine.c:1279:5
#16 0x55a17c4bdb03 in qemu_machine_creation_done
/home/petmay01/linaro/qemu-for-merges/build/clang/../../softmmu/vl.c:2567:5
#17 0x55a17c4bdb03 in qmp_x_exit_preconfig
/home/petmay01/linaro/qemu-for-merges/build/clang/../../softmmu/vl.c:2590
#18 0x55a17c4c2c0b in qemu_init
/home/petmay01/linaro/qemu-for-merges/build/clang/../../softmmu/vl.c:3611:9
#19 0x55a17b756db5 in main
/home/petmay01/linaro/qemu-for-merges/build/clang/../../softmmu/main.c:49:5
#20 0x7f3a9c9f6bf6 in __libc_start_main
/build/glibc-S9d2JN/glibc-2.27/csu/../csu/libc-start.c:310
#21 0x55a17b731969 in _start
(/home/petmay01/linaro/qemu-for-merges/build/clang/qemu-system-mips64el+0x1140969)
OK
Suggests the relevant commit is
"acpi:piix4, vt82c686: reinitialize acpi PM device on reset"
This happens because pm_update_sci() calls pci_irq_handler(),
which calls pci_intx(pci_dev), which returns -1, which is not
a valid interrupt number to call pci_irq_handler() with.
Q: given that pci_irq_handler() says it must only be called with
an irqnum in [0..3], shouldn't pci_set_irq() be a bit more
cautious than to pull a byte directly out of PCI_INTERRUPT_PIN
and assume it's valid? (Is this guest-writable, or is it read-only?)
thanks
-- PMM
