Hi Igor On Tue, 16 Apr 2024 at 13:33, Igor Mammedov <imammedo@xxxxxxxxxx> wrote: > > 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? I am using a e2 instance that does not support nested virtualization :( > > 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. I will give it a try... but you are correct, if this is running this slow I expect that nothing from my CI will work reliably. Thanks! > > > > > 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! > > > > > > > -- Ricardo Ribalda
