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?
