| Message ID | 20230213101759.2577077-31-nikos.nikoleris@arm.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | EFI and ACPI support for arm64 | expand |
On Mon, Feb 13, 2023 at 10:17:59AM +0000, Nikos Nikoleris wrote: > This change adds a efi/run script inspired by the one in x86. This > script will setup a folder with the test compiled as an EFI app and a > startup.nsh script. The script launches QEMU providing an image with > EDKII and the path to the folder with the test which is executed > automatically. > > For example: > > $> ./arm/efi/run ./arm/selftest.efi setup smp=2 mem=256 This should be ./arm/efi/run ./arm/selftest.efi -append "setup smp=2 mem=256" -smp 2 -m 256 but I can't get any tests to run through ./arm/efi/run. All of them immediately die with a DABT_EL1. I can get the tests to run (and pass) by manually booting into UEFI with the FAT partition pointing at the parent directory $QEMU -nodefaults -machine virt -accel tcg -cpu cortex-a57 \ -device pci-testdev -display none -serial stdio \ -bios /usr/share/edk2/aarch64/QEMU_EFI.silent.fd \ -drive file.dir=efi-tests/,file.driver=vvfat,file.rw=on,format=raw,if=virtio and then, for example for the timer test, doing fs0: cd timer timer.efi but the script never works. Thanks, drew
Hi Drew, On 21/03/2023 18:41, Andrew Jones wrote: > On Mon, Feb 13, 2023 at 10:17:59AM +0000, Nikos Nikoleris wrote: >> This change adds a efi/run script inspired by the one in x86. This >> script will setup a folder with the test compiled as an EFI app and a >> startup.nsh script. The script launches QEMU providing an image with >> EDKII and the path to the folder with the test which is executed >> automatically. >> >> For example: >> >> $> ./arm/efi/run ./arm/selftest.efi setup smp=2 mem=256 > > This should be > > ./arm/efi/run ./arm/selftest.efi -append "setup smp=2 mem=256" -smp 2 -m 256 > Indeed, I will update the commit message. > but I can't get any tests to run through ./arm/efi/run. All of them > immediately die with a DABT_EL1. I can get the tests to run (and pass) by > manually booting into UEFI with the FAT partition pointing at the parent > directory > I suppose the DABT_EL1 is happening after the test has started and not while the UEFI interactive shell starts? > $QEMU -nodefaults -machine virt -accel tcg -cpu cortex-a57 \ > -device pci-testdev -display none -serial stdio \ > -bios /usr/share/edk2/aarch64/QEMU_EFI.silent.fd \ > -drive file.dir=efi-tests/,file.driver=vvfat,file.rw=on,format=raw,if=virtio > Do you hit the DABT_EL1 if you let it automatically start using the startup.nsh prepared by the ./arm/efi/run script? Meaning change the above command if you provided -drive file.dir=efi-tests/timer instead: $QEMU -nodefaults -machine virt -accel tcg -cpu cortex-a57 \ -device pci-testdev -display none -serial stdio \ -bios /usr/share/edk2/aarch64/QEMU_EFI.silent.fd \ -drive file.dir=efi tests/timer,file.driver=vvfat,file.rw=on,format=raw,if=virtio Thanks for reviewing this! Nikos > and then, for example for the timer test, doing > > fs0: > cd timer > timer.efi > > but the script never works. > > Thanks, > drew
On Wed, Mar 22, 2023 at 10:02:35AM +0000, Nikos Nikoleris wrote: > Hi Drew, > > On 21/03/2023 18:41, Andrew Jones wrote: > > On Mon, Feb 13, 2023 at 10:17:59AM +0000, Nikos Nikoleris wrote: > > > This change adds a efi/run script inspired by the one in x86. This > > > script will setup a folder with the test compiled as an EFI app and a > > > startup.nsh script. The script launches QEMU providing an image with > > > EDKII and the path to the folder with the test which is executed > > > automatically. > > > > > > For example: > > > > > > $> ./arm/efi/run ./arm/selftest.efi setup smp=2 mem=256 > > > > This should be > > > > ./arm/efi/run ./arm/selftest.efi -append "setup smp=2 mem=256" -smp 2 -m 256 > > > > Indeed, I will update the commit message. > > > but I can't get any tests to run through ./arm/efi/run. All of them > > immediately die with a DABT_EL1. I can get the tests to run (and pass) by > > manually booting into UEFI with the FAT partition pointing at the parent > > directory > > > > I suppose the DABT_EL1 is happening after the test has started and not while > the UEFI interactive shell starts? The countdown completes and the startup script runs (I can add an echo to check it). So it must be the test that fails. > > > $QEMU -nodefaults -machine virt -accel tcg -cpu cortex-a57 \ > > -device pci-testdev -display none -serial stdio \ > > -bios /usr/share/edk2/aarch64/QEMU_EFI.silent.fd \ > > -drive file.dir=efi-tests/,file.driver=vvfat,file.rw=on,format=raw,if=virtio > > > > Do you hit the DABT_EL1 if you let it automatically start using the > startup.nsh prepared by the ./arm/efi/run script? Meaning change the above > command if you provided -drive file.dir=efi-tests/timer instead: > > $QEMU -nodefaults -machine virt -accel tcg -cpu cortex-a57 \ > -device pci-testdev -display none -serial stdio \ > -bios /usr/share/edk2/aarch64/QEMU_EFI.silent.fd \ > -drive file.dir=efi > tests/timer,file.driver=vvfat,file.rw=on,format=raw,if=virtio Yes, this is what ./arm/efi/run does, and it doesn't help to use the command line directly. > > Thanks for reviewing this! > > Nikos > > > and then, for example for the timer test, doing > > > > fs0: > > cd timer > > timer.efi This actually doesn't work. I was actually doing fs0: cd timer ls timer.efi and, believe it or not, without the 'ls' I get the dabt, with the 'ls' the test runs and passes. Adding an 'ls' to the startup script doesn't help the automatic execution though. Which versions of QEMU and edk2 are you using? And what file system do you have the efi-tests directory on? Thanks, drew > > > > but the script never works. > > > > Thanks, > > drew
On 22/03/2023 11:24, Andrew Jones wrote: > On Wed, Mar 22, 2023 at 10:02:35AM +0000, Nikos Nikoleris wrote: >> Hi Drew, >> >> On 21/03/2023 18:41, Andrew Jones wrote: >>> On Mon, Feb 13, 2023 at 10:17:59AM +0000, Nikos Nikoleris wrote: >>>> This change adds a efi/run script inspired by the one in x86. This >>>> script will setup a folder with the test compiled as an EFI app and a >>>> startup.nsh script. The script launches QEMU providing an image with >>>> EDKII and the path to the folder with the test which is executed >>>> automatically. >>>> >>>> For example: >>>> >>>> $> ./arm/efi/run ./arm/selftest.efi setup smp=2 mem=256 >>> >>> This should be >>> >>> ./arm/efi/run ./arm/selftest.efi -append "setup smp=2 mem=256" -smp 2 -m 256 >>> >> >> Indeed, I will update the commit message. >> >>> but I can't get any tests to run through ./arm/efi/run. All of them >>> immediately die with a DABT_EL1. I can get the tests to run (and pass) by >>> manually booting into UEFI with the FAT partition pointing at the parent >>> directory >>> >> >> I suppose the DABT_EL1 is happening after the test has started and not while >> the UEFI interactive shell starts? > > The countdown completes and the startup script runs (I can add an echo to > check it). So it must be the test that fails. > >> >>> $QEMU -nodefaults -machine virt -accel tcg -cpu cortex-a57 \ >>> -device pci-testdev -display none -serial stdio \ >>> -bios /usr/share/edk2/aarch64/QEMU_EFI.silent.fd \ >>> -drive file.dir=efi-tests/,file.driver=vvfat,file.rw=on,format=raw,if=virtio >>> >> >> Do you hit the DABT_EL1 if you let it automatically start using the >> startup.nsh prepared by the ./arm/efi/run script? Meaning change the above >> command if you provided -drive file.dir=efi-tests/timer instead: >> >> $QEMU -nodefaults -machine virt -accel tcg -cpu cortex-a57 \ >> -device pci-testdev -display none -serial stdio \ >> -bios /usr/share/edk2/aarch64/QEMU_EFI.silent.fd \ >> -drive file.dir=efi >> tests/timer,file.driver=vvfat,file.rw=on,format=raw,if=virtio > > Yes, this is what ./arm/efi/run does, and it doesn't help to use the > command line directly. > >> >> Thanks for reviewing this! >> >> Nikos >> >>> and then, for example for the timer test, doing >>> >>> fs0: >>> cd timer >>> timer.efi > > This actually doesn't work. I was actually doing > > fs0: > cd timer > ls > timer.efi > > and, believe it or not, without the 'ls' I get the dabt, with the 'ls' the > test runs and passes. Adding an 'ls' to the startup script doesn't help > the automatic execution though. > > Which versions of QEMU and edk2 are you using? And what file system do you > have the efi-tests directory on? > I am using the QEMU_EFI.fd image that comes with Ubuntu 20.04.6 (0~20191122.bd85bf54-2ubuntu3.4) https://packages.ubuntu.com/focal-updates/qemu-efi-aarch64 and I've tried two different versions of QEMU $> qemu-system-aarch64 --version QEMU emulator version 4.2.1 (Debian 1:4.2-3ubuntu6.24) Copyright (c) 2003-2019 Fabrice Bellard and the QEMU Project developers $> ../qemu/build/qemu-system-aarch64 --version QEMU emulator version 7.0.0 (v7.0.0-dirty) Copyright (c) 2003-2022 Fabrice Bellard and the QEMU Project developers efi-tests is on ext4 I am happy to have a closer look if you help me reproduce your environment. Thanks, Nikos
On Wed, Mar 22, 2023 at 11:57:17AM +0000, Nikos Nikoleris wrote: > On 22/03/2023 11:24, Andrew Jones wrote: > > On Wed, Mar 22, 2023 at 10:02:35AM +0000, Nikos Nikoleris wrote: > > > Hi Drew, > > > > > > On 21/03/2023 18:41, Andrew Jones wrote: > > > > On Mon, Feb 13, 2023 at 10:17:59AM +0000, Nikos Nikoleris wrote: > > > > > This change adds a efi/run script inspired by the one in x86. This > > > > > script will setup a folder with the test compiled as an EFI app and a > > > > > startup.nsh script. The script launches QEMU providing an image with > > > > > EDKII and the path to the folder with the test which is executed > > > > > automatically. > > > > > > > > > > For example: > > > > > > > > > > $> ./arm/efi/run ./arm/selftest.efi setup smp=2 mem=256 > > > > > > > > This should be > > > > > > > > ./arm/efi/run ./arm/selftest.efi -append "setup smp=2 mem=256" -smp 2 -m 256 > > > > > > > > > > Indeed, I will update the commit message. > > > > > > > but I can't get any tests to run through ./arm/efi/run. All of them > > > > immediately die with a DABT_EL1. I can get the tests to run (and pass) by > > > > manually booting into UEFI with the FAT partition pointing at the parent > > > > directory > > > > > > > > > > I suppose the DABT_EL1 is happening after the test has started and not while > > > the UEFI interactive shell starts? > > > > The countdown completes and the startup script runs (I can add an echo to > > check it). So it must be the test that fails. > > > > > > > > > $QEMU -nodefaults -machine virt -accel tcg -cpu cortex-a57 \ > > > > -device pci-testdev -display none -serial stdio \ > > > > -bios /usr/share/edk2/aarch64/QEMU_EFI.silent.fd \ > > > > -drive file.dir=efi-tests/,file.driver=vvfat,file.rw=on,format=raw,if=virtio > > > > > > > > > > Do you hit the DABT_EL1 if you let it automatically start using the > > > startup.nsh prepared by the ./arm/efi/run script? Meaning change the above > > > command if you provided -drive file.dir=efi-tests/timer instead: > > > > > > $QEMU -nodefaults -machine virt -accel tcg -cpu cortex-a57 \ > > > -device pci-testdev -display none -serial stdio \ > > > -bios /usr/share/edk2/aarch64/QEMU_EFI.silent.fd \ > > > -drive file.dir=efi > > > tests/timer,file.driver=vvfat,file.rw=on,format=raw,if=virtio > > > > Yes, this is what ./arm/efi/run does, and it doesn't help to use the > > command line directly. > > > > > > > > Thanks for reviewing this! > > > > > > Nikos > > > > > > > and then, for example for the timer test, doing > > > > > > > > fs0: > > > > cd timer > > > > timer.efi > > > > This actually doesn't work. I was actually doing > > > > fs0: > > cd timer > > ls > > timer.efi > > > > and, believe it or not, without the 'ls' I get the dabt, with the 'ls' the > > test runs and passes. Adding an 'ls' to the startup script doesn't help > > the automatic execution though. > > > > Which versions of QEMU and edk2 are you using? And what file system do you > > have the efi-tests directory on? > > > > I am using the QEMU_EFI.fd image that comes with Ubuntu 20.04.6 > (0~20191122.bd85bf54-2ubuntu3.4) > https://packages.ubuntu.com/focal-updates/qemu-efi-aarch64 > > and I've tried two different versions of QEMU > > $> qemu-system-aarch64 --version > > QEMU emulator version 4.2.1 (Debian 1:4.2-3ubuntu6.24) > Copyright (c) 2003-2019 Fabrice Bellard and the QEMU Project developers > > $> ../qemu/build/qemu-system-aarch64 --version > QEMU emulator version 7.0.0 (v7.0.0-dirty) > Copyright (c) 2003-2022 Fabrice Bellard and the QEMU Project developers > > efi-tests is on ext4 > > I am happy to have a closer look if you help me reproduce your environment. I'm on Fedora 36 and the file system used for this is XFS. My QEMU version was something pretty recent, but I didn't remember what, so I just updated to latest master (which happens to be the same as v8.0.0-rc1 right now). My edk2 is the one packaged with F36, edk2-aarch64-20221117gitfff6d81270b5-14.fc36.noarch The QEMU update to v8.0.0-rc1 didn't change anything for me (still same failure and still same "fix" of running the test manually after doing a manual 'ls'). Thanks, drew
On 22/03/2023 12:32, Andrew Jones wrote: > On Wed, Mar 22, 2023 at 11:57:17AM +0000, Nikos Nikoleris wrote: >> On 22/03/2023 11:24, Andrew Jones wrote: >>> On Wed, Mar 22, 2023 at 10:02:35AM +0000, Nikos Nikoleris wrote: >>>> Hi Drew, >>>> >>>> On 21/03/2023 18:41, Andrew Jones wrote: >>>>> On Mon, Feb 13, 2023 at 10:17:59AM +0000, Nikos Nikoleris wrote: >>>>>> This change adds a efi/run script inspired by the one in x86. This >>>>>> script will setup a folder with the test compiled as an EFI app and a >>>>>> startup.nsh script. The script launches QEMU providing an image with >>>>>> EDKII and the path to the folder with the test which is executed >>>>>> automatically. >>>>>> >>>>>> For example: >>>>>> >>>>>> $> ./arm/efi/run ./arm/selftest.efi setup smp=2 mem=256 >>>>> >>>>> This should be >>>>> >>>>> ./arm/efi/run ./arm/selftest.efi -append "setup smp=2 mem=256" -smp 2 -m 256 >>>>> >>>> >>>> Indeed, I will update the commit message. >>>> >>>>> but I can't get any tests to run through ./arm/efi/run. All of them >>>>> immediately die with a DABT_EL1. I can get the tests to run (and pass) by >>>>> manually booting into UEFI with the FAT partition pointing at the parent >>>>> directory >>>>> >>>> >>>> I suppose the DABT_EL1 is happening after the test has started and not while >>>> the UEFI interactive shell starts? >>> >>> The countdown completes and the startup script runs (I can add an echo to >>> check it). So it must be the test that fails. >>> >>>> >>>>> $QEMU -nodefaults -machine virt -accel tcg -cpu cortex-a57 \ >>>>> -device pci-testdev -display none -serial stdio \ >>>>> -bios /usr/share/edk2/aarch64/QEMU_EFI.silent.fd \ >>>>> -drive file.dir=efi-tests/,file.driver=vvfat,file.rw=on,format=raw,if=virtio >>>>> >>>> >>>> Do you hit the DABT_EL1 if you let it automatically start using the >>>> startup.nsh prepared by the ./arm/efi/run script? Meaning change the above >>>> command if you provided -drive file.dir=efi-tests/timer instead: >>>> >>>> $QEMU -nodefaults -machine virt -accel tcg -cpu cortex-a57 \ >>>> -device pci-testdev -display none -serial stdio \ >>>> -bios /usr/share/edk2/aarch64/QEMU_EFI.silent.fd \ >>>> -drive file.dir=efi >>>> tests/timer,file.driver=vvfat,file.rw=on,format=raw,if=virtio >>> >>> Yes, this is what ./arm/efi/run does, and it doesn't help to use the >>> command line directly. >>> >>>> >>>> Thanks for reviewing this! >>>> >>>> Nikos >>>> >>>>> and then, for example for the timer test, doing >>>>> >>>>> fs0: >>>>> cd timer >>>>> timer.efi >>> >>> This actually doesn't work. I was actually doing >>> >>> fs0: >>> cd timer >>> ls >>> timer.efi >>> >>> and, believe it or not, without the 'ls' I get the dabt, with the 'ls' the >>> test runs and passes. Adding an 'ls' to the startup script doesn't help >>> the automatic execution though. >>> >>> Which versions of QEMU and edk2 are you using? And what file system do you >>> have the efi-tests directory on? >>> >> >> I am using the QEMU_EFI.fd image that comes with Ubuntu 20.04.6 >> (0~20191122.bd85bf54-2ubuntu3.4) >> https://packages.ubuntu.com/focal-updates/qemu-efi-aarch64 >> >> and I've tried two different versions of QEMU >> >> $> qemu-system-aarch64 --version >> >> QEMU emulator version 4.2.1 (Debian 1:4.2-3ubuntu6.24) >> Copyright (c) 2003-2019 Fabrice Bellard and the QEMU Project developers >> >> $> ../qemu/build/qemu-system-aarch64 --version >> QEMU emulator version 7.0.0 (v7.0.0-dirty) >> Copyright (c) 2003-2022 Fabrice Bellard and the QEMU Project developers >> >> efi-tests is on ext4 >> >> I am happy to have a closer look if you help me reproduce your environment. > > I'm on Fedora 36 and the file system used for this is XFS. My QEMU version > was something pretty recent, but I didn't remember what, so I just updated > to latest master (which happens to be the same as v8.0.0-rc1 right now). > My edk2 is the one packaged with F36, > edk2-aarch64-20221117gitfff6d81270b5-14.fc36.noarch > > The QEMU update to v8.0.0-rc1 didn't change anything for me (still same > failure and still same "fix" of running the test manually after doing > a manual 'ls'). > Thanks Drew! I managed to hit the DABT_EL1 when I switched to the F36 edk2. The problem seems to be with the initialization of the page allocation mechanism. mmu_idmap is allocated at 0x80000000 and phys_alloc_show() prints phys_alloc minimum alignment: 0x40 0000000048000000-000000007c590fff [USED] 000000007c591000-000000007c590fff [FREE] Am I wrong to expect that the address that page_alloc() returns for mmu_idmap should be within the [USED] range? I'll have a closer look into this but I just wanted to check as I am not sure I fully understand the code/logic of lib/alloc_page.{c,h} Thanks, Nikos
On Wed, Mar 22, 2023 at 07:09:23PM +0000, Nikos Nikoleris wrote: > On 22/03/2023 12:32, Andrew Jones wrote: > > On Wed, Mar 22, 2023 at 11:57:17AM +0000, Nikos Nikoleris wrote: > > > On 22/03/2023 11:24, Andrew Jones wrote: > > > > On Wed, Mar 22, 2023 at 10:02:35AM +0000, Nikos Nikoleris wrote: > > > > > Hi Drew, > > > > > > > > > > On 21/03/2023 18:41, Andrew Jones wrote: > > > > > > On Mon, Feb 13, 2023 at 10:17:59AM +0000, Nikos Nikoleris wrote: > > > > > > > This change adds a efi/run script inspired by the one in x86. This > > > > > > > script will setup a folder with the test compiled as an EFI app and a > > > > > > > startup.nsh script. The script launches QEMU providing an image with > > > > > > > EDKII and the path to the folder with the test which is executed > > > > > > > automatically. > > > > > > > > > > > > > > For example: > > > > > > > > > > > > > > $> ./arm/efi/run ./arm/selftest.efi setup smp=2 mem=256 > > > > > > > > > > > > This should be > > > > > > > > > > > > ./arm/efi/run ./arm/selftest.efi -append "setup smp=2 mem=256" -smp 2 -m 256 > > > > > > > > > > > > > > > > Indeed, I will update the commit message. > > > > > > > > > > > but I can't get any tests to run through ./arm/efi/run. All of them > > > > > > immediately die with a DABT_EL1. I can get the tests to run (and pass) by > > > > > > manually booting into UEFI with the FAT partition pointing at the parent > > > > > > directory > > > > > > > > > > > > > > > > I suppose the DABT_EL1 is happening after the test has started and not while > > > > > the UEFI interactive shell starts? > > > > > > > > The countdown completes and the startup script runs (I can add an echo to > > > > check it). So it must be the test that fails. > > > > > > > > > > > > > > > $QEMU -nodefaults -machine virt -accel tcg -cpu cortex-a57 \ > > > > > > -device pci-testdev -display none -serial stdio \ > > > > > > -bios /usr/share/edk2/aarch64/QEMU_EFI.silent.fd \ > > > > > > -drive file.dir=efi-tests/,file.driver=vvfat,file.rw=on,format=raw,if=virtio > > > > > > > > > > > > > > > > Do you hit the DABT_EL1 if you let it automatically start using the > > > > > startup.nsh prepared by the ./arm/efi/run script? Meaning change the above > > > > > command if you provided -drive file.dir=efi-tests/timer instead: > > > > > > > > > > $QEMU -nodefaults -machine virt -accel tcg -cpu cortex-a57 \ > > > > > -device pci-testdev -display none -serial stdio \ > > > > > -bios /usr/share/edk2/aarch64/QEMU_EFI.silent.fd \ > > > > > -drive file.dir=efi > > > > > tests/timer,file.driver=vvfat,file.rw=on,format=raw,if=virtio > > > > > > > > Yes, this is what ./arm/efi/run does, and it doesn't help to use the > > > > command line directly. > > > > > > > > > > > > > > Thanks for reviewing this! > > > > > > > > > > Nikos > > > > > > > > > > > and then, for example for the timer test, doing > > > > > > > > > > > > fs0: > > > > > > cd timer > > > > > > timer.efi > > > > > > > > This actually doesn't work. I was actually doing > > > > > > > > fs0: > > > > cd timer > > > > ls > > > > timer.efi > > > > > > > > and, believe it or not, without the 'ls' I get the dabt, with the 'ls' the > > > > test runs and passes. Adding an 'ls' to the startup script doesn't help > > > > the automatic execution though. > > > > > > > > Which versions of QEMU and edk2 are you using? And what file system do you > > > > have the efi-tests directory on? > > > > > > > > > > I am using the QEMU_EFI.fd image that comes with Ubuntu 20.04.6 > > > (0~20191122.bd85bf54-2ubuntu3.4) > > > https://packages.ubuntu.com/focal-updates/qemu-efi-aarch64 > > > > > > and I've tried two different versions of QEMU > > > > > > $> qemu-system-aarch64 --version > > > > > > QEMU emulator version 4.2.1 (Debian 1:4.2-3ubuntu6.24) > > > Copyright (c) 2003-2019 Fabrice Bellard and the QEMU Project developers > > > > > > $> ../qemu/build/qemu-system-aarch64 --version > > > QEMU emulator version 7.0.0 (v7.0.0-dirty) > > > Copyright (c) 2003-2022 Fabrice Bellard and the QEMU Project developers > > > > > > efi-tests is on ext4 > > > > > > I am happy to have a closer look if you help me reproduce your environment. > > > > I'm on Fedora 36 and the file system used for this is XFS. My QEMU version > > was something pretty recent, but I didn't remember what, so I just updated > > to latest master (which happens to be the same as v8.0.0-rc1 right now). > > My edk2 is the one packaged with F36, > > edk2-aarch64-20221117gitfff6d81270b5-14.fc36.noarch > > > > The QEMU update to v8.0.0-rc1 didn't change anything for me (still same > > failure and still same "fix" of running the test manually after doing > > a manual 'ls'). > > > > Thanks Drew! > > I managed to hit the DABT_EL1 when I switched to the F36 edk2. The problem > seems to be with the initialization of the page allocation mechanism. > mmu_idmap is allocated at 0x80000000 and phys_alloc_show() prints > > phys_alloc minimum alignment: 0x40 > 0000000048000000-000000007c590fff [USED] > 000000007c591000-000000007c590fff [FREE] > > Am I wrong to expect that the address that page_alloc() returns for > mmu_idmap should be within the [USED] range? You're not wrong. That's what I would expect as well from the sequence of allocator initializations and allocations, and that's indeed how it works for the non-uefi case. > > I'll have a closer look into this but I just wanted to check as I am not > sure I fully understand the code/logic of lib/alloc_page.{c,h} I'll also try to find time to take a look. TBH, I never completely grokked the new allocator either. If it gets in our way, then we could add a simpler allocator implementation (just a linked list like it was before) as an alternative and then use that instead. Thanks, drew
Hi, Just a thought, but if the page allocator is giving you trouble, you could try using the physical allocator instead, like I tried to do in my cache maintenance series [1] (requires this patch [2] to change how the idmap is allocated, to use pgd_alloc() instead of page_alloc()). That patch also moves the point where the MMU is enabled to earlier in the boot process, which might be too invasive for this series. In theory, it shouldn't cause any problems, but that's just in theory. [1] https://gitlab.arm.com/linux-arm/kvm-unit-tests-ae/-/commit/3385347b8157d72ea1f2b83afe0026305d89a9ea [2] https://gitlab.arm.com/linux-arm/kvm-unit-tests-ae/-/commit/6faa52530b6a1c150dca4bb7e7caae6c70b162ee Thanks, Alex On Thu, Mar 23, 2023 at 06:52:56PM +0100, Andrew Jones wrote: > On Wed, Mar 22, 2023 at 07:09:23PM +0000, Nikos Nikoleris wrote: > > On 22/03/2023 12:32, Andrew Jones wrote: > > > On Wed, Mar 22, 2023 at 11:57:17AM +0000, Nikos Nikoleris wrote: > > > > On 22/03/2023 11:24, Andrew Jones wrote: > > > > > On Wed, Mar 22, 2023 at 10:02:35AM +0000, Nikos Nikoleris wrote: > > > > > > Hi Drew, > > > > > > > > > > > > On 21/03/2023 18:41, Andrew Jones wrote: > > > > > > > On Mon, Feb 13, 2023 at 10:17:59AM +0000, Nikos Nikoleris wrote: > > > > > > > > This change adds a efi/run script inspired by the one in x86. This > > > > > > > > script will setup a folder with the test compiled as an EFI app and a > > > > > > > > startup.nsh script. The script launches QEMU providing an image with > > > > > > > > EDKII and the path to the folder with the test which is executed > > > > > > > > automatically. > > > > > > > > > > > > > > > > For example: > > > > > > > > > > > > > > > > $> ./arm/efi/run ./arm/selftest.efi setup smp=2 mem=256 > > > > > > > > > > > > > > This should be > > > > > > > > > > > > > > ./arm/efi/run ./arm/selftest.efi -append "setup smp=2 mem=256" -smp 2 -m 256 > > > > > > > > > > > > > > > > > > > Indeed, I will update the commit message. > > > > > > > > > > > > > but I can't get any tests to run through ./arm/efi/run. All of them > > > > > > > immediately die with a DABT_EL1. I can get the tests to run (and pass) by > > > > > > > manually booting into UEFI with the FAT partition pointing at the parent > > > > > > > directory > > > > > > > > > > > > > > > > > > > I suppose the DABT_EL1 is happening after the test has started and not while > > > > > > the UEFI interactive shell starts? > > > > > > > > > > The countdown completes and the startup script runs (I can add an echo to > > > > > check it). So it must be the test that fails. > > > > > > > > > > > > > > > > > > $QEMU -nodefaults -machine virt -accel tcg -cpu cortex-a57 \ > > > > > > > -device pci-testdev -display none -serial stdio \ > > > > > > > -bios /usr/share/edk2/aarch64/QEMU_EFI.silent.fd \ > > > > > > > -drive file.dir=efi-tests/,file.driver=vvfat,file.rw=on,format=raw,if=virtio > > > > > > > > > > > > > > > > > > > Do you hit the DABT_EL1 if you let it automatically start using the > > > > > > startup.nsh prepared by the ./arm/efi/run script? Meaning change the above > > > > > > command if you provided -drive file.dir=efi-tests/timer instead: > > > > > > > > > > > > $QEMU -nodefaults -machine virt -accel tcg -cpu cortex-a57 \ > > > > > > -device pci-testdev -display none -serial stdio \ > > > > > > -bios /usr/share/edk2/aarch64/QEMU_EFI.silent.fd \ > > > > > > -drive file.dir=efi > > > > > > tests/timer,file.driver=vvfat,file.rw=on,format=raw,if=virtio > > > > > > > > > > Yes, this is what ./arm/efi/run does, and it doesn't help to use the > > > > > command line directly. > > > > > > > > > > > > > > > > > Thanks for reviewing this! > > > > > > > > > > > > Nikos > > > > > > > > > > > > > and then, for example for the timer test, doing > > > > > > > > > > > > > > fs0: > > > > > > > cd timer > > > > > > > timer.efi > > > > > > > > > > This actually doesn't work. I was actually doing > > > > > > > > > > fs0: > > > > > cd timer > > > > > ls > > > > > timer.efi > > > > > > > > > > and, believe it or not, without the 'ls' I get the dabt, with the 'ls' the > > > > > test runs and passes. Adding an 'ls' to the startup script doesn't help > > > > > the automatic execution though. > > > > > > > > > > Which versions of QEMU and edk2 are you using? And what file system do you > > > > > have the efi-tests directory on? > > > > > > > > > > > > > I am using the QEMU_EFI.fd image that comes with Ubuntu 20.04.6 > > > > (0~20191122.bd85bf54-2ubuntu3.4) > > > > https://packages.ubuntu.com/focal-updates/qemu-efi-aarch64 > > > > > > > > and I've tried two different versions of QEMU > > > > > > > > $> qemu-system-aarch64 --version > > > > > > > > QEMU emulator version 4.2.1 (Debian 1:4.2-3ubuntu6.24) > > > > Copyright (c) 2003-2019 Fabrice Bellard and the QEMU Project developers > > > > > > > > $> ../qemu/build/qemu-system-aarch64 --version > > > > QEMU emulator version 7.0.0 (v7.0.0-dirty) > > > > Copyright (c) 2003-2022 Fabrice Bellard and the QEMU Project developers > > > > > > > > efi-tests is on ext4 > > > > > > > > I am happy to have a closer look if you help me reproduce your environment. > > > > > > I'm on Fedora 36 and the file system used for this is XFS. My QEMU version > > > was something pretty recent, but I didn't remember what, so I just updated > > > to latest master (which happens to be the same as v8.0.0-rc1 right now). > > > My edk2 is the one packaged with F36, > > > edk2-aarch64-20221117gitfff6d81270b5-14.fc36.noarch > > > > > > The QEMU update to v8.0.0-rc1 didn't change anything for me (still same > > > failure and still same "fix" of running the test manually after doing > > > a manual 'ls'). > > > > > > > Thanks Drew! > > > > I managed to hit the DABT_EL1 when I switched to the F36 edk2. The problem > > seems to be with the initialization of the page allocation mechanism. > > mmu_idmap is allocated at 0x80000000 and phys_alloc_show() prints > > > > phys_alloc minimum alignment: 0x40 > > 0000000048000000-000000007c590fff [USED] > > 000000007c591000-000000007c590fff [FREE] > > > > Am I wrong to expect that the address that page_alloc() returns for > > mmu_idmap should be within the [USED] range? > > You're not wrong. That's what I would expect as well from the sequence > of allocator initializations and allocations, and that's indeed how it > works for the non-uefi case. > > > > > I'll have a closer look into this but I just wanted to check as I am not > > sure I fully understand the code/logic of lib/alloc_page.{c,h} > > I'll also try to find time to take a look. TBH, I never completely grokked > the new allocator either. If it gets in our way, then we could add a > simpler allocator implementation (just a linked list like it was before) > as an alternative and then use that instead. > > Thanks, > drew >
diff --git a/arm/Makefile.common b/arm/Makefile.common index e251f6a8..90a6ff3a 100644 --- a/arm/Makefile.common +++ b/arm/Makefile.common @@ -12,6 +12,7 @@ tests-common += $(TEST_DIR)/gic.$(exe) tests-common += $(TEST_DIR)/psci.$(exe) tests-common += $(TEST_DIR)/sieve.$(exe) tests-common += $(TEST_DIR)/pl031.$(exe) +tests-common += $(TEST_DIR)/dummy.$(exe) tests-all = $(tests-common) $(tests) all: directories $(tests-all) diff --git a/arm/dummy.c b/arm/dummy.c new file mode 100644 index 00000000..7033bb7c --- /dev/null +++ b/arm/dummy.c @@ -0,0 +1,12 @@ +#include "libcflat.h" + +int main(int argc, char **argv) +{ + /* + * scripts/runtime.bash uses this test as a canary to determine if the + * basic setup is functional. Print a magic string to let runtime.bash + * know that all is well. + */ + printf("Dummy Hello World!"); + return 0; +} diff --git a/arm/efi/run b/arm/efi/run new file mode 100755 index 00000000..dfff717a --- /dev/null +++ b/arm/efi/run @@ -0,0 +1,61 @@ +#!/bin/bash + +set -e + +if [ $# -eq 0 ]; then + echo "Usage $0 TEST_CASE [QEMU_ARGS]" + exit 2 +fi + +if [ ! -f config.mak ]; then + echo "run './configure --enable-efi && make' first. See ./configure -h" + exit 2 +fi +source config.mak +source scripts/arch-run.bash +source scripts/common.bash + +: "${EFI_SRC:=$(realpath "$(dirname "$0")/../")}" +: "${EFI_UEFI:=/usr/share/qemu-efi-aarch64/QEMU_EFI.fd}" +: "${EFI_TEST:=efi-tests}" +: "${EFI_CASE:=$(basename $1 .efi)}" + +if [ ! -f "$EFI_UEFI" ]; then + echo "UEFI firmware not found: $EFI_UEFI" + echo "Please install the UEFI firmware to this path" + echo "Or specify the correct path with the env variable EFI_UEFI" + exit 2 +fi + +# Remove the TEST_CASE from $@ +shift 1 + +# Fish out the arguments for the test, they should be the next string +# after the "-append" option +qemu_args=() +cmd_args=() +while (( "$#" )); do + if [ "$1" = "-append" ]; then + cmd_args=$2 + shift 2 + else + qemu_args+=("$1") + shift 1 + fi +done + +if [ "$EFI_CASE" = "_NO_FILE_4Uhere_" ]; then + EFI_CASE=dummy +fi + +: "${EFI_CASE_DIR:="$EFI_TEST/$EFI_CASE"}" +mkdir -p "$EFI_CASE_DIR" + +cp "$EFI_SRC/$EFI_CASE.efi" "$EFI_TEST/$EFI_CASE/" +echo "@echo -off" > "$EFI_TEST/$EFI_CASE/startup.nsh" +echo "$EFI_CASE.efi" "${cmd_args[@]}" >> "$EFI_TEST/$EFI_CASE/startup.nsh" + +EFI_RUN=y $TEST_DIR/run \ + -bios "$EFI_UEFI" \ + -drive file.dir="$EFI_TEST/$EFI_CASE/",file.driver=vvfat,file.rw=on,format=raw,if=virtio \ + "${qemu_args[@]}" diff --git a/arm/run b/arm/run index 12848912..62f845b3 100755 --- a/arm/run +++ b/arm/run @@ -65,8 +65,10 @@ if $qemu $M -chardev testdev,id=id -initrd . 2>&1 \ exit 2 fi -chr_testdev='-device virtio-serial-device' -chr_testdev+=' -device virtconsole,chardev=ctd -chardev testdev,id=ctd' +if [ "$EFI_RUN" != "y" ]; then + chr_testdev='-device virtio-serial-device' + chr_testdev+=' -device virtconsole,chardev=ctd -chardev testdev,id=ctd' +fi pci_testdev= if $qemu $M -device '?' 2>&1 | grep pci-testdev > /dev/null; then @@ -75,7 +77,11 @@ fi A="-accel $ACCEL" command="$qemu -nodefaults $M $A -cpu $processor $chr_testdev $pci_testdev" -command+=" -display none -serial stdio -kernel" +command+=" -display none -serial stdio" command="$(migration_cmd) $(timeout_cmd) $command" -run_qemu $command "$@" +if [ "$EFI_RUN" = "y" ]; then + ENVIRON_DEFAULT=n run_qemu_status $command "$@" +else + run_qemu $command -kernel "$@" +fi diff --git a/scripts/runtime.bash b/scripts/runtime.bash index f8794e9a..13eade26 100644 --- a/scripts/runtime.bash +++ b/scripts/runtime.bash @@ -130,11 +130,18 @@ function run() done fi - last_line=$(premature_failure > >(tail -1)) && { + log=$(premature_failure) && { skip=true - if [ "${CONFIG_EFI}" == "y" ] && [[ "${last_line}" =~ "Dummy Hello World!" ]]; then - skip=false + if [ "${CONFIG_EFI}" == "y" ]; then + if [ "$ARCH" == "x86_64" ] && + [[ "$(tail -1 <<<"$log")" =~ "Dummy Hello World!" ]]; then + skip=false + elif [ "$ARCH" == "arm64" ] && + [[ "$(tail -2 <<<"$log" | head -1)" =~ "Dummy Hello World!" ]]; then + skip=false + fi fi + if [ ${skip} == true ]; then print_result "SKIP" $testname "" "$last_line" return 77