Hi All,
As discussed in the meeting today,please find my ITS code implementation from linaro git repo below
ssh://git@git.linaro.org/people/shashi.mallela/qemu.git
Please provide your review comments.
While majority of the functionality is implemented,there are final changes to be done around GITS_TRANSLATER and referencing the ITS device into sbsa-ref which i shall update subsequently.
Thanks
Shashi
On Tue, Mar 02, 2021 at 11:18:31 +0000, Leif Lindholm via Asa-dev wrote:
> On Tue, Mar 02, 2021 at 11:02:35 +0000, Marcin Juszkiewicz via Asa-dev wrote:
> > I run sbsa-acs in both QEMU and on HoneyComb to check how it goes.
> >
> > Recently I noticed long times of PE checks. For example "2 : Check for SIMD
> > extensions" is running here for over 3 minutes. On machine with 4 emulated
> > cpu cores (a72).
>
> That sounds completely bonkers.
> https://github.com/ARM-software/sbsa-acs/blob/master/test_pool/pe/test_c002…
>
> I mean the actual test here is reading ID_AA64PFR0_EL1 and checking
> the value of a field in the result.
>
> > That's with local git HEAD builds of QEMU, EDK2, Sbsa.efi using Fedora
> > 10.2.1 cross compiler.
> >
> > Any ideas what is going on?
>
> 1) The test itself is not the problem.
> 2) Masahisa has reported other weirdness recently wrt MPIDR values in
> ACPI and stuff.
>
> What do you get reported in the logs for number of PEs in system and
> such?
We carried the conversation over to IRC, and the investigation
resulted in
https://edk2.groups.io/g/devel/topic/patch_edk2_platforms_1_1/81024935
/
Leif
On Tue, Mar 02, 2021 at 11:02:35 +0000, Marcin Juszkiewicz via Asa-dev wrote:
> I run sbsa-acs in both QEMU and on HoneyComb to check how it goes.
>
> Recently I noticed long times of PE checks. For example "2 : Check for SIMD
> extensions" is running here for over 3 minutes. On machine with 4 emulated
> cpu cores (a72).
That sounds completely bonkers.
https://github.com/ARM-software/sbsa-acs/blob/master/test_pool/pe/test_c002…
I mean the actual test here is reading ID_AA64PFR0_EL1 and checking
the value of a field in the result.
> That's with local git HEAD builds of QEMU, EDK2, Sbsa.efi using Fedora
> 10.2.1 cross compiler.
>
> Any ideas what is going on?
1) The test itself is not the problem.
2) Masahisa has reported other weirdness recently wrt MPIDR values in
ACPI and stuff.
What do you get reported in the logs for number of PEs in system and
such?
/
Leif
I run sbsa-acs in both QEMU and on HoneyComb to check how it goes.
Recently I noticed long times of PE checks. For example "2 : Check for
SIMD extensions" is running here for over 3 minutes. On machine with 4
emulated cpu cores (a72).
That's with local git HEAD builds of QEMU, EDK2, Sbsa.efi using Fedora
10.2.1 cross compiler.
Any ideas what is going on?
Hi All,
Sorry for long email, but I need your advice to debug my current problem.
[Issue]
SynchronousExceptionSPx() occurs in secondary core
while primary core is executing to boot edk2.
# I use almost latest TF-A and edk2 source code.
# TF-A Includes Graeme's patches to support 512 cores.
[Detail]
In sbsa-qemu boot flow, primary core starts bl1 -> bl2 -> bl31 -> bl32 -> edk2.
My sbsa-qemu enables UEFI secure variables, so edk2 calls MM_COMMUNICATE service
and access uefi variables using StandaloneMM variable/flash drivers
running in Secure-EL0.
For secondary cores, all secondary cores sleep with wfe()
in plat/qemu/common/aarch64/plat_helpers.S::plat_secondary_cold_boot_setup()
in bl1,
until linux kernel calls PSCI(cpu on).
The below gdb output is at edk2 boot. At this point, everythig is fine and
edk2 <-> StandaloneMM communication works.
---
(gdb) info thread
Id Target Id Frame
* 1 Thread 1.1 (CPU#0 [running]) spm_mm_smc_handler (smc_fid=3288334433,
x1=0, x2=0, x3=0, x4=0, cookie=0x0 <bl1_entrypoint>,
handle=0x3ff8a010 <sp_ctx+16>, flags=0)
at services/std_svc/spm_mm/spm_mm_main.c:280
2 Thread 1.2 (CPU#1 [running]) plat_secondary_cold_boot_setup ()
at plat/qemu/common/aarch64/plat_helpers.S:84
---
Several MM_COMMUNICATE service call occurs in edk2,
suddenly SynchronousExceptionSPx() is invoked in secondary core.
(To make issue simple, I start qemu with "-smp 2")
# I set breakpoint at SynchronousExceptionSPx() in secondary core.
---
(gdb) info thread
Id Target Id Frame
1 Thread 1.1 (CPU#0 [running]) 0x0000000020aef988 in ?? ()
* 2 Thread 1.2 (CPU#1 [running]) SynchronousExceptionSPx ()
at bl1/aarch64/bl1_exceptions.S:54
---
After that, secondary core goes into panic_handler() and could not boot anymore.
EDK2 and standaloneMM runs only on primary core until linux issues PSCI call,
so I don't have any idea why SynchronousException(generated by software?) occurs
in secondary core.
[Observation]
1) Some EL3 registers are as follows when secondary core stops
with breakpoint at SynchronousExceptionSPx ().
ELR_EL3 0x31c4
ESR_EL3 0x2000000
FAR_EL3 0x0
ELR_EL3 points 0x31c4, it is wfe() at plat_secondary_cold_boot_setup().
Does it mean SynchronousException occurs while secondary core sleep with wfe()?
# All register dump and disassembled bl1.elf are attached.
2) PSCI related area "PLAT_QEMU_HOLD_BASE"(starts from bottom of
the secure SRAM(0x20000000)) is as expected.
Secondary core#1 checks 0x20000010 in poll_mailbox() loop, the value(0) means
secondary core shall keep to sleep with wfe().
---
INFO: 0x20000000 3fcee114
INFO: 0x20000008 0
INFO: 0x20000010 0
INFO: 0x20000018 0
---
This log is output in every spm_mm SMC handler of primary core.
3) When I load same TF-A/BL32(StandaloneMM) image and disable UEFI secure boot
on edk2, this issue does not occur. It means calling MM_COMMUNICATE
service causes
this issue.
Does anyone have any idea/clue to debug of this issue?
Thanks,
Masahisa
Hi All,
I just encounter this error, I would like to share the information.
SMP boot fails with the latest master branch of
edk2/edk2-platforms/tf-a as of today.
# I boot sbsa-qemu with "-smp 4".
Linux kernel outputs following error.
[ 0.000000] duplicate boot CPU MPIDR: 0x0 in MADT
[ 0.000000] duplicate boot CPU MPIDR: 0x0 in MADT
[ 0.000000] duplicate boot CPU MPIDR: 0x0 in MADT
debian@debian:~$ lscpu
Architecture: aarch64
Byte Order: Little Endian
CPU(s): 1
On-line CPU(s) list: 0
Thread(s) per core: 1
Core(s) per socket: 1
Socket(s): 1
NUMA node(s): 1
Vendor ID: ARM
Model: 3
Model name: Cortex-A72
Stepping: r0p3
BogoMIPS: 125.00
L1d cache: 32K
L1i cache: 32K
L2 cache: 512K
NUMA node0 CPU(s): 0
Flags: fp asimd evtstrm aes pmull sha1 sha2 crc32 cpuid
Thanks,
Masahisa
During today's meeting we agreed on creating Jira cards to track how
close we are to SBSA level 3 and 4 compliance when it comes to QEMU SBSA
Reference Platform.
SBSA level 3 requirements are tracked in card ASA-75. I marked several
cards as blockers of it.
SBSA level 4 is tracked in ASA-76. It depends on ASA-75 and then has
several newer cards added as blockers:
ASA-81 Pass "Memory Access to Un-Populated addr" test in SBSA-ACS
ASA-80 Pass PCIe tests in SBSA-ACS
ASA-79 Pass PCIe MSI/MSI-X test in SBSA-ACS
ASA-78 Pass VMID16 test in SBSA-ACS
ASA-77 Pass RAS test in SBSA-ACS
ASA-74 Add support for newer cpu core than Cortex-A72
ASA-67 Add Virtual Host Extensions (VHE)
Each card got failure message from SBSA-ACS as first comment.
ASA-74 among with QEMU-414 will bring us Cortex-A76 which will be v8.2
so we should pass most of PE tests.
According to SBSA v6.1 specification we will need ARMv8.3 cpu for level
4 (level 3 is fine with v8.0 one). This will be sorted out once we get
v8.2 one.
W dniu 30.10.2020 o 13:03, Marcin Juszkiewicz via Asa-dev pisze:
> I added new CI job: ldcg-sbsa-acs.
>
> It builds HEAD of qemu and edk2 and then use it to run Arm SBSA ACS
> testsuite for SBSA levels 3-6.
Some changes done:
1. As SBSA ACS gets new commits I changed CI job to build what's
in git HEAD instead of using releases.
2. sbsa-ref is now using Cortex-A72 instead of A57 during run.
3. We have two runs per SBSA level now. One is with default action
for watchdog (reset) while other ignores watchdog (action
none).
Shashi has some ideas why SBSA ACS are failing in watchdog tests and
will file an issue.
https://snapshots.linaro.org/ldcg/sbsa-acs/9/ should get populated in
few minutes with full logs.