On Mon, 15 Apr 2024 16:18:22 +0200 Ricardo Ribalda <ribalda@xxxxxxxxxx> wrote: > Hi Igor, Hi Rafael > > Yes, it seems that it is just KASAN being extremely slow. > From a completely newbie here... Is there a reason why qemu generates > the table vs returning a precomputed one? it can be a pre-generated Package like we do with ARM (example: acpi_dsdt_add_pci_route_table) > This is the config file: > https://gitlab.freedesktop.org/linux-media/media-ci/-/blob/main/testdata/virtme/virtme.config?ref_type=heads > > And this is the qemu cli: > > /usr/bin/qemu-system-x86_64 -m 4G -fsdev > local,id=virtfs3,path=/,security_model=none,readonly=on,multidevs=remap > -device virtio-9p-pci,fsdev=virtfs3,mount_tag=/dev/root -device > i6300esb,id=watchdog0 -parallel none -net none -smp 2 -vga none > -display none -serial chardev:console -chardev > file,id=console,path=/proc/self/fd/2 -chardev > stdio,id=stdin,signal=on,mux=off -device virtio-serial-pci -device > virtserialport,name=virtme.stdin,chardev=stdin -chardev > file,id=stdout,path=/proc/self/fd/1 -device virtio-serial-pci -device > virtserialport,name=virtme.stdout,chardev=stdout -chardev > file,id=stderr,path=/proc/self/fd/2 -device virtio-serial-pci -device > virtserialport,name=virtme.stderr,chardev=stderr -chardev > file,id=dev_stdout,path=/proc/self/fd/1 -device virtio-serial-pci > -device virtserialport,name=virtme.dev_stdout,chardev=dev_stdout > -chardev file,id=dev_stderr,path=/proc/self/fd/2 -device > virtio-serial-pci -device > virtserialport,name=virtme.dev_stderr,chardev=dev_stderr -chardev > file,id=ret,path=/tmp/virtme_retefeobj4f -device virtio-serial-pci > -device virtserialport,name=virtme.ret,chardev=ret -no-reboot -kernel > ./arch/x86/boot/bzImage -append 'nr_open=1048576 > virtme_link_mods=/builds/linux-media/media-staging/.virtme_mods/lib/modules/0.0.0 > console=ttyS0 earlyprintk=serial,ttyS0,115200 panic=-1 > virtme.exec=`c2ggL21lZGlhLWNpL3Rlc3RkYXRhL3ZpcnRtZS90ZXN0LnNoIC9tZWRpYS1jaS90aGlyZF9wYXJ0eS92NGwtdXRpbHMgLTMy` > virtme_root_user=1 rootfstype=9p > rootflags=version=9p2000.L,trans=virtio,access=any raid=noautodetect > ro init=/usr/lib/python3/dist-packages/virtme/guest/virtme-init' boots fine for me on old Xeon E5-2630v3. Perhaps issue is that your host is too slow, is there reason not to use KVM instead of TCG? Alternatively you can try using q35 machine type instead of default 'pc', it doesn't have _PRT in simple configuration like yours. But then running things that depend on time is not reliable under TCG, so you might hit timeout elsewhere. > > Regards! > > On Mon, 15 Apr 2024 at 14:55, Rafael J. Wysocki <rafael@xxxxxxxxxx> wrote: > > > > On Mon, Apr 15, 2024 at 2:52 PM Igor Mammedov <imammedo@xxxxxxxxxx> wrote: > > > > > > On Sun, 14 Apr 2024 04:37:24 -0400 > > > "Michael S. Tsirkin" <mst@xxxxxxxxxx> wrote: > > > > > > > On Fri, Apr 12, 2024 at 11:43:22PM +0200, Ricardo Ribalda wrote: > > > > > Hi > > > > > > > > > > I am using virtme to do some CI around linux-media. > > > > > > > > > > Everything works as expected, but when I enable KASAN, I am starting > > > > > to get a lot of timeouts when the Method _PRT is executed. Eg: > > > > > > > > > > [ 56.335875] ACPI Error: Aborting method \_SB.PCI0._PRT due to > > > > > previous error (AE_AML_LOOP_TIMEOUT) (20230628/psparse-529) > > > > > [ 56.529826] ACPI Error: Method execution failed \_SB.PCI0._PRT due > > > > > to previous error (AE_AML_LOOP_TIMEOUT) (20230628/uteval-68) > > > > > [ 56.532391] virtio-pci 0000:00:02.0: can't derive routing for PCI INT A > > > > > [ 56.532823] virtio-pci 0000:00:02.0: PCI INT A: no GSI > > > > > [ 86.877471] ACPI Error: Aborting method \_SB.PCI0._PRT due to > > > > > previous error (AE_AML_LOOP_TIMEOUT) (20230628/psparse-529) > > > > > [ 87.073854] ACPI Error: Method execution failed \_SB.PCI0._PRT due > > > > > to previous error (AE_AML_LOOP_TIMEOUT) (20230628/uteval-68) > > > > > [ 87.075550] virtio-pci 0000:00:04.0: can't derive routing for PCI INT A > > > > > [ 87.075810] virtio-pci 0000:00:04.0: PCI INT A: no GSI > > > > > > > > > > 0000:00:04.0 and 0000:00:02.0 are virtio devices (console and 9p-filesystem) > > > > > > > > > > If I increase the timeout (ACPI_MAX_LOOP_TIMEOUT), then the Method is > > > > > always executed, but it is very annoying that I have to wait more than > > > > > 5 minutes to start the vm. > > > > > > > > > > Despite not having kvm enabled, the machine is quite decent, so I > > > > > would expect that it could run that method relatively fast. > > > > > > > > > > Do you have any hint of what I should be looking at? > > > > > > The way QEMU generates _PRT haven't been changed for ages, > > > it's not likely to be a culprit. > > > > > > CCing Rafael who might have an idea why ACPI misbehaves. > > > > It looks like the method evaluation time increases with KASAN enabled > > and it gets aborted due to exceeding the evaluation time limit. > > > > Thanks! > > >
