Re: [PULL 00/20] pc,virtio,pci: fixes, features

[Peter Maydell]

On Mon, 22 Mar 2021 at 16:41, Peter Maydell <peter.maydell@linaro.org> wrote:
>
> On Mon, 22 Mar 2021 at 15:44, Michael S. Tsirkin <mst@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 <mst@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