ArmPkg/ArmScmiDxe: Fix the calculation of RequiredArraySize As per the SCMI specification, section CLOCK_DESCRIBE_RATES mentions that the value of num_rates_flags[11:0] in the response must be 3 if the return format is the triplet. Due to the buggy firmware, this was not noticed for long time. The firmware is now fixed resulting in ClockDescribeRates() to fail with "Buffer Too Small" error as the RequiredArraySize gets miscalculated as 72 instead of 24. Fix the issue by reusing the logic for both the return format which must work if num_rates_flags has correct value as expected from the specification. Cc: Girish Pathak <girish.pathak@arm.com> Cc: Jeff Brasen <jbrasen@nvidia.com> Reviewed-by: Pierre Gondois <pierre.gondois@arm.com> Tested-by: Pierre Gondois <pierre.gondois@arm.com> Reported-by: Sami Mujawar <sami.mujawar@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> Reviewed-by: Sami Mujawar <sami.mujawar@arm.com> Tested-by: Sami Mujawar <sami.mujawar@arm.com>
ArmPkg: implement EFI_MP_SERVICES_PROTOCOL based on PSCI calls Add support for EFI_MP_SERVICES_PROTOCOL during the DXE phase under AArch64. PSCI_CPU_ON is called to power on the core, the supplied procedure is executed and PSCI_CPU_OFF is called to power off the core. Fixes contributed by Ard Biesheuvel. Signed-off-by: Rebecca Cran <rebecca@quicinc.com> Reviewed-by: Ard Biesheuvel <ardb@kernel.org> Tested-by: Kun Qin <kun.qin@microsoft.com>
ArmPkg: Remove duplicated words In an effort to clean the documentation of the above package, remove duplicated words, and fix a typo while at it. Signed-off-by: Pierre Gondois <pierre.gondois@arm.com> Reviewed-by: Sami Mujawar <sami.muajwar@arm.com> Reviewed-by: Leif Lindholm <quic_llindhol@quicinc.com>
ArmPkg/CpuDxe: drop ARM_PROCESSOR_TABLE pseudo-ACPI table The ARM_PROCESSOR_TABLE pseudo-ACPI table (which carries a ACPI-table like header but is published as a EFI config table) is not described in any relevant spec, and is not known to be relied upon by any OS. Let's just get rid of it. Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Reviewed-by: Sami Mujawar <sami.mujawar@arm.com> Tested-by: Sami Mujawar <sami.mujawar@arm.com>
ArmPkg/Drivers: ArmGicIsInterruptEnabled returns incorrect value The issue appears to have been introduced by: 41fb5d46 : ArmPkg/ArmGic: Use the GIC Redistributor instead of GIC Distributor for GICv3 The changes to ArmGicIsInterruptEnabled() introduced the error where the Boolean result is assigned to Interrupts, but then the bit position check is performed again (against the computed Boolean result instead of the interrupt mask) during the return statement. Fix removes erroneous test and relies on boolean test made at return. Signed-off-by: Robbie King <robbiek@xsightlabs.com> Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
ArmPkg/ArmMmuLib AARCH64: avoid EL0 accessible mappings We never run any code at EL0, and so it would seem that any access permissions set for EL0 (via the AP[1] attribute in the page tables) are irrelevant. We currently set EL0 and EL1 permissions to the same value arbitrarily. However, this causes problems on hardware like the Apple M1 running the MacOS hypervisor framework, which enters EL1 with SCTLR_EL1.SPAN enabled, causing the Privileged Access Never (PAN) feature to be enabled on any exception taken to EL1, including the IRQ exceptions that handle our timer interrupt. When PAN is enabled, EL1 has no access to any mappings that are also accessible to EL0, causing the firmware to crash if it attempts to access such a mapping. Even though it is debatable whether or not SCTLR_EL1.SPAN should be disabled at entry or whether the firmware should put all UNKNOWN bits in all system registers in a consistent state (which it should), using EL0 permissions serves no purpose whatsoever so let's fix that regardless. Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Tested-by: Alexander Graf <agraf@csgraf.de> Acked-by: Leif Lindholm <leif@nuviainc.com>
ArmPkg: MmCommunicationDxe: Update MM communicate `MessageLength` check REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3751 Current MM communicate routine from ArmPkg would conduct few checks prior to proceeding with SMC calls. However, the inspection step is different from PI specification. This patch updated MM communicate input argument inspection routine to assure that "if the `MessageLength` is zero, or too large for the MM implementation to manage, the MM implementation must update the `MessageLength` to reflect the size of the `Data` buffer that it can tolerate", as described by `EFI_MM_COMMUNICATION_PROTOCOL.Communicate()` section in PI specification. Cc: Leif Lindholm <leif@nuviainc.com> Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Bret Barkelew <Bret.Barkelew@microsoft.com> Cc: Michael Kubacki <michael.kubacki@microsoft.com> Cc: Sami Mujawar <sami.mujawar@arm.com> Signed-off-by: Kun Qin <kuqin12@gmail.com> Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
ArmPkg: MmCommunicationDxe: Update MM communicate `CommSize` check REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3751 Current MM communicate routine from ArmPkg would conduct few checks prior to proceeding with SMC calls. However, the inspection step is different from PI specification. This patch updated MM communicate input argument inspection routine to assure `CommSize` represents "the size of the data buffer being passed in" instead of the size of the data being used from data buffer, as described by section `EFI_MM_COMMUNICATION2_PROTOCOL.Communicate()` in PI specification. Cc: Leif Lindholm <leif@nuviainc.com> Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Bret Barkelew <Bret.Barkelew@microsoft.com> Cc: Michael Kubacki <michael.kubacki@microsoft.com> Cc: Sami Mujawar <sami.mujawar@arm.com> Signed-off-by: Kun Qin <kuqin12@gmail.com> Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
ArmPkg: MmCommunicationDxe: Update MM communicate `CommBuffer**` checks REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3751 Current MM communicate routine from ArmPkg would conduct few checks prior to proceeding with SMC calls. However, the inspection step is different from PI specification. This patch updated MM communicate input argument inspection routine to assure that return code `EFI_INVALID_PARAMETER` represents "the `CommBuffer**` parameters do not refer to the same location in memory", as described by `EFI_MM_COMMUNICATION2_PROTOCOL.Communicate()` section in PI specification. Cc: Leif Lindholm <leif@nuviainc.com> Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Bret Barkelew <Bret.Barkelew@microsoft.com> Cc: Michael Kubacki <michael.kubacki@microsoft.com> Cc: Sami Mujawar <sami.mujawar@arm.com> Signed-off-by: Kun Qin <kuqin12@gmail.com> Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
ArmPkg: MmCommunicationDxe: MM communicate function argument attributes Current MM communicate2 function from ArmPkg described input arguments `CommBufferPhysical`, `CommBufferVirtual` and `CommSize` as input only, which mismatches with the "input and output type" as in PI specification. This change updated function descriptions of MM communite2 to match input argument types. Cc: Leif Lindholm <leif@nuviainc.com> Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Bret Barkelew <Bret.Barkelew@microsoft.com> Cc: Michael Kubacki <michael.kubacki@microsoft.com> Cc: Sami Mujawar <sami.mujawar@arm.com> Signed-off-by: Kun Qin <kuqin12@gmail.com> Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
ArmPkg: Apply uncrustify changes REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3737 Apply uncrustify changes to .c/.h files in the ArmPkg package Cc: Andrew Fish <afish@apple.com> Cc: Leif Lindholm <leif@nuviainc.com> Cc: Michael D Kinney <michael.d.kinney@intel.com> Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com> Reviewed-by: Andrew Fish <afish@apple.com>
ArmPkg: Use PcdPciIoTranslation PCD from MdePkg PcdPciIoTranslation PCD is relocated to MdePkg and leveraged by both ARM and RISC-V arch. This patch removes the one from ArmPkg and address the corresponding changes required for other modules under ArmVirtPkg. Signed-off-by: Abner Chang <abner.chang@hpe.com> Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Leif Lindholm <leif@nuviainc.com> Cc: Sami Mujawar <sami.mujawar@arm.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Daniel Schaefer <daniel.schaefer@hpe.com> Cc: Sunil V L <sunilvl@ventanamicro.com> Reviewed-by: Daniel Schaefer <daniel.schaefer@hpe.com> Reviewed-by: Sunil V L <sunilvl@ventanamicro.com> Acked-by: Gerd Hoffmann <kraxel@redhat.com>
ArmPkg/GicV3Dxe: Don't signal EOI on arbitrary interrupts Currently, at ExitBootServices() time, the GICv3 driver signals End-Of-Interrupt (EOI) on all interrupt lines that are supported by the interrupt controller. This appears to have been carried over from the GICv2 version, but has been turned into something that violates the GIC spec, and may trigger SError exceptions on some implementations. Marc puts it as follows: The GIC interrupt state machine is pretty strict. An interrupt can only be deactivated (with or without prior priority drop) if it has been acknowledged first. In GIC speak, this means that only the following sequences are valid: With EOImode==0: x = ICC_IAR{0,1}_EL1; ICC_EOIR{0,1}_EL1 = x; With EOImode==1: x = ICC_IAR{0,1}_EL1; ICC_EOIR{0,1}_EL1 = x; ICC_DIR_EL1 = x; Any write to ICC_EOIR{0,1}_EL1 that isn't the direct consequence of the same value being read from ICC_IAR{0,1}_EL1, and with the correct nesting, breaks the state machine and leads to unpredictable results that affects *all* interrupts in the system (most likely, the priority system is dead). See Figure 4-3 ("Interrupt handling state machine") in Arm IHI 0069F for a description of the acceptable transitions. Additionally, on implementations that have ICC_CTLR_EL1.SEIS==1, a SError may be generated to signal the error. See the various <quote> IMPLEMENTATION_DEFINED "SError ...."; </quote> that are all over the pseudocode contained in the same architecture spec. Needless to say, this is pretty final for any SW that would do silly things on such implementations (which do exist). Given that in our implementation, every signalled interrupt is acked, handled and EOId in sequence, there is no reason to EOI all interrupts at ExitBootServices() time in the first place, so let's just drop this code. This fixes an issue reported by Marc where an SError is triggered by this code, bringing down the system. Reported-by: Marc Zyngier <maz@kernel.org> Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Acked-by: Marc Zyngier <maz@kernel.org> Tested-by: Marc Zyngier <maz@kernel.org> Reviewed-by: Leif Lindholm <leif@nuviainc.com>
ArmPkg/ArmGic: Fix maximum number of interrupts in GICv3 Bugzilla: 3415 (https://bugzilla.tianocore.org/show_bug.cgi?id=3415) The GICv3 architecture supports up to 1020 ordinary interrupt lines. The actual number of interrupts supported is described by the ITLinesNumber field in the GICD_TYPER register. The total number of implemented registers is normally calculated as 32*(ITLinesNumber+1). However, maximum value (0x1f) is a special case since that would indicate that 1024 interrupts are implemented. Add handling for this special case in ArmGicGetMaxNumInterrupts. Signed-off-by: Andreas Sandberg <andreas.sandberg@arm.com> Signed-off-by: Joey Gouly <joey.gouly@arm.com> Signed-off-by: Sami Mujawar <sami.mujawar@arm.com> Reviewed-by: Ard Biesheuvel <ardb@kernel.org> Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
ArmPkg: Update SCMI Base Protocol version to 0x20000 The SCP-firmware has moved to full support for SCMIv2 which means that the base protocol can be either compliant with SCMI v1 or v2. Allow any version between SCMI v1.0 and SCMI v2.0 to be compatible with the current implementation. Signed-off-by: Nicola Mazzucato <nicola.mazzucato@arm.com> Signed-off-by: Pierre Gondois <Pierre.Gondois@arm.com> Tested-by: Sami Mujawar <sami.mujawar@arm.com> Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
ArmPkg: Correct small typos The 'cspell' CI test detected some small typos in ArmPkg. Correct them. Cc: Bret Barkelew <bret.barkelew@microsoft.com> Cc: Sean Brogan <sean.brogan@microsoft.com> Cc: Leif Lindholm <leif@nuviainc.com> Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Sami Mujawar <sami.mujawar@arm.com> Signed-off-by: Pierre Gondois <Pierre.Gondois@arm.com> Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
ArmPkg: Fix Ecc error 8003 This patch fixes the following Ecc reported error: The #ifndef at the start of an include file should have one postfix underscore, and no prefix underscore character Some include guards have been modified to match the name of the header file. Some comments have also been added on the closing '#endif'. Cc: Bret Barkelew <bret.barkelew@microsoft.com> Cc: Sean Brogan <sean.brogan@microsoft.com> Cc: Leif Lindholm <leif@nuviainc.com> Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Sami Mujawar <sami.mujawar@arm.com> Signed-off-by: Pierre Gondois <Pierre.Gondois@arm.com> Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
ArmPkg: Fix Ecc error 8005 for SCMI_MESSAGE_ID_PERFORMANCE This patch fixes the following Ecc reported error: Variable name does not follow the rules: 1. First character should be upper case 2. Must contain lower case characters 3. No white space characters 4. Global variable name must start with a 'g' Signed-off-by: Pierre Gondois <Pierre.Gondois@arm.com> Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
ArmPkg: Fix Ecc error 8005 for SCMI_CLOCK_RATE_FORMAT This patch fixes the following Ecc reported error: Variable name does not follow the rules: 1. First character should be upper case 2. Must contain lower case characters 3. No white space characters 4. Global variable name must start with a 'g' Signed-off-by: Pierre Gondois <Pierre.Gondois@arm.com> Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>