Hi, long time no mail so let me tell you how our merge queue looks:
1. Leif wrote patchset for TF-A to add 'max' cpu support.
This gives us CPU with all/most features supported in QEMU. Compared to
'cortex-a72' we use now we get some tests pass for level 4 and above.
https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/9112
Code to enable 'max' cpu model for sbsa-ref is already merged into QEMU
tree.
Passed tests:
20 : Check for 16-Bit VMID : Result: PASS
21 : Check for Virtual host extensions : Result: PASS
22 : Check for pointer signing : Result: PASS
27 : Check for SHA3 and SHA512 support : Result: PASS
31 : Check PEs Implement SB Barrier : Result: PASS
32 : Check PE Impl CFP,DVP,CPP RCTX : Result: PASS
33 : Check Branch Target Support : Result: PASS
2. I sent patch to QEMU to bump amount of PMU counters to six (required
by both BSA and SBSA).
https://lists.gnu.org/archive/html/qemu-devel/2021-03/msg01012.html
Patch was discussed and then Peter Maydell proposed patch which handles
that per CPU model.
https://lists.gnu.org/archive/html/qemu-devel/2021-03/msg04065.html
Passed tests:
12 : Check number of PMU counters : Result: PASS
3. GIT ITS enablement done by Shashi.
This work has two parts: QEMU and EDK2.
https://lists.gnu.org/archive/html/qemu-devel/2021-03/msg05315.htmlhttps://edk2.groups.io/g/devel/message/72682?p=,,,20,0,0,0::Created,,shashi…
This allows us to pass ITS related tests and allows us to add SMMU handling.
Passed tests:
102 : If PCIe, then GIC implements ITS : Result: PASS
On 01/03/2021 06:20, Masahisa Kojima via Asa-dev wrote:
> 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
>
Hi Masahisa,
Just to check, your qemu is new enough to contain this commit?
commit 999f6ebde5d3ee30b03270bc05095bed737b7dab
Author: Leif Lindholm <leif(a)nuviainc.com>
Date: Thu Aug 27 13:43:35 2020 +0100
hw/arm/sbsa-ref: add "reg" property to DT cpu nodes
Graeme
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