Xen and bhyve are placing ACPI tables into system memory. So, they can
share the same code. Therefore, create a new library which searches and
installs ACPI tables from system memory.
Signed-off-by: Corvin Köhne <corvink@FreeBSD.org>
Reviewed-by: Anthony PERARD <anthony.perard@citrix.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Edk2 was failing, rather than creating more PML4 entries, when they
weren't present in the initial memory acceptance flow. Because of that
VMs with more than 512G memory were crashing. This code fixes that.
This change affects only SEV-SNP VMs.
The code was tested by successfully booting a 512G SEV-SNP VM.
Signed-off-by: Mikolaj Lisik <lisik@google.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Acked-by: Tom Lendacky <thomas.lendacky@amd.com>
The RISC-V version of the DXE IPL does not implement setting the stack
NX, so before switching to an implementation that will ASSERT() on the
missing support, drop the PCD setting that enables it.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Sunil V L <sunilvl@ventanamicro.com>
They are useful for those platforms where SMC SiP calls exist.
Signed-off-by: Marcin Juszkiewicz <marcin.juszkiewicz@linaro.org>
Reviewed-by: Leif Lindholm <quic_llindhol@quicinc.com>
Uncrustify checks are too rigid, making them counter-productive:
- it leads to code that is arguably harder to parse visually (e.g.,
the changes to ArmPkg/Include/Chipset/AArch64Mmu.h in commit
429309e0c6)
- it forces indentation-only changes to code in the vicinity of actual
changes, making the code history more bloated than necessary (see
commit 7f198321ee for an example)
- finding out from the web UI what exactly Uncrustify objected to is not
straight-forward.
So let's enable AuditMode for ArmPkg, so that interested parties can see
the uncrustify recommendations if desired, but without preventing the
changes from being merged. This leaves it at the discretion of the
ArmPkg maintainers to decide which level of conformance is required.
Cc: Leif Lindholm <quic_llindhol@quicinc.com>
Cc: "Kinney, Michael D" <michael.d.kinney@intel.com>
Cc: Michael Kubacki <mikuback@linux.microsoft.com>
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Leif Lindholm <quic_llindhol@quicinc.com>
In case ShellConvertStringToUint64() fails the Handles are left
uninitialized. That can for example happen for Handle2 and Handle3 in
case only one parameter was specified on the command line. Which can
trigger the ASSERT() in line 185.
Reproducer: boot ovmf to efi shell in qemu, using q35 machine type, then
try disconnect the sata controller in efi shell.
Fix that by explicitly setting them to NULL in that case. While being
at it also simplify the logic and avoid pointlessly calling
ShellConvertStringToUint64() in case ParamN is NULL.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Zhichao Gao <zhichao.gao@intel.com>
As per the SMBIOS spec, in smbios type0 table, if the Bios size is
greater than 16MB, extended bios size is used to update size information
and bios size is set to 0xff. when this data is printed by smbiosview,
both bios size and extended bios size is printed if the smbios version
is beyond 3.1, which is incorrect as Bios size is set to 0xff when
rom size is more than 16MB.
To fix this bug, added a condition to print bios size only when it is
not set to 0xff or if the smbios version is older than 3.1.
Signed-off-by: Thejaswani Putta <tputta@nvidia.com>
Cc: Ray Ni <ray.ni@intel.com>
Cc: Zhichao Gao <zhichao.gao@intel.com>
Reviewed-by: Zhichao Gao <zhichao.gao@intel.com>
Now that OvmfPkg/SataControllerDxe and its MdeModulePkg counterpart have
been unified, and no in-tree uses of the OVMF variant remain, let's
delete it.
Tested-by: Gerd Hoffmann <kraxel@redhat.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Pedro Falcato <pedro.falcato@gmail.com>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Replace the OVMF-specific SataControllerDxe (to be later removed) with
the generic, MdeModulePkg one, for the OvmfXen platform.
Signed-off-by: Pedro Falcato <pedro.falcato@gmail.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Acked-by: Anthony PERARD <anthony.perard@citrix.com>
Replace the OVMF-specific SataControllerDxe (to be later removed) with
the generic, MdeModulePkg one, for the AmdSev platform.
Signed-off-by: Pedro Falcato <pedro.falcato@gmail.com>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Replace the OVMF-specific SataControllerDxe (to be later removed) with
the generic, MdeModulePkg one, for the IntelTdx platform.
Signed-off-by: Pedro Falcato <pedro.falcato@gmail.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Replace the OVMF-specific SataControllerDxe (to be later removed) with
the generic, MdeModulePkg one, for the CloudHv platform.
Signed-off-by: Pedro Falcato <pedro.falcato@gmail.com>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Replace the OVMF-specific SataControllerDxe (to be later removed) with
the generic, MdeModulePkg one, for the Bhyve platform.
Signed-off-by: Pedro Falcato <pedro.falcato@gmail.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Acked-by: Peter Grehan <grehan@freebsd.org>
Acked-by: Corvin Köhne <corvink@FreeBSD.org>
Replace the OVMF-specific SataControllerDxe (to be later removed) with
the generic, MdeModulePkg one, for the Microvm platform.
Signed-off-by: Pedro Falcato <pedro.falcato@gmail.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Replace the OVMF-specific SataControllerDxe (to be later removed) with
the generic, MdeModulePkg one, for OvmfPkg{Ia32, X64, Ia32X64} platforms.
Tested-by: Gerd Hoffmann <kraxel@redhat.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Pedro Falcato <pedro.falcato@gmail.com>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
ASSERT (Private != NULL) (where Private = CR(...)) is ineffective as
CR(Ptr, Type, Member, Sig) either returns Ptr - offsetof(Type, Member),
or ASSERTS on the signature, so it's unlikely to ever return NULL (must
be passed a pointer = member's offset, or in this case, 0x4).
ASSERT on This != NULL instead.
Signed-off-by: Pedro Falcato <pedro.falcato@gmail.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
When a UEFI_DRIVER attempts to open a protocol interface with BY_DRIVER
attribute that it already has open with BY_DRIVER attribute,
OpenProtocol() returns EFI_ALREADY_STARTED. This is not an error. The
UEFI-2.7 spec currently says,
> EFI_ALREADY_STARTED -- Attributes is BY_DRIVER and there is an item on
> the open list with an attribute of BY_DRIVER
> whose agent handle is the same as AgentHandle.
Downgrade the log mask for this one condition to DEBUG_INFO, in
SataControllerStart(). This will match the log mask of the other two
informative messages in this function.
(ported from commit 5dfba97)
Signed-off-by: Pedro Falcato <pedro.falcato@gmail.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
The ArmGicAcknowledgeInterrupt () returns the value returned by the
Interrupt Acknowledge Register and the InterruptID separately in an out
parameter.
The function documents the following: 'InterruptId is returned
separately from the register value because in the GICv2 the register
value contains the CpuId and InterruptId while in the GICv3 the register
value is only the InterruptId.'
This function skips setting the InterruptId in the out parameter for
GICv3. Although the return value from the function is the InterruptId
for GICv3, this breaks the function usage model as the caller expects
the InterruptId in the out parameter for the function. e.g. The caller
may end up using the InterruptID which could potentially be an
uninitialised variable value.
Therefore, set the InterruptID in the function out parameter for GICv3
as well.
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
According to the GIC architecture version 3 and 4 specification, the
maximum number of INTID bits supported in the CPU interface is 24.
Considering this the RegShift variable is not required to be more than 8
bits. Therefore, make the RegShift variable type to UINT8. Also add
necessary typecasts when calculating the RegOffset and RegShift values.
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
GICD_SGIR is a 32-bit register, of which INTID is bits [3:0] and Bits
[14:4] is RES0. Since SgiId parameter in the function ArmGicSendSgiTo ()
is UINT8, mask unused bits of SgiId before writing to the GICD_SGIR
register to prevent accidental setting of the RES0 bits.
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
The IrqInterruptHandler () and ExitBootServicesEvent () function
declarations were unused. Therefore, remove these declarations.
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
The EIOR register of the Gic CPU interface is a 32 bit register.
However, the HARDWARE_INTERRUPT_SOURCE used to represent the interrupt
source (Interrupt ID) is typedefed as UINTN, see
EmbeddedPkg\Include\Protocol\HardwareInterrupt.h
Therfore, typecast the interrupt ID (Source) value to UINT32 before
setting the EOIR register. Also, add an assert to check that the value
does not exceed 32 bits.
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
Although the maximum interrupt ID on GicV2 is 10bit and for GicV3/4 is
24bit, and that the IAR and EOIR registers of the Gic CPU interface are
32 bit; the typedef HARDWARE_INTERRUPT_SOURCE is defined as UINTN in
EmbeddedPkg\Include\Protocol\HardwareInterrupt.h
Therefore, use UINTN for Gic Interrupt variables and use appropriate
typecasts wherever needed.
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
The CPU Interface Identification Register (GICC_IIDR) is a 32-bit
register. Since ArmGicGetInterfaceIdentification () returns the value
read from the GICC_IIDR register, update the return type for this
function to UINT32.
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
According to edk2 coding standard specification, Non-Boolean comparisons
must use a compare operator (==, !=, >, < >=, <=). See Section 5.7.2.1
at https://edk2-docs.gitbook.io/
edk-ii-c-coding-standards-specification/5_source_files/ 57_c_programming
Therefore, fix the comparison in ArmGicEnableDistributor()
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
The Software Generated Interrupt Register (GICD_SGIR) is a 32 bit
register with the following bit assignment:
TargetListFilter, bits [25:24]
CPUTargetList, bits [23:16]
NSATT, bit [15]
SGIINTID, bits [3:0]
Therefore, modify the TargetListFilter, CPUTargetList, SGI Interrupt ID
parameters of the ArmGicSendSgiTo () to use UINT8 instead of INTN.
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
The data type used by variables representing the
GicInterruptInterfaceBase has been inconsistently used in the ArmGic
driver and the library. The PCD defined for the GIC Interrupt interface
base address is UINT64. However, the data types for the variables used
is UINTN, INTN, and at some places UINT32.
Therefore, update the data types to use UINTN and add necessary
typecasts when reading values from the PCD. This should then be
consistent across AArch32 and AArch64 builds.
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
The data type used by variables representing the GicDistributorBase has
been inconsistently used in the ArmGic driver and the library. The PCD
defined for the GIC Distributor base address is UINT64. However, the
data types for the variables used is UINTN, INTN, and at some places
UINT32.
Therefore, update the data types to use UINTN and add necessary
typecasts when reading values from the PCD. This should then be
consistent across AArch32 and AArch64 builds.
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
The GIC v2 base addresses can be 64bit, don't limit to 32 on 64bit
machines.
Signed-off-by: Neil Jones <neil.jones@blaize.com>
Reviewed-by: Pedro Falcato <pedro.falcato@gmail.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
In case a virtio serial device is found in the system register the first
console port as EFI console, by updating ConIn, ConOut and ErrOut.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
IsVirtioPciRng() becomes just a thin wrapper for IsVirtioPci().
This allows to add similar thin wrappers for other virtio
devices in the future.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
IsVirtioRng() becomes just a thin wrapper for IsVirtio().
This allows to add similar thin wrappers for other virtio
devices in the future.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Use the MdePkg versions instead of maintaining a copy in BaseTools.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
Reviewed-by: Rebecca Cran <rebecca@bsdio.com>
Use the MdePkg version instead of maintaining a copy in BaseTools.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Chao Li <lichao@loongson.cn>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
Reviewed-by: Rebecca Cran <rebecca@bsdio.com>
Use the newer versions of the machine #defines.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Chao Li <lichao@loongson.cn>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
Reviewed-by: Rebecca Cran <rebecca@bsdio.com>
The #define for IMAGE_FILE_MACHINE_ARM is not present in MdePkg,
this looks like a relic not used any more. Remove.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
Reviewed-by: Rebecca Cran <rebecca@bsdio.com>
The BaseTools and MdePkg versions of PeImage.h diverged over time,
add some missing bits to the MdePkg header file in preparation for
removing the BaseTools version.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
Reviewed-by: Rebecca Cran <rebecca@bsdio.com>
Use the MdePkg version instead of maintaining a copy in BaseTools.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Acked-by: Sunil V L <sunilvl@ventanamicro.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
Reviewed-by: Rebecca Cran <rebecca@bsdio.com>
Use the MdePkg version instead of maintaining a copy in BaseTools.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Chao Li <lichao@loongson.cn>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
Reviewed-by: Rebecca Cran <rebecca@bsdio.com>
Appears to be a relic for ancient windows / compiler versions,
windows builds in CI work just fine without it.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
Reviewed-by: Rebecca Cran <rebecca@bsdio.com>
Not needed any more on modern toolchains, they are better
in not creating a GOT without this trick.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
Reviewed-by: Rebecca Cran <rebecca@bsdio.com>
Tell clang to not use external (via got) references for data access.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Acked-by: Liming Gao <gaoliming@byosoft.com.cn>
Older linux kernels have problems with phys-bits larger than 46,
ubuntu 18.04 (kernel 4.15) has been reported to be affected.
Reduce phys-bits limit from 47 to 46.
Reported-by: Fiona Ebner <f.ebner@proxmox.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Flash can be write-protected in qemu (which is usually the case for
code). In case the variable store flash block is configured read-only
ovmf wouldn't be able to store EFI variables there, so not setting up
fvb in that case (and fallhack to emulation) is the better option.
It'll avoid problems later due to flash writes failing.
The patch tries to write back the original value read earlier, so flash
content doesn't change in case the write succeeds. But the status we
read back after the attempt to write will tell us whenever flash is
writable or not.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Apparently TPL_CALLBACK is too low, code runs into an ASSERT
complaining the new TPL is lower than the old TPL.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4424
In Relaxed-AP Sync Mode, BSP will not wait for all Aps arrive. However,
PerformRemainingTasks() needs to wait all Aps arrive before calling
SetMemMapAttributes and ConfigSmmCodeAccessCheck() when mSmmReadyToLock
is true. In SetMemMapAttributes(), SmmSetMemoryAttributesEx() will call
FlushTlbForAll() that need to start up the aps. So it need to let all
aps arrive. Same as SetMemMapAttributes(), ConfigSmmCodeAccessCheck()
also will start up the aps.
Cc: Eric Dong <eric.dong@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Signed-off-by: Zhihao Li <zhihao.li@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
Corvin Köhne
Mikolaj Lisik via groups.io
Ard Biesheuvel
Marcin Juszkiewicz
Gerd Hoffmann
Thejaswani Putta
Pedro Falcato
Sami Mujawar
Neil Jones
Zhihao Li