summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* OvmfPkg/VirtioFsDxe: implement EFI_SIMPLE_FILE_SYSTEM_PROTOCOL.OpenVolume()Laszlo Ersek2020-12-2115-1/+432
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | With the help of the VirtioFsFuseOpenDir() and VirtioFsFuseReleaseFileOrDir() functions introduced previously, we can now open and close the root directory. So let's implement EFI_SIMPLE_FILE_SYSTEM_PROTOCOL.OpenVolume(). OpenVolume() creates a new EFI_FILE_PROTOCOL object -- a reference to the root directory of the filesystem. Thus, we have to start tracking references to EFI_SIMPLE_FILE_SYSTEM_PROTOCOL, lest we unbind the virtio-fs device while files are open. There are two methods that release an EFI_FILE_PROTOCOL object: the Close() and the Delete() member functions. In particular, they are not allowed to fail with regard to resource management -- they must release resources unconditionally. Thus, for rolling back the resource accounting that we do in EFI_SIMPLE_FILE_SYSTEM_PROTOCOL.OpenVolume(), we have to implement the first versions of EFI_FILE_PROTOCOL.Close() and EFI_FILE_PROTOCOL.Delete() in this patch as well. With this patch applied, the UEFI shell can enter the root directory of the Virtio Filesystem (such as with the "FS3:" shell command), and the "DIR" shell command exercises FUSE_OPENDIR and FUSE_RELEASEDIR, according to the virtiofsd log. The "DIR" command reports the root directory as if it were empty; probably because at this time, we only allow the shell to open and to close the root directory, but not to read it. Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Philippe Mathieu-Daudé <philmd@redhat.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3097 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20201216211125.19496-12-lersek@redhat.com> Acked-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
* OvmfPkg/VirtioFsDxe: add shared wrapper for FUSE_RELEASE / FUSE_RELEASEDIRLaszlo Ersek2020-12-214-0/+142
| | | | | | | | | | | | | | The FUSE_RELEASE and FUSE_RELEASEDIR commands only differ in the opcode. Add a common function called VirtioFsFuseReleaseFileOrDir() for sending either command. Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Philippe Mathieu-Daudé <philmd@redhat.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3097 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20201216211125.19496-11-lersek@redhat.com> Acked-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
* OvmfPkg/VirtioFsDxe: implement the wrapper function for FUSE_OPENDIRLaszlo Ersek2020-12-214-0/+143
| | | | | | | | | | | | | Add the VirtioFsFuseOpenDir() function, for sending the FUSE_OPENDIR command to the Virtio Filesystem device. Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Philippe Mathieu-Daudé <philmd@redhat.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3097 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20201216211125.19496-10-lersek@redhat.com> Acked-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
* OvmfPkg/VirtioFsDxe: submit the FUSE_INIT request to the deviceLaszlo Ersek2020-12-216-8/+182
| | | | | | | | | | | | | | | | Submit the FUSE_INIT request to the Virtio Filesystem device, for starting the FUSE session. The FUSE_INIT request is logged by the virtio-fs daemon, with this patch applied, when (for example) using the "CONNECT" UEFI shell command. Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Philippe Mathieu-Daudé <philmd@redhat.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3097 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20201216211125.19496-9-lersek@redhat.com> Acked-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
* OvmfPkg/VirtioFsDxe: map "errno" values to EFI_STATUSLaszlo Ersek2020-12-212-0/+205
| | | | | | | | | | | | | | | | | | | The VirtioFsFuseCheckResponse() function dedicates the EFI_DEVICE_ERROR status code to the case when the Virtio Filesystem device explicitly returns an error via the "VIRTIO_FS_FUSE_RESPONSE.Error" field. Said field effectively carries a Linux "errno" value. Introduce a helper function for mapping "errno" values to (hopefully) reasonable EFI_STATUS codes. This way we'll be able to propagate "errno" values as EFI_STATUS return codes along the UEFI call stack -- in some detail anyway. Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Philippe Mathieu-Daudé <philmd@redhat.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3097 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20201216211125.19496-8-lersek@redhat.com> Acked-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
* OvmfPkg/VirtioFsDxe: introduce the basic FUSE request/response headersLaszlo Ersek2020-12-214-0/+287
| | | | | | | | | | | | | | | | | | | | | | Introduce the VIRTIO_FS_FUSE_REQUEST and VIRTIO_FS_FUSE_RESPONSE structures, which are the common headers for the various FUSE request/response structures. Introduce the VirtioFsFuseNewRequest() helper function for populating VIRTIO_FS_FUSE_REQUEST, from parameters and from a VIRTIO_FS-level request counter. Introduce the VirtioFsFuseCheckResponse() helper function for verifying most FUSE response types that begin with the VIRTIO_FS_FUSE_RESPONSE header. Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Philippe Mathieu-Daudé <philmd@redhat.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3097 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20201216211125.19496-7-lersek@redhat.com> Acked-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
* OvmfPkg/VirtioFsDxe: add a scatter-gather list data typeLaszlo Ersek2020-12-212-0/+461
| | | | | | | | | | | | | | | | | | | | | | | In preparation for the variously structured FUSE request/response exchanges that virtio-fs uses, introduce a scatter-gather list data type. This will let us express FUSE request-response pairs flexibly. Add a function for validating whether a (request buffer list, response buffer list) pair is well-formed, and supported by the Virtio Filesystem device's queue depth. Add another function for mapping and submitting a validated pair of scatter-gather lists to the Virtio Filesystem device. Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Philippe Mathieu-Daudé <philmd@redhat.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3097 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20201216211125.19496-6-lersek@redhat.com> Acked-by: Ard Biesheuvel <ard.biesheuvel@arm.com> [lersek@redhat.com: suppress useless VS2019 warning about signed/unsigned comparison in VirtioFsSgListsValidate()]
* OvmfPkg/VirtioFsDxe: implement virtio device (un)initializationLaszlo Ersek2020-12-215-2/+412
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add the VirtioFsInit(), VirtioFsUninit(), and VirtioFsExitBoot() functions. In VirtioFsInit(): - Verify the host-side config of the virtio-fs device. - Save the filesystem label ("tag") for later, from the configuration area of the virtio-fs device. - Save the virtio queue size for later as well. - Set up the virtio ring for sending requests. In VirtioFsUninit(): - Reset the device. - Tear down the virtio ring. In VirtioFsExitBoot(): - Reset the device. With this patch, the UEFI connect / disconnect controller operations involve virtio setup / teardown; they are visible in the virtio-fs daemon's log file. The virtiofsd log also confirms the device reset in VirtioFsExitBoot(), when an OS is booted while the virtio-fs device is bound. Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Philippe Mathieu-Daudé <philmd@redhat.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3097 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20201216211125.19496-5-lersek@redhat.com> Acked-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
* OvmfPkg/VirtioFsDxe: DriverBinding: open VirtioDevice, install SimpleFsLaszlo Ersek2020-12-215-3/+181
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Complete the Supported, Start, and Stop member functions of EFI_DRIVER_BINDING_PROTOCOL sufficiently for exercising the UEFI driver model: - bind virtio-fs devices, - produce placeholder EFI_SIMPLE_FILE_SYSTEM_PROTOCOL instances on them. On the "TO_START" (= Virtio) side, the VirtioFsBindingSupported() function verifies the Virtio subsystem ID for the virtio-fs device (decimal 26 -- see <https://github.com/oasis-tcs/virtio-spec/blob/87fa6b5d8155/virtio-fs.tex>). Beyond that, no actual Virtio setup is performed for now. Those bits are going to be implemented later in this series. On the "BY_START" (= UEFI filesystem) side, the VirtioFsOpenVolume() function -- which is the sole EFI_SIMPLE_FILE_SYSTEM_PROTOCOL member function -- is a stub; it always returns EFI_NO_MEDIA, for now. The "CONNECT", "DISCONNECT", and "MAP -R" UEFI Shell commands can be used to test this patch. Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Philippe Mathieu-Daudé <philmd@redhat.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3097 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20201216211125.19496-4-lersek@redhat.com> Acked-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
* ArmVirtPkg: include VirtioFsDxe in the ArmVirtQemu* platformsLaszlo Ersek2020-12-213-3/+6
| | | | | | | | | | | | | Include the VirtioFsDxe driver in the ArmVirtPkg platforms that include Virtio10Dxe. (The virtio-fs device is virtio-1.0-only.) Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Cc: Leif Lindholm <leif@nuviainc.com> Cc: Philippe Mathieu-Daudé <philmd@redhat.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3097 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20201216211125.19496-3-lersek@redhat.com> Acked-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
* OvmfPkg: introduce VirtioFsDxeLaszlo Ersek2020-12-218-0/+210
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The purpose of the driver is to ease file exchange (file sharing) between the guest firmware and the virtualization host. The driver is supposed to interoperate with QEMU's "virtiofsd" (Virtio Filesystem Daemon). References: - https://virtio-fs.gitlab.io/ - https://libvirt.org/kbase/virtiofs.html VirtioFsDxe will bind virtio-fs devices, and produce EFI_SIMPLE_FILE_SYSTEM_PROTOCOL instances on them. In the longer term, assuming QEMU will create "bootorder" fw_cfg file entries for virtio-fs devices, booting guest OSes from host-side directories should become possible (dependent on the matching QemuBootOrderLib enhancement). Add the skeleton of the driver. Install EFI_DRIVER_BINDING_PROTOCOL with stub member functions. Install EFI_COMPONENT_NAME2_PROTOCOL with final member functions. This suffices for the DRIVERS command in the UEFI Shell to list the driver with a human-readable name. The file permission model is described immediately in the INF file as a comment block, for future reference. Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Philippe Mathieu-Daudé <philmd@redhat.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3097 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20201216211125.19496-2-lersek@redhat.com> Acked-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
* EmbeddedPkg/TimeBaseLib: remove useless truncation to 32-bitLaszlo Ersek2020-12-212-4/+4
| | | | | | | | | | | | | | | | | | | EfiTimeToEpoch() calls EfiGetEpochDays() internally, which (reasonably) returns a UINTN. But then EfiTimeToEpoch() truncates the EfiGetEpochDays() retval to UINT32 for no good reason, effectively restricting Time->Year under 2106. This truncation was pointed out with a valid warning (= build error) by VS2019. Allow EfiTimeToEpoch() to return / propagate a UINTN value. Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Cc: Leif Lindholm <leif@nuviainc.com> Cc: Philippe Mathieu-Daudé <philmd@redhat.com> Signed-off-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20201221113657.6779-3-lersek@redhat.com> Acked-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
* ArmPlatformPkg/PL031RealTimeClockLib: cast EfiTimeToEpoch() val. to UINT32Laszlo Ersek2020-12-211-1/+1
| | | | | | | | | | | | | | | | | In preparation for changing EfiTimeToEpoch()'s return type to UINTN, cast EfiTimeToEpoch()'s retval to UINT32 explicitly, in LibSetTime(). Currently, this is a no-op, and even after widening the retval, it will make no difference, as LibSetTime() explicitly restricts Time->Year under 2106, given that "the PL031 is a 32-bit counter counting seconds". The patch is made for preventing compiler warnings. Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Cc: Leif Lindholm <leif@nuviainc.com> Cc: Philippe Mathieu-Daudé <philmd@redhat.com> Signed-off-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20201221113657.6779-2-lersek@redhat.com> Acked-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
* EmulatorPkg/PlatformCI: stick with "ubuntu-18.04" for nowBob Feng2020-12-211-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | "vm_image: 'ubuntu-latest'" now refers to Ubuntu Focal (20.04LTS), not Ubuntu Bionic (18.04LTS), according to <https://github.com/actions/virtual-environments/issues/1816>. In Focal, an EmulatorPkg linking step fails like this: > INFO - "gcc" -o > /home/vsts/work/1/s/Build/EmulatorIA32/DEBUG_GCC5/IA32/Host -m32 > -L/usr/X11R6/lib > -Wl,--start-group,@/home/vsts/work/1/s/Build/EmulatorIA32/DEBUG_GCC5/IA32/EmulatorPkg/Unix/Host/Host/OUTPUT/static_library_files.lst,--end-group > -lpthread -ldl -lXext -lX11 > INFO - /usr/bin/ld: skipping incompatible > /usr/lib/gcc/x86_64-linux-gnu/9/libgcc.a when searching for -lgcc > INFO - /usr/bin/ld: cannot find -lgcc > INFO - /usr/bin/ld: skipping incompatible > /usr/lib/gcc/x86_64-linux-gnu/9/libgcc.a when searching for -lgcc > INFO - /usr/bin/ld: cannot find -lgcc > INFO - collect2: error: ld returned 1 exit status > INFO - make: *** [GNUmakefile:421: > /home/vsts/work/1/s/Build/EmulatorIA32/DEBUG_GCC5/IA32/EmulatorPkg/Unix/Host/Host/DEBUG/Host] > Error 1 So for now, stick with the previous Ubuntu environment, which continues to be supported, per <https://github.com/actions/virtual-environments/issues/1816>. The following ticket has been opened about this particular issue: <https://github.com/actions/virtual-environments/issues/2324>. Signed-off-by: Bob Feng <bob.c.feng@intel.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Andrew Fish <afish@apple.com> Cc: Ray Ni <ray.ni@intel.com> Message-Id: <20201221031930.1799-1-bob.c.feng@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> [lersek@redhat.com: update the commit message to refer to GCC rather than to QEMU]
* MdeModulePkg/PciSioSerialDxe: Flush Tx before config changeMichael D Kinney2020-12-191-1/+90
| | | | | | | | | | | | | | | | | | | | | | https://bugzilla.tianocore.org/show_bug.cgi?id=3114 Add logic to flush all UART transmit buffers if there is a config change from Reset(), SetAttributes() or SetControl(). Use a timeout in the flush operation, so the system can continue to boot if the transmit buffers can not be flushed for any reason. This change prevents lost characters on serial debug logs and serial consoles when a config change is made. It also prevents a UART from getting into a bad state or reporting error status due to characters being transmitted at the same time registers are updated with new communications settings. Cc: Hao A Wu <hao.a.wu@intel.com> Cc: Ray Ni <ray.ni@intel.com> Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com> Reviewed-by: Ray Ni <ray.ni@intel.com> Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
* ArmPkg/ArmGicV3Dxe: Use ArmGicSetInterruptPriority() to set priorityQuan Nguyen2020-12-181-8/+5
| | | | | | | | | | | When Affinity Routing enabled, the GICR_IPRIORITYR<n> is used to set priority for SGIs and PPIs instead of GICD_IPRIORITYR<n>. This patch calls ArmGicSetInterruptPriority() helper function when setting priority to handle the difference. Cc: Leif Lindholm <leif@nuviainc.com> Signed-off-by: Quan Nguyen <quan@os.amperecomputing.com> Reviewed-off-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
* ArmPkg/ArmGicLib: Add ArmGicSetInterruptPriority() helper functionQuan Nguyen2020-12-182-0/+53
| | | | | | | | | | | | | | | | According to ARM IHI 0069F, section 11.9.18 GICD_IPRIORITYR<n>, Interrupt Priority Registers, n = 0 - 254, when affinity routing is enabled for the Security state of an interrupt, GICR_IPRIORITYR<n> is used instead of GICD_IPRIORITYR<n> where n = 0 to 7 (that is, for SGIs and PPIs). As setting interrupt priority for SGIs and PPIs are handled using difference registers depends on the mode, this patch instroduces ArmGicSetInterruptPriority() helper function to handle the discrepancy. Cc: Leif Lindholm <leif@nuviainc.com> Signed-off-by: Quan Nguyen <quan@os.amperecomputing.com> Reviewed-off-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
* ArmPkg/ArmLib: move ArmReadIdPfr0/1 into private header ArmV7Lib.hLeif Lindholm2020-12-182-12/+12
| | | | | | | | | | | ArmReadIdPfr0 () and ArmReadIdPfr1 () are now used only inside ArmLib. Remove the prototypes from the public header to discourage new id register accessor additions, and direct id register access in general. Move them into local header Arm/ArmV7Lib.h. Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Signed-off-by: Leif Lindholm <leif@nuviainc.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
* ArmPkg/ArmLib: rename AArch64 variant of ArmReadIdPfr0Leif Lindholm2020-12-183-3/+10
| | | | | | | | | | ArmReadIdPfr0 is now used only inside ArmLib. Rename the AArch64 variant ArmReadIdAA64Pfr0 and add a declaration of that only into local header AArch64/AArch64Lib.h. Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Signed-off-by: Leif Lindholm <leif@nuviainc.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
* ArmPkg/ArmLib: delete AArch64 version of ArmReadIdPfr1Leif Lindholm2020-12-181-8/+0
| | | | | | | | | The AArch64 version of ArmReadIdPfr1 is not used by any code in tree, or in edk2-platforms. Delete it. Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Signed-off-by: Leif Lindholm <leif@nuviainc.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
* ArmPkg: use helper to check for Security extensions in ArmArchTimerLibLeif Lindholm2020-12-181-1/+1
| | | | | | | | | Use the helper ArmHasSecurityExtensions () instead of accessing ID_PFR1 directly. Only affects ARM build. Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Signed-off-by: Leif Lindholm <leif@nuviainc.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
* ArmPkg: add ArmHasSecurityExtensions () helper functionLeif Lindholm2020-12-182-0/+32
| | | | | | | | | | | | | Create a helper function to eliminate direct feature register reading. Returns BOOLEAN True if the CPU implements the Security extensions, otherwise returns BOOL False. This function is only implemented for ARM, not AArch64. Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Signed-off-by: Leif Lindholm <leif@nuviainc.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
* ArmPkg: remove duplicated ARM/AArch64 ArmGicArchSecLib sourcesLeif Lindholm2020-12-183-50/+2
| | | | | | | | | | | The ID register access was the only difference between them, so after switching to the ArmHasGicSystemRegisters () helper, there is no longer any need to have separate ARM/AArch64 source files for ArmGicArchSecLib, so unify them and drop the subdirectories. Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Signed-off-by: Leif Lindholm <leif@nuviainc.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
* ArmPkg: remove duplicated ARM/AArch64 ArmGicArchLib sourcesLeif Lindholm2020-12-183-65/+2
| | | | | | | | | | | The ID register access was the only difference between them, so after switching to the ArmHasGicSystemRegisters () helper, there is no longer any need to have separate ARM/AArch64 source files for ArmGicArchLib, so unify them and drop the subdirectories. Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Signed-off-by: Leif Lindholm <leif@nuviainc.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
* ArmPkg: use ID register helper for ArmGicArch(Sec)LibLeif Lindholm2020-12-184-4/+4
| | | | | | | | Use ArmHasGicSystemRegisters () instead of direct ID register tests. Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Signed-off-by: Leif Lindholm <leif@nuviainc.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
* ArmPkg/ArmLib: add ArmHasGicSystemRegisters () helper functionLeif Lindholm2020-12-183-0/+50
| | | | | | | | | | | | Create a helper function to eliminate direct feature register reading, which gets messy in code shared between ARM/AArch64. Returns BOOLEAN True if the CPU implements the GIC System Register Interface (any version), otherwise returns BOOL False. Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Signed-off-by: Leif Lindholm <leif@nuviainc.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
* OvmfPkg/PlatformBootManagerLib: fix PCI interrupt link (LNKx)Borghorst, Hendrik via groups.io2020-12-181-13/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch fixes an issue with the current programming of the i440fx PCI Interrupt routing assignment. Explanation by Laszlo Ersek: (1) The rotating pattern is a map: (slot, function) --> (interrupt link) [LNKA..LNKD] (more precisely, it is a pattern from (slot, pin) to (interrupt link), but function<->pin is an identity mapping in the QEMU hardware, so we can just use (slot, function) rather than (slot, pin) on the left hand side. But I digress.) The ACPI _PRT object is generated by QEMU; it describes this map. (2) Another map is (interrupt link) --> { set of possible interrupt numbers, for this link } This map is given by the LNK[A..D] ACPI objects, also given by QEMU. (3) What the firmware is expected to do is: (3a) for each interrupt link, select an *actual* interrupt from the set that's possible for that link, yielding a deterministic map (interrupt link) --> (actual interrupt number) and (3b) for each PCI device/function with an interrupt pin, resolve the (slot, function) --> (interrupt link) --> (actual interrupt number) functional composition, and program the result into the Interrupt Line register of the device. In OVMF, we do not parse the rotating map described under (1) from QEMU's _PRT object. Instead, we duplicate the code. This is not a problem. In OVMF, we also do not parse the map described under (2) from QEMU's ACPI content. Instead, we pick a specific selection (3a) that we "apriori" know satisfies (2). This is also not a problem. OVMF's particular selection is the PciHostIrqs table. ( Table (2) from QEMU is LNKA -> { 5, 10, 11 } LNKB -> { 5, 10, 11 } LNKC -> { 5, 10, 11 } LNKD -> { 5, 10, 11 } and our specific pick in OVMF, in the PciHostIrqs table, is LNKA -> 10 LNKB -> 10 LNKC -> 11 LNKD -> 11 ) In OVMF, we also cover step (3b), in the SetPciIntLine() function. What's missing in OVMF -- and what this patch corrects -- is that we currently fail to program our selection for table (3) into the hardware. We pick a specific LNKx->IRQ# mapping for each interrupt link, and we correctly program the PCI Interrupt Line registers through those link-to-IRQ mappings -- but we don't tell the hardware about the link-to-IRQ mappings. More precisely, we program such a link-to-IRQ mapping table into the hardware that is then not matched by the mapping we use for programming the PCI device/function interrupt lines. As a result, some PCI Interrupt Line registers will have impossible values -- a given (slot, function) may use a particular link, but also report an interrupt number that was never picked for that link. Output of Linux PCI Interrupt Links for i440fx before the patch: [ 0.327305] ACPI: PCI Interrupt Link [LNKA] (IRQs 5 10 *11) [ 0.327944] ACPI: PCI Interrupt Link [LNKB] (IRQs 5 10 *11) [ 0.328582] ACPI: PCI Interrupt Link [LNKC] (IRQs 5 *10 11) [ 0.329208] ACPI: PCI Interrupt Link [LNKD] (IRQs 5 *10 11) [ 0.329807] ACPI: PCI Interrupt Link [LNKS] (IRQs *9) after the patch: [ 0.327292] ACPI: PCI Interrupt Link [LNKA] (IRQs 5 *10 11) [ 0.327934] ACPI: PCI Interrupt Link [LNKB] (IRQs 5 *10 11) [ 0.328564] ACPI: PCI Interrupt Link [LNKC] (IRQs 5 10 *11) [ 0.329195] ACPI: PCI Interrupt Link [LNKD] (IRQs 5 10 *11) [ 0.329785] ACPI: PCI Interrupt Link [LNKS] (IRQs *9) Output of Linux PCI Interrupt Links for q35 before the patch: [ 0.307474] ACPI: PCI Interrupt Link [LNKA] (IRQs 5 *10 11) [ 0.308027] ACPI: PCI Interrupt Link [LNKB] (IRQs 5 *10 11) [ 0.308764] ACPI: PCI Interrupt Link [LNKC] (IRQs 5 10 *11) [ 0.309310] ACPI: PCI Interrupt Link [LNKD] (IRQs 5 10 *11) [ 0.309853] ACPI: PCI Interrupt Link [LNKE] (IRQs 5 *10 11) [ 0.310508] ACPI: PCI Interrupt Link [LNKF] (IRQs 5 *10 11) [ 0.311051] ACPI: PCI Interrupt Link [LNKG] (IRQs 5 10 *11) [ 0.311589] ACPI: PCI Interrupt Link [LNKH] (IRQs 5 10 *11) after the patch: [ 0.301991] ACPI: PCI Interrupt Link [LNKA] (IRQs 5 *10 11) [ 0.302833] ACPI: PCI Interrupt Link [LNKB] (IRQs 5 *10 11) [ 0.303354] ACPI: PCI Interrupt Link [LNKC] (IRQs 5 10 *11) [ 0.303873] ACPI: PCI Interrupt Link [LNKD] (IRQs 5 10 *11) [ 0.304399] ACPI: PCI Interrupt Link [LNKE] (IRQs 5 *10 11) [ 0.304918] ACPI: PCI Interrupt Link [LNKF] (IRQs 5 *10 11) [ 0.305436] ACPI: PCI Interrupt Link [LNKG] (IRQs 5 10 *11) [ 0.305954] ACPI: PCI Interrupt Link [LNKH] (IRQs 5 10 *11) Signed-off-by: Hendrik Borghorst <hborghor@amazon.de> Reviewed-by: David Woodhouse <dwmw@amazon.co.uk> Message-Id: <8dbedc4c7a1c3fd390aca915270814e3b35e13a5.camel@amazon.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
* Revert "UefiCpuPkg/CpuDxe: Fix boot error"Laszlo Ersek2020-12-181-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | This reverts commit cee5b0441af39dd6f76cc4e0447a1c7f788cbb00. Commit cee5b0441af3 ("UefiCpuPkg/CpuDxe: Fix boot error", 2020-12-08) breaks CpuDxe (and with it, OVMF boot) on AMD processors. AMD processors cannot do far jumps to 64-bit targets, as documented in the AMD64 Architecture Programmer's Manual. Revert the patch until a RETFQ-based substitute is posted. Cc: Eric Dong <eric.dong@intel.com> Cc: Guo Dong <guo.dong@intel.com> Cc: James Bottomley <James.Bottomley@HansenPartnership.com> Cc: Rahul Kumar <rahul1.kumar@intel.com> Cc: Ray Ni <ray.ni@intel.com> Cc: Thomas Lendacky <thomas.lendacky@amd.com> Ref: https://edk2.groups.io/g/devel/message/68597 Ref: https://www.redhat.com/archives/edk2-devel-archive/2020-December/msg00493.html Reported-by: Thomas Lendacky <thomas.lendacky@amd.com> Ref: https://edk2.groups.io/g/devel/message/68832 Ref: https://www.redhat.com/archives/edk2-devel-archive/2020-December/msg00737.html Reported-by: James Bottomley <James.Bottomley@HansenPartnership.com> Signed-off-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20201217085055.15131-1-lersek@redhat.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3121 [lersek@redhat.com: add BZ link]
* OvmfPkg/AmdSev/SecretDxe: make secret location naming genericJames Bottomley2020-12-184-10/+10
| | | | | | | | | | | | It is anticipated that this part of the code will work for both Intel TDX and AMD SEV, so remove the SEV specific naming and change to ConfidentialComputing as a more architecture neutral prefix. Apart from the symbol rename, there are no code changes. Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com> Message-Id: <20201216014146.2229-3-jejb@linux.ibm.com> Reviewed-by: Jiewen Yao <Jiewen.yao@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg: Change SEV Launch Secret API to be UINT64 for base and sizeJames Bottomley2020-12-181-2/+2
| | | | | | | | | | | | Although the SEV secret location must always be below 4GB, the same is not necessarily true for Intel TDX, so change the configuration table to contain a pair of UINT64 parameters instead of UINT32 so that any X64 location can be represented. Signed-off-by: James Bottomley <jejb@linux.ibm.com> Message-Id: <20201216014146.2229-2-jejb@linux.ibm.com> Reviewed-by: Jiewen Yao <Jiewen.yao@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg/PlatformCI: stick with "ubuntu-18.04" for nowLaszlo Ersek2020-12-181-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | "vm_image: 'ubuntu-latest'" now refers to Ubuntu Focal (20.04LTS), not Ubuntu Bionic (18.04LTS), according to <https://github.com/actions/virtual-environments/issues/1816>. In Focal, the "qemu" package is a dummy package with no dependencies, and so the actual emulators are not pulled in. Compare: https://packages.ubuntu.com/bionic/qemu https://packages.ubuntu.com/focal/qemu This causes CI runs to fail. It would be best to switch to the "qemu-system" package name, which continues to depend on the emulators: https://packages.ubuntu.com/bionic/qemu-system https://packages.ubuntu.com/focal/qemu-system However, while that package does make the emulators available, the emulators crash. So for now, stick with the previous Ubuntu environment, which continues to be supported, per <https://github.com/actions/virtual-environments/issues/1816>. Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Philippe Mathieu-Daudé <philmd@redhat.com> Signed-off-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20201217204049.26817-3-lersek@redhat.com> Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
* ArmVirtPkg/PlatformCI: stick with "ubuntu-18.04" for nowLaszlo Ersek2020-12-181-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | "vm_image: 'ubuntu-latest'" now refers to Ubuntu Focal (20.04LTS), not Ubuntu Bionic (18.04LTS), according to <https://github.com/actions/virtual-environments/issues/1816>. In Focal, the "qemu" package is a dummy package with no dependencies, and so the actual emulators are not pulled in. Compare: https://packages.ubuntu.com/bionic/qemu https://packages.ubuntu.com/focal/qemu This causes CI runs to fail. It would be best to switch to the "qemu-system" package name, which continues to depend on the emulators: https://packages.ubuntu.com/bionic/qemu-system https://packages.ubuntu.com/focal/qemu-system However, while that package does make the emulators available, the emulators crash. So for now, stick with the previous Ubuntu environment, which continues to be supported, per <https://github.com/actions/virtual-environments/issues/1816>. Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Cc: Leif Lindholm <leif@nuviainc.com> Cc: Philippe Mathieu-Daudé <philmd@redhat.com> Signed-off-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20201217204049.26817-2-lersek@redhat.com> Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
* RedfishPkg/RedfishCredentialDxe: EDKII Redfish Credential DXE driverAbner Chang2020-12-1610-0/+565
| | | | | | | | | | | | | | | EDKII Redfish Credential DXE driver which abstracts platform Redfish credential implementation. Signed-off-by: Jiaxin Wu <jiaxin.wu@intel.com> Signed-off-by: Ting Ye <ting.ye@intel.com> Signed-off-by: Siyuan Fu <siyuan.fu@intel.com> Signed-off-by: Fan Wang <fan.wang@intel.com> Signed-off-by: Abner Chang <abner.chang@hpe.com> Cc: Nickle Wang <nickle.wang@hpe.com> Cc: Peter O'Hanley <peter.ohanley@hpe.com> Reviewed-by: Nickle Wang <nickle.wang@hpe.com>
* RedfishPkg/Include: EDKII Redfish Credential Header fileAbner Chang2020-12-162-0/+104
| | | | | | | | | | | | Signed-off-by: Jiaxin Wu <jiaxin.wu@intel.com> Signed-off-by: Ting Ye <ting.ye@intel.com> Signed-off-by: Siyuan Fu <siyuan.fu@intel.com> Signed-off-by: Fan Wang <fan.wang@intel.com> Signed-off-by: Abner Chang <abner.chang@hpe.com> Cc: Nickle Wang <nickle.wang@hpe.com> Cc: Peter O'Hanley <peter.ohanley@hpe.com> Reviewed-by: Nickle Wang <nickle.wang@hpe.com>
* MdePkg/include: Add DMAR SATC Table DefinitionSheng Wei2020-12-151-3/+31
| | | | | | | | | | | | | | | | | | | SoC Integrated Address Translation Cache (SATC) reporting structure is one of the Remapping Structure, which is imported since Intel(R) Virtualization Technology for Directed I/O (VT-D) Architecture Specification v3.2. REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3109 Signed-off-by: Sheng Wei <w.sheng@intel.com> Cc: Michael D Kinney <michael.d.kinney@intel.com> Cc: Liming Gao <gaoliming@byosoft.com.cn> Cc: Zhiguang Liu <zhiguang.liu@intel.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Jenny Huang <jenny.huang@intel.com> Cc: Kowalewski Robert <robert.kowalewski@intel.com> Cc: Feng Roger <roger.feng@intel.com> Reviewed-by: Zhiguang Liu <zhiguang.liu@intel.com> Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
* BaseTools: Add comments in StructurePcd DSC file.Chen, Christine2020-12-151-3/+12
| | | | | | | | | | | | | | Currently VFR files have variables comments which will not be added into StructurePcd.dsc file. Thus, it is not convenient for developer to Modify Pcds. To solve this problem, The comments will be modified to user friendly format and added after the corresponding Pcd values in StructurePcd.dsc file. Cc: Bob Feng <bob.c.feng@intel.com> Cc: Liming Gao <gaoliming@byosoft.com.cn> Signed-off-by: Yuwei Chen <yuwei.chen@intel.com> Reviewed-by: Bob Feng <bob.c.feng@intel.com>
* MdeModulePkg/Variable/RuntimeDxe: Add Variable Lock Protocol Unit TestsMichael D Kinney2020-12-153-0/+612
| | | | | | | | | | | | | | | | https://bugzilla.tianocore.org/show_bug.cgi?id=3111 Add host based unit tests for the multiple lock case using Variable Lock Protocol, Variable Policy Protocol, and mixes of Variable Lock Protocol and Variable Policy Protocol. Cc: Michael D Kinney <michael.d.kinney@intel.com> Cc: Hao A Wu <hao.a.wu@intel.com> Cc: Liming Gao <gaoliming@byosoft.com.cn> Signed-off-by: Bret Barkelew <Bret.Barkelew@microsoft.com> Reviewed-by: Hao A Wu <hao.a.wu@intel.com> Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn> Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
* MdeModulePkg/Variable/RuntimeDxe: Restore Variable Lock Protocol behaviorBret Barkelew2020-12-151-36/+59
| | | | | | | | | | | | | | | | | | | | | | | https://bugzilla.tianocore.org/show_bug.cgi?id=3111 The VariableLock shim currently fails if called twice because the underlying Variable Policy engine returns an error if a policy is set on an existing variable. This breaks existing code which expect it to silently pass if a variable is locked multiple times (because it should "be locked"). Refactor the shim to confirm that the variable is indeed locked and then change the error to EFI_SUCCESS and generate a DEBUG_ERROR message so the duplicate lock can be reported in a debug log and removed. Cc: Michael D Kinney <michael.d.kinney@intel.com> Cc: Hao A Wu <hao.a.wu@intel.com> Cc: Liming Gao <gaoliming@byosoft.com.cn> Signed-off-by: Bret Barkelew <Bret.Barkelew@microsoft.com> Reviewed-by: Hao A Wu <hao.a.wu@intel.com> Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn> Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
* .azurepipelines: Use alternate cmocka repoMichael D Kinney2020-12-152-0/+6
| | | | | | | | | | | Use git config insteadOf feature to use an alternate cmocka repo from github when running CI. Cc: Sean Brogan <sean.brogan@microsoft.com> Cc: Bret Barkelew <Bret.Barkelew@microsoft.com> Cc: Liming Gao <gaoliming@byosoft.com.cn> Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com> Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
* OvmfPkg/AmdSev: Expose the Sev Secret area using a configuration tableJames Bottomley2020-12-146-0/+95
| | | | | | | | | | | | | | Now that the secret area is protected by a boot time HOB, extract its location details into a configuration table referenced by gSevLaunchSecretGuid so the boot loader or OS can locate it before a call to ExitBootServices(). Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3077 Signed-off-by: James Bottomley <jejb@linux.ibm.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20201130202819.3910-7-jejb@linux.ibm.com> Acked-by: Ard Biesheuvel <ard.biesheuvel@arm.com> [lersek@redhat.com: fix indentation of InstallConfigurationTable() args]
* OvmfPkg/AmdSev: assign and reserve the Sev Secret areaJames Bottomley2020-12-144-0/+65
| | | | | | | | | | | | | Create a one page secret area in the MEMFD and reserve the area with a boot time HOB. Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3077 Signed-off-by: James Bottomley <jejb@linux.ibm.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20201130202819.3910-6-jejb@linux.ibm.com> Acked-by: Ard Biesheuvel <ard.biesheuvel@arm.com> [lersek@redhat.com: s/protect/reserve/g in the commit message, at Ard's and James's suggestion]
* OvmfPkg: create a SEV secret area in the AmdSev memfdJames Bottomley2020-12-144-0/+31
| | | | | | | | | | | | | | SEV needs an area to place an injected secret where OVMF can find it and pass it up as a ConfigurationTable. This patch implements the area itself as an addition to the SEV enhanced reset vector table using an additional guid (4c2eb361-7d9b-4cc3-8081-127c90d3d294). Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3077 Signed-off-by: James Bottomley <jejb@linux.ibm.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20201130202819.3910-5-jejb@linux.ibm.com> Acked-by: Ard Biesheuvel <ard.biesheuvel@arm.com> [lersek@redhat.com: fix typo in "ResetVectorVtf0.asm" comments]
* OvmfPkg/AmdSev: add Grub Firmware Volume PackageJames Bottomley2020-12-1412-10/+2144
| | | | | | | | | | | | | | | | | | | | | | | | | | | | This is used to package up the grub bootloader into a firmware volume where it can be executed as a shell like the UEFI Shell. Grub itself is built as a minimal entity into a Fv and then added as a boot option. By default the UEFI shell isn't built but for debugging purposes it can be enabled and will then be presented as a boot option (This should never be allowed for secure boot in an external data centre but may be useful for local debugging). Finally all other boot options except grub and possibly the shell are stripped and the boot timeout forced to 0 so the system will not enter a setup menu and will only boot to grub. This is done by copying the Library/PlatformBootManagerLib into Library/PlatformBootManagerLibGrub and then customizing it. Boot failure is fatal to try to prevent secret theft. Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3077 Signed-off-by: James Bottomley <jejb@linux.ibm.com> Message-Id: <20201130202819.3910-4-jejb@linux.ibm.com> Acked-by: Ard Biesheuvel <ard.biesheuvel@arm.com> [lersek@redhat.com: replace local variable initialization with assignment] Reviewed-by: Laszlo Ersek <lersek@redhat.com> [lersek@redhat.com: squash 'OvmfPkg: add "gGrubFileGuid=Grub" to GuidCheck.IgnoreDuplicates', reviewed stand-alone by Phil (msgid <e6eae551-8563-ccfb-5547-7a97da6d46e5@redhat.com>) and Ard (msgid <10aeda37-def6-d9a4-6e02-4c66c1492f57@arm.com>)]
* OvmfPkg/Amdsev: Base commit to build encrypted boot specific OVMFJames Bottomley2020-12-142-0/+1283
| | | | | | | | | | | | | | | This commit represents the file copied from OvmfPkgX64 with minor changes to change the build name. This package will form the basis for adding Sev specific features. Since everything must go into a single rom file for attestation, the separated build of code and variables is eliminated. Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3077 Signed-off-by: James Bottomley <jejb@linux.ibm.com> Message-Id: <20201130202819.3910-3-jejb@linux.ibm.com> Acked-by: Ard Biesheuvel <ard.biesheuvel@arm.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg/ResetVector: convert SEV-ES Reset Block structure to be GUIDedJames Bottomley2020-12-141-11/+40
| | | | | | | | | | | | Convert the current ES reset block structure to an extensible guid based structure by appending a header and length, which allow for multiple guid based data packets to be inserted. Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3077 Signed-off-by: James Bottomley <jejb@linux.ibm.com> Message-Id: <20201130202819.3910-2-jejb@linux.ibm.com> Acked-by: Ard Biesheuvel <ard.biesheuvel@arm.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg: Disable EccCheck CI until EccCheck issues are fixedSean Brogan2020-12-141-1/+2
| | | | | | | | | Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com> Message-Id: <20201210215640.1260-1-mikuback@linux.microsoft.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
* UefiCpuPkg/CpuFeature: reduce time complexty to calc CpuInfo.FirstRay Ni2020-12-141-49/+47
| | | | | | | | | | | | | | | | | | | | | | CpuInfo.First stores whether the current thread belongs to the first package in the platform, first core in a package, first thread in a core. But the time complexity of original algorithm to calculate the CpuInfo.First is O (n) * O (p) * O (c). n: number of processors p: number of packages c: number of cores per package The patch trades time with space by storing the first package, first core per package, first thread per core in an array. The time complexity becomes O (n). Signed-off-by: Ray Ni <ray.ni@intel.com> Reviewed-by: Eric Dong <eric.dong@intel.com> Reviewed-by: Star Zeng <star.zeng@intel.com> Cc: Yun Lou <yun.lou@intel.com> Cc: Laszlo Ersek <lersek@redhat.com>
* UefiCpuPkg RegisterCpuFeaturesLib: Use AllocatePages() for InitOrderStar Zeng2020-12-141-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | The required buffer size for InitOrder will be 96K when NumberOfCpus=1024. sizeof (CPU_FEATURES_INIT_ORDER) = 96 NumberOfCpus = 1024 = 1K sizeof (CPU_FEATURES_INIT_ORDER) * NumberOfCpus = 96K AllocateZeroPool() will call to PeiServicesAllocatePool() which will use EFI_HOB_MEMORY_POOL to management memory pool. EFI_HOB_MEMORY_POOL.Header.HobLength is UINT16 type, so there is no way for AllocateZeroPool() to allocate > 64K memory. So AllocateZeroPool() could not be used anymore for the case above or even bigger required buffer size. This patch updates the code to use AllocatePages() instead of AllocateZeroPool() to allocate buffer for InitOrder. Signed-off-by: Star Zeng <star.zeng@intel.com> Reviewed-by: Ray Ni <ray.ni@intel.com> Cc: Ray Ni <ray.ni@intel.com> Cc: Eric Dong <eric.dong@intel.com> Cc: Laszlo Ersek <lersek@redhat.com>
* MdeModulePkg: Fix SetMem parameter in OnigurumaUefiPortBaraneedharan Anbazhagan2020-12-141-1/+1
| | | | | | | | | | Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3085 Coding error in converting memset call to SetMem - Length and Value is not swapped on calling SetMem Signed-off-by: Baraneedharan Anbazhagan <anbazhagan@hp.com> Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
* ShellPkg/AcpiView: PCCT ParserMarc Moisson-Franckhauser2020-12-116-5/+679
| | | | | | | | | | | | | | | | | | | | Bugzilla: 3047 (https://bugzilla.tianocore.org/show_bug.cgi?id=3047) Create a new parser for the PCCT Table. The PCCT Table is used to describe how the OSPM can communicate with entities outside the platform. It describes which memory spaces correspond to which entity as well as a few of the needed information to handle the communications. This new PCCT parser dumps the values and names of the table fields. It also performs some validation on the table's fields. Signed-off-by: Marc Moisson-Franckhauser <marc.moisson-franckhauser@arm.com> Signed-off-by: Sami Mujawar <sami.mujawar@arm.com> Reviewed-by: Zhichao Gao <zhichao.gao@intel.com>
generated by cgit v1.2.3 (git 2.25.1) at 2024-07-16 07:05:35 +0000