summaryrefslogtreecommitdiff
path: root/OvmfPkg
AgeCommit message (Collapse)AuthorFilesLines
2018-02-11OvmfPkg: Add SafeIntLib and BmpSupportLib to DSC filesMichael D Kinney3-0/+6
https://bugzilla.tianocore.org/show_bug.cgi?id=800 Based on content from the following branch/commits: https://github.com/Microsoft/MS_UEFI/tree/share/MsCapsuleSupport https://github.com/Microsoft/MS_UEFI/commit/33bab4031a417d7d5a7d356c15a14c2e60302b2d https://github.com/Microsoft/MS_UEFI/commit/ca516b1a61315c2d823f453e12d2135098f53d61 https://github.com/Microsoft/MS_UEFI/commit/2b9f111f2e74a4c2ef4c4e32379e111f016dbd9b The BootGraphicsResourceTableDxe module uses the BmpSupportLib and SafeIntLib to convert a GOP BLT buffer to a BMP graphics image. Add library mappings for these new library classes. Cc: Sean Brogan <sean.brogan@microsoft.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Bret Barkelew <Bret.Barkelew@microsoft.com>
2018-02-08OvmfPkg/PlatformPei: sync AmdSevInitialize() definition with declarationLaszlo Ersek1-1/+2
"Platform.h" declares the AmdSevInitialize() function without EFIAPI, but the definition in "AmdSev.c" includes EFIAPI. GCC toolchains without LTO do not catch this error because "AmdSev.c" does not include "Platform.h"; i.e. the declaration used by callers such as "Platform.c" is not actually matched against the function definition at build time. With LTO enabled, the mismatch is found -- however, as a warning only, due to commit f8d0b9662993 ("BaseTools GCC5: disable warnings-as-errors for now", 2016-08-03). Include the header in the C file (which turns the issue into a hard build error on all GCC toolchains), plus sync the declaration from the header file to the C file. There's been no functional breakage because AmdSevInitialize() takes no parameters. Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Brijesh Singh <brijesh.singh@amd.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Fixes: 13b5d743c87a22dfcd94e8475d943dee5712b62d Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Brijesh Singh <brijesh.singh@amd.com> Reviewed-by: Jaben Carsey <jaben.carsey@intel.com> Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
2018-01-16OvmfPkg: Don't add -mno-mmx -mno-sse option for XCODE5 tool chainLiming Gao3-3/+9
Ovmf appended option -mno-mmx -mno-sse, but these two options were enabled in Openssl. The compiler option becomes -mmmx ?msse -mno-mmx -mno-sse. It trig mac clang compiler hang when compile one source file in openssl. This issue is found when SECURE_BOOT_ENABLE is TRUE. This may be the compiler issue. To work around it, don't add these two options for XCODE5 tool chain. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Liming Gao <liming.gao@intel.com> Cc: Andrew Fish <afish@apple.com> Cc: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
2018-01-15OvmfPkg/BaseMemEncryptSevLib: Enable protection for newly added page tableBrijesh Singh2-7/+399
Commit 2ac1730bf2a5 (MdeModulePkg/DxeIpl: Mark page table as read-only) sets the memory pages used for page table as read-only after paging is setup and sets CR0.WP to protect CPU modifying the read-only pages. The commit causes #PF when MemEncryptSevClearPageEncMask() or MemEncryptSevSetPageEncMask() tries to change the page-table attributes. This patch takes the similar approach as Commit 147fd35c3e38 (UefiCpuPkg/CpuDxe: Enable protection for newly added page table). When page table protection is enabled, we disable it temporarily before changing the page table attributes. This patch makes use of the same approach as Commit 2ac1730bf2a5 (MdeModulePkg/DxeIpl: Mark page table as read-only)) for allocating page table memory from reserved memory pool, which helps to reduce a potential "split" operation. The patch duplicates code from commit 147fd35c3e38. The code duplication will be removed after we implement page table manipulation library. See bugzilla https://bugzilla.tianocore.org/show_bug.cgi?id=847. Cc: Jian J Wang <jian.j.wang@intel.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Brijesh Singh <brijesh.singh@amd.com> Acked-by: Laszlo Ersek <lersek@redhat.com>
2017-11-29OvmfPkg: Add tftp dynamic commandRuiyu Ni6-9/+21
The TFTP command was converted from a NULL class library instance to a dynamic shell command in commit 0961002352e9. This patch complements commit f9bc2f876326, which only removed the old library, but didn't add the new dynamic command。 Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Anthony Perard <anthony.perard@citrix.com> Cc: Julien Grall <julien.grall@linaro.org>
2017-11-29OvmfPkg/Sec: Fix 64bit SEC build failureRuiyu Ni1-4/+2
Original code breaks a single assembly code to multiple lines. But, when VS CL.exe preprocesses the FixedPcdGet32() macro invocation to the replacement text, it loses '\', and causes NASM to fail. Changing the multiple lines to one line to resolve the build failure. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
2017-11-28OvmfPkg/QemuBootOrderLib: let an OFW devpath match multiple UEFI boot optsLaszlo Ersek1-1/+0
This means that SetBootOrderFromQemu() will preserve all UEFI boot options matched by any given OFW devpath, such as PXEv4, HTTPv4, PXEv6 and HTTPv6 boot options for the same NIC. Currently we stop the matching / appending for the OFW devpath coming from the outer loop whenever we find the first UEFI boot option match in the inner loop. (The previous patch was about multiple OFW devpaths matching a single UEFI boot option (which should never happen). This patch is about a single OFW devpath matching multiple UEFI boot options. With the "break" statement removed here, the small optimization from the last patch becomes a bit more relevant, because now the inner loop always counts up to ActiveCount.) Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
2017-11-28OvmfPkg/QemuBootOrderLib: skip already matched / appended UEFI boot optsLaszlo Ersek1-1/+2
The SetBootOrderFromQemu() function implements a nested loop where - the outer loop iterates over all OpenFirmware (OFW) device paths in the QEMU boot order, and translates each to a UEFI device path prefix; - the inner loop matches the current (translated) prefix against all active UEFI boot options in turn; - if the UEFI boot option is matched by the translated prefix, the UEFI boot option is appended to the "new" UEFI boot order, and marked as "has been appended". This patch adds a micro-optimization where already matched / appended UEFI boot options are skipped in the inner loop. This is not a functional change. A functional change would be if, as a consequence of the patch, some UEFI boot options would no longer be *doubly* matched. For a UEFI boot option to be matched by two translated prefixes, one of those prefixes would have to be a (proper, or equal) prefix of the other prefix. The PCI and MMIO OFW translation routines output such only in the following cases: - When the original OFW device paths are prefixes of each other. This is not possible from the QEMU side. (Only leaf devices are bootable.) - When the translation rules in the routines are incomplete, and don't look at the OFW device paths for sufficient length (i.e., at nodes where they would already differ, and the difference would show up in the translation output). This would be a shortcoming of the translation routines and should be fixed in TranslatePciOfwNodes() and TranslateMmioOfwNodes(), whenever identified. Even in the second case, this patch would replace the double appending of a single UEFI boot option (matched by two different OFW device paths) with a correct, or cross-, matching of two different UEFI boot options. Again, this is not expected, but arguably it would be more correct than duplicate boot option appending, should it occur due to any (unexpected, unknown) lack of detail in the translation routines. Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
2017-11-28OvmfPkg: Fix build failure due to Tftp library removalRuiyu Ni3-3/+0
Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
2017-11-17OvmfPkg: save on I/O port accesses when the debug port is not in usePaolo Bonzini4-9/+127
When SEV is enabled, every debug message printed by OVMF to the QEMU debug port traps from the guest to QEMU character by character because "REP OUTSB" cannot be used by IoWriteFifo8. Furthermore, when OVMF is built with the DEBUG_VERBOSE bit (value 0x00400000) enabled in "gEfiMdePkgTokenSpaceGuid.PcdDebugPrintErrorLevel", then the OvmfPkg/IoMmuDxe driver, and the OvmfPkg/Library/BaseMemEncryptSevLib library instance that is built into it, produce a huge amount of log messages. Therefore, in SEV guests, the boot time impact is huge (about 45 seconds _additional_ time spent writing to the debug port). While these messages are very useful for analyzing guest behavior, most of the time the user won't be capturing the OVMF debug log. In fact libvirt does not provide a method for configuring log capture; users that wish to do this (or are instructed to do this) have to resort to <qemu:arg>. The debug console device provides a handy detection mechanism; when read, it returns 0xE9 (which is very much unlike the 0xFF that is returned by an unused port). Use it to skip the possibly expensive OUT instructions when the debug I/O port isn't plugged anywhere. For SEC, the debug port has to be read before each full message. However: - if the debug port is available, then reading one byte before writing a full message isn't tragic, especially because SEC doesn't print many messages - if the debug port is not available, then reading one byte instead of writing a full message is still a win. Contributed-under: TianoCore Contribution Agreement 1.0 Cc: Laszlo Ersek <lersek@redhat.com> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Jordan Justen (Intel address) <jordan.l.justen@intel.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Tested-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
2017-11-17OvmfPkg: create a separate PlatformDebugLibIoPort instance for SECPaolo Bonzini8-19/+119
The next patch will want to add a global variable to PlatformDebugLibIoPort, but this is not suitable for the SEC phase, because SEC runs from read-only flash. The solution is to have two library instances, one for SEC and another for all other firmware phases. This patch adds the "plumbing" for the SEC library instance, separating the INF files and moving the constructor to a separate C source file. Contributed-under: TianoCore Contribution Agreement 1.1 Cc: Laszlo Ersek <lersek@redhat.com> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Jordan Justen (Intel address) <jordan.l.justen@intel.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Tested-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
2017-11-17OvmfPkg: make PlatformDebugLibIoPort a proper BASE libraryPaolo Bonzini1-3/+2
Remove Uefi.h, which includes UefiSpec.h, and change the return value to match the RETURN_STATUS type. Contributed-under: TianoCore Contribution Agreement 1.1 Cc: Laszlo Ersek <lersek@redhat.com> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Jordan Justen (Intel address) <jordan.l.justen@intel.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Tested-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
2017-11-17OvmfPkg: restore temporary SEC/PEI RAM size to 64KBLaszlo Ersek3-3/+3
(1) In the PEI phase, the PCD database is maintained in a GUID HOB. In OVMF, we load the PCD PEIM before any other PEIMs (using APRIORI PEI), so that all other PEIMs can use dynamic PCDs. Consequently, - the PCD GUID HOB is initially allocated from the temporary SEC/PEI heap, - whenever we introduce a dynamic PCD to a PEIM built into OVMF such that the PCD is new to OVMF's whole PEI phase, the PCD GUID HOB (and its temporary heap footprint) grow. I've noticed that, if we add just one more dynamic PCD to the PEI phase, then in the X64 build, - we get very close to the half of the temporary heap (i.e., 8192 bytes), - obscure PEI phase hangs or DXE core initialization failures (ASSERTs) occur. The symptoms vary between the FD_SIZE_2MB and FD_SIZE_4MB builds of X64 OVMF. (2) I've found that commit 2bbd7e2fbd4b ("UefiCpuPkg/MtrrLib: Update algorithm to calculate optimal settings", 2017-09-27) introduced a large (16KB) stack allocation: > The patch changes existing MtrrSetMemoryAttributeInMtrrSettings() and > MtrrSetMemoryAttribute() to use the 4-page stack buffer for calculation. > ... > +#define SCRATCH_BUFFER_SIZE (4 * SIZE_4KB) > ... > @@ -2207,17 +2462,66 @@ MtrrSetMemoryAttributeInMtrrSettings ( > ... > + UINT8 Scratch[SCRATCH_BUFFER_SIZE]; (3) OVMF's temp SEC/PEI RAM size has been 32KB ever since commit 7cb6b0e06809 ("OvmfPkg: Move SEC/PEI Temporary RAM from 0x70000 to 0x810000", 2014-01-21) Of that, the upper 16KB half is stack (growing down), and the lower 16KB half is heap. Thus, OvmfPkg/PlatformPei's calls to "UefiCpuPkg/Library/MtrrLib", in QemuInitializeRam(), cause the Scratch array to overflow the entire stack (heading towards lower addresses), and corrupt the heap below the stack. It turns out that the total stack demand is about 24KB, so the overflow is able to corrupt the upper 8KB of the heap. If that part of the heap is actually used (for example because we grow the PCD GUID HOB sufficiently), mayhem ensues. (4) Right after commit 7cb6b0e06809 (see above), there would be no room left above the 32KB temp SEC/PEI RAM. However, given more recent commits 45d870815156 ("OvmfPkg/PlatformPei: rebase and resize the permanent PEI memory for S3", 2016-07-13) 6b04cca4d697 ("OvmfPkg: remove PcdS3AcpiReservedMemoryBase, PcdS3AcpiReservedMemorySize", 2016-07-12) we can now restore the temp SEC/PEI RAM size to the original (pre-7cb6b0e06809) 64KB. This will allow for a 32KB temp SEC/PEI stack, which accommodates the ~24KB demand mentioned in (3). (Prior patches in this series will let us monitor the stack usage in the future.) Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=747 Ref: http://mid.mail-archive.com/a49cc089-12ae-a887-a4d6-4dc509233a74@redhat.com Ref: http://mid.mail-archive.com/03e369bb-77c4-0134-258f-bdae62cbc8c5@redhat.com Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
2017-11-17OvmfPkg/Sec/X64: seed the temporary RAM with PcdInitValueInTempStackLaszlo Ersek1-0/+21
This allows the PEI core to report the maximum temporary SEC/PEI stack usage on the DEBUG_INFO level, in the PeiCheckAndSwitchStack() function [MdeModulePkg/Core/Pei/Dispatcher/Dispatcher.c]: * Normal boot: > Temp Stack : BaseAddress=0x814000 Length=0x4000 > Temp Heap : BaseAddress=0x810000 Length=0x4000 > Total temporary memory: 32768 bytes. > temporary memory stack ever used: 5080 bytes. <---- > temporary memory heap used for HobList: 8080 bytes. > temporary memory heap occupied by memory pages: 0 bytes. * S3 resume (no SMM / PEI decompression) > Temp Stack : BaseAddress=0x814000 Length=0x4000 > Temp Heap : BaseAddress=0x810000 Length=0x4000 > Total temporary memory: 32768 bytes. > temporary memory stack ever used: 5048 bytes. <---- > temporary memory heap used for HobList: 7112 bytes. > temporary memory heap occupied by memory pages: 0 bytes. I unit-tested this change by transitorily adding an infinite loop right after the "rep stosq", and dumping the guest's temp SEC/PEI RAM (32KB currently) while the guest was stuck in the loop. The dump includes one dword from before and after the temp SEC/PEI RAM: > $ virsh qemu-monitor-command GUEST_NAME --hmp 'xp /8194wx 0x80FFFC' > > 000000000080fffc: 0x00000000 0x5aa55aa5 0x5aa55aa5 0x5aa55aa5 > 000000000081000c: 0x5aa55aa5 0x5aa55aa5 0x5aa55aa5 0x5aa55aa5 > ... > 0000000000817fec: 0x5aa55aa5 0x5aa55aa5 0x5aa55aa5 0x5aa55aa5 > 0000000000817ffc: 0x5aa55aa5 0x00000000 Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=747 Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
2017-11-17OvmfPkg/Sec/Ia32: seed the temporary RAM with PcdInitValueInTempStackLaszlo Ersek2-0/+19
This allows the PEI core to report the maximum temporary SEC/PEI stack usage on the DEBUG_INFO level, in the PeiCheckAndSwitchStack() function [MdeModulePkg/Core/Pei/Dispatcher/Dispatcher.c]: * Normal boot: > Temp Stack : BaseAddress=0x814000 Length=0x4000 > Temp Heap : BaseAddress=0x810000 Length=0x4000 > Total temporary memory: 32768 bytes. > temporary memory stack ever used: 3664 bytes. <---- > temporary memory heap used for HobList: 5904 bytes. > temporary memory heap occupied by memory pages: 0 bytes. * S3 resume (with PEI decompression / SMM): > Temp Stack : BaseAddress=0x814000 Length=0x4000 > Temp Heap : BaseAddress=0x810000 Length=0x4000 > Total temporary memory: 32768 bytes. > temporary memory stack ever used: 3428 bytes. <---- > temporary memory heap used for HobList: 4816 bytes. > temporary memory heap occupied by memory pages: 0 bytes. I unit-tested this change by transitorily adding an infinite loop right after the "rep stosd", and dumping the guest's temp SEC/PEI RAM (32KB currently) while the guest was stuck in the loop. The dump includes one dword from before and after the temp SEC/PEI RAM: > $ virsh qemu-monitor-command GUEST_NAME --hmp 'xp /8194wx 0x80FFFC' > > 000000000080fffc: 0x00000000 0x5aa55aa5 0x5aa55aa5 0x5aa55aa5 > 000000000081000c: 0x5aa55aa5 0x5aa55aa5 0x5aa55aa5 0x5aa55aa5 > ... > 0000000000817fec: 0x5aa55aa5 0x5aa55aa5 0x5aa55aa5 0x5aa55aa5 > 0000000000817ffc: 0x5aa55aa5 0x00000000 Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=747 Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
2017-11-17OvmfPkg/XenHypercallLib: enable virt extensions for ARMArd Biesheuvel2-0/+5
XenHypercallLib uses the 'hvc' instruction, which is not implemented on all ARMv7 CPUs, and so we need to explicitly specify a CPU that has the virtualization extensions. This override used to be set at the platform level, but this was removed in commit 0d36a219c7bdbb27d775b50837823b2a9928147c ('ArmPlatformPkg/PL031RealTimeClockLib: drop ArmPlatformSysConfigLib reference), under the assumption that all users of the 'hvc' instruction had already been fixed. So fix this for GNU binutils by adding the 'virt' arch extension directive, and for RVCT by setting the --cpu command line option to a CPU that is virt capable. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Acked-by: Laszlo Ersek <lersek@redhat.com>
2017-10-19OvmfPkg: fix dynamic default for oprom verification policy PCD without SBLaszlo Ersek3-9/+0
I missed the following, both while reviewing and while testing commit 6041ac65ae87 ("OvmfPkg/PlatformPei: DENY_EXECUTE_ON_SECURITY_VIOLATION when SEV is active", 2017-10-05): If "-D SECURE_BOOT_ENABLE" is not passed on the "build" command line, then OVMF has no dynamic default at all for "PcdOptionRomImageVerificationPolicy". This means that the PcdSet32S() call added in the subject commit doesn't even compile: > OvmfPkg/PlatformPei/AmdSev.c: In function 'AmdSevInitialize': > OvmfPkg/PlatformPei/AmdSev.c:67:3: error: implicit declaration of > function '_PCD_SET_MODE_32_S_PcdOptionRomImageVerificationPolicy' > [-Werror=implicit-function-declaration] > PcdStatus = PcdSet32S (PcdOptionRomImageVerificationPolicy, 0x4); > ^ > cc1: all warnings being treated as errors Make the current, SB-only, 0x00 dynamic default unconditional. This is the simplest approach, and it reflects the intent of original commit 1fea9ddb4e3f ("OvmfPkg: execute option ROM images regardless of Secure Boot", 2016-01-07). Without SECURE_BOOT_ENABLE, "SecurityPkg/Library/DxeImageVerificationLib" is not used anyway, so the PCD is never read. This issue was first caught and reported by Gerd Hoffmann <kraxel@redhat.com>'s Jenkins CI. Later it was also reported in <https://bugzilla.tianocore.org/show_bug.cgi?id=737>. Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Brijesh Singh <brijesh.singh@amd.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Fixes: 6041ac65ae879389f3ab5c0699f916d3e71c97fe Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Laszlo Ersek <lersek@redhat.com> [lersek@redhat.com: trim commit message as suggested by Jordan] Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> [lersek@redhat.com: add reference to TianoCore BZ#737]
2017-10-17OvmfPkg/PlatformPei: DENY_EXECUTE_ON_SECURITY_VIOLATION when SEV is activeBrijesh Singh5-12/+24
The following commit: 1fea9ddb4e3f OvmfPkg: execute option ROM images regardless of Secure Boot sets the OptionRomImageVerificationPolicy to ALWAYS_EXECUTE the expansion ROMs attached to the emulated PCI devices. A expansion ROM constitute another channel through which a cloud provider (i.e hypervisor) can inject a code in guest boot flow to compromise it. When SEV is enabled, the bios code has been verified by the guest owner via the SEV guest launch sequence before its executed. When secure boot, is enabled, lets make sure that we do not allow guest bios to execute a code which is not signed by the guest owner. Fixes: https://bugzilla.tianocore.org/show_bug.cgi?id=728 Cc: Chao Zhang <chao.b.zhang@intel.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Tom Lendacky <thomas.lendacky@amd.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Brijesh Singh <brijesh.singh@amd.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
2017-10-11OvmfPkg/QemuVideoDxe: Bypass NULL pointer detection during VBE SHIM installingJian J Wang2-0/+15
QemuVideoDxe driver will link VBE SHIM into page 0. If NULL pointer detection is enabled, this driver will fail to load. NULL pointer detection bypassing code is added to prevent such problem during boot. Please note that Windows 7 will try to access VBE SHIM during boot if it's installed, and then cause boot failure. This can be fixed by setting BIT7 of PcdNullPointerDetectionPropertyMask to disable NULL pointer detection after EndOfDxe. As far as we know, there's no other OSs has such issue. Cc: Laszlo Ersek <lersek@redhat.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Michael Kinney <michael.d.kinney@intel.com> Cc: Ayellet Wolman <ayellet.wolman@intel.com> Suggested-by: Ayellet Wolman <ayellet.wolman@intel.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Jian J Wang <jian.j.wang@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
2017-10-03OvmfPkg/PciHotPlugInitDxe: translate QEMU's resource reservation hintsLaszlo Ersek2-6/+367
Parse QEMU_PCI_BRIDGE_CAPABILITY_RESOURCE_RESERVATION from the bridges' conventional config spaces. Translate the fields as follows: * BusNumbers: * 0 -- no reservation; * (-1) -- firmware default, i.e. no reservation; * otherwise -- reserve the requested value. (NB, bus number reservation is not supposed to work before <https://bugzilla.tianocore.org/show_bug.cgi?id=656> is fixed.) * Io: * 0 -- no reservation; * (-1) -- keep our current default (512B); * otherwise -- round up the requested value and reserve that. * NonPrefetchable32BitMmio: * 0 -- no reservation; * (-1) -- keep our current default (2MB); * otherwise -- round up the requested value and reserve that. * Prefetchable32BitMmio: * 0 -- no reservation, proceed to Prefetchable64BitMmio; * (-1) -- firmware default, i.e. no reservation, proceed to Prefetchable64BitMmio; * otherwise -- round up the requested value and reserve that. (NB, if Prefetchable32BitMmio is reserved in addition to NonPrefetchable32BitMmio, then PciBusDxe currently runs into an assertion failure. Refer to <https://bugzilla.tianocore.org/show_bug.cgi?id=720>.) * Prefetchable64BitMmio: * only reached if Prefetchable32BitMmio was not reserved; * 0 -- no reservation; * (-1) -- firmware default, i.e. no reservation; * otherwise -- round up the requested value and reserve that. If QEMU_PCI_BRIDGE_CAPABILITY_RESOURCE_RESERVATION is missing, plus any time the rounding fails, fall back to the current defaults. Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Marcel Apfelbaum <marcel@redhat.com> Cc: Ruiyu Ni <ruiyu.ni@intel.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
2017-10-03OvmfPkg/PciHotPlugInitDxe: add helper functions for setting up paddingsLaszlo Ersek2-10/+156
Extract the SetIoPadding() and SetMmioPadding() functions, so that we can set EFI_ACPI_ADDRESS_SPACE_DESCRIPTOR fields using parameter names and values that are more friendly than the original field names and their expected values. Introduce the HighBitSetRoundUp32() and HighBitSetRoundUp64() functions for calculating the last parameter ("SizeExponent") of SetIoPadding() and SetMmioPadding(). Put the new functions to use when requesting the default reservations. (In order to be consistent with a later patch, "SizeExponent" is calculated for SetIoPadding() with HighBitSetRoundUp64().) Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Marcel Apfelbaum <marcel@redhat.com> Cc: Ruiyu Ni <ruiyu.ni@intel.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
2017-10-03OvmfPkg/PciHotPlugInitDxe: generalize RESOURCE_PADDING compositionLaszlo Ersek2-64/+98
PciHotPlugInitDxe has a static variable called "mPadding" (of type RESOURCE_PADDING), which describes two constant resource reservations: - MmioPadding: 2MB of non-prefetchable (hence 32-bit) MMIO space, - IoPadding: 512B of IO space. In the GetResourcePadding() member function of EFI_PCI_HOT_PLUG_INIT_PROTOCOL, the driver outputs a dynamically allocated verbatim copy of "mPadding", for PciBusDxe to consume in its ApplyResourcePadding() function. In a later patch, we're going to compose the set of resource reservations dynamically, based on QEMU hints. Generalize the RESOURCE_PADDING structure so that we may generate (or not generate) each resource type individually: - Replace the named "MmioPadding" and "IoPadding" fields in RESOURCE_PADDING with an array of descriptors, - remove "mPadding", - in GetResourcePadding(), request the same (default) reservations as before, as if we attempted and failed to fetch the QEMU hints. Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Marcel Apfelbaum <marcel@redhat.com> Cc: Ruiyu Ni <ruiyu.ni@intel.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
2017-10-03OvmfPkg/PciHotPlugInitDxe: clean up addr. range for non-prefetchable MMIOLaszlo Ersek1-2/+2
The non-prefetchable MMIO aperture of a bridge can never fall outside of the 32-bit address space. Namely, the MemoryBase and MemoryLimit fields in PCI_BRIDGE_CONTROL_REGISTER have type UINT16, and based on the PCI-to-PCI Bridge Architecture Spec, Chapter 3.2, the actual MMIO aperture is determined as in: NonPrefetchMemoryBase = (((MemoryBase & 0xFFF0u) >> 4) << 20) | 0x00000 NonPrefetchMemoryLimit = (((MemoryLimit & 0xFFF0u) >> 4) << 20) | 0xFFFFF In "OvmfPkg/PciHotPlugInitDxe", the "mPadding.MmioPadding.AddrSpaceGranularity" field is currently initialized to 64. According to the above, this is useless generality: a non-prefetchable MMIO reservation may only be satisfied from 32-bit address space. Update the field to 32. In practice this change makes no difference, because PciBusDxe already enforces the 32-bit limitation when it sees "non-prefetchable" from (SpecificFlag==0). Quoting commit 8aba40b79267 ("OvmfPkg: add PciHotPlugInitDxe", 2016-06-30): "regardless of our request for 64-bit MMIO reservation, it is downgraded to 32-bit". (See the Platform Init Spec 1.6, Volume 5, - Table 8. "ACPI 2.0 & 3.0 QWORD Address Space Descriptor Usage", and - Table 11. "Memory Resource Flag (Resource Type = 0) Usage", for an explanation of the "mPadding.MmioPadding" fields.) Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Marcel Apfelbaum <marcel@redhat.com> Cc: Ruiyu Ni <ruiyu.ni@intel.com> Fixes: 8aba40b79267df761bd24d6874ae87f47a7bd3de Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
2017-10-03OvmfPkg/PciHotPlugInitDxe: clean up protocol usage commentLaszlo Ersek1-1/+1
The driver always produces an instance of the EFI_PCI_HOT_PLUG_INIT_PROTOCOL. The "SOMETIMES_PRODUCES" remark is an oversight from the original v1->v2 patch update; v2 should have stated "ALWAYS_PRODUCES": http://mid.mail-archive.com/1468242274-12686-5-git-send-email-lersek@redhat.com > Notes: > v2: > - drop the PcdPciBusHotplugDeviceSupport check, and the PcdLib > dependency with it [Jordan] Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Marcel Apfelbaum <marcel@redhat.com> Cc: Ruiyu Ni <ruiyu.ni@intel.com> Fixes: 8aba40b79267df761bd24d6874ae87f47a7bd3de Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
2017-10-03OvmfPkg/IndustryStandard: define PCI Capabilities for QEMU's PCI BridgesLaszlo Ersek1-0/+60
QEMU has recently gained the ability to provide various hints about its PCI bridges. The hints take the form of vendor-specific PCI capabilities. Define macros and types under "OvmfPkg/Include/IndustryStandard" to describe these capabilities. The definitions correspond to "docs/pcie_pci_bridge.txt" in the QEMU tree. Said documentation was added in the last commit of the following series: a35fe226558a hw/pci: introduce pcie-pci-bridge device 70e1ee59bb94 hw/pci: introduce bridge-only vendor-specific capability to provide some hints to firmware 226263fb5cda hw/pci: add QEMU-specific PCI capability to the Generic PCI Express Root Port c1800a162765 docs: update documentation considering PCIE-PCI bridge We are going to parse the Resource Reservation Capability in OvmfPkg/PciHotPlugInitDxe, and return the reservation requests to PciBusDxe. Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Marcel Apfelbaum <marcel@redhat.com> Cc: Ruiyu Ni <ruiyu.ni@intel.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
2017-09-22OvmfPkg/VirtioNetDxe: log debug message in VirtioNetExitBoot()Laszlo Ersek1-0/+1
The other four virtio device drivers (VirtioBlkDxe, VirtioGpuDxe, VirtioRngDxe, VirtioScsiDxe) log such messages at this point; follow suit. Cc: Brijesh Singh <brijesh.singh@amd.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Brijesh Singh <brijesh.singh@amd.com>
2017-09-22OvmfPkg/VirtioNetDxe: document Rx/Tx allocs and mappings on Init/ShutdownLaszlo Ersek1-4/+8
Document the following actions on the EfiSimpleNetworkStarted <-> EfiSimpleNetworkInitialized state transitions: * from commit 46b11f00ac70 ("OvmfPkg/VirtioNetDxe: alloc RxBuf using AllocateSharedPages()", 2017-09-14): VirtioNetInitRx -> { VirtIo->AllocateSharedPages, VirtioMapAllBytesInSharedBuffer } VirtioNetShutdownRx -> { VirtIo->UnmapSharedBuffer, VirtIo->FreeSharedPages } * from commit 891f016c1b99 ("OvmfPkg/VirtioNetDxe: dynamically alloc transmit header", 2017-09-14): VirtioNetInitTx -> { VirtIo->AllocateSharedPages, VirtioMapAllBytesInSharedBuffer } VirtioNetShutdownTx -> { VirtIo->UnmapSharedBuffer, VirtIo->FreeSharedPages } Cc: Brijesh Singh <brijesh.singh@amd.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Brijesh Singh <brijesh.singh@amd.com>
2017-09-22OvmfPkg/QemuBootOrderLib: recognize "usb-storage" devices in XHCI portsLaszlo Ersek1-0/+44
The feature is primarily useful for modern AARCH64 guests that have no built-in virtio block / SCSI drivers; as on "qemu-system-aarch64 -M virt", there are no IDE or AHCI controllers that could be used as fallback. XHCI is available in "-M virt" however, and because XHCI predates AARCH64 by several years, said guests are expected to have built-in drivers for it. Other device models ("usb-uas", "usb-bot") are out of scope for now, similarly to USB1.x (UHCI) and USB2 (EHCI) host controllers, and similarly to USB hubs (which are USB1.1 only). In particular, port mapping between EHCI and companion UHCI controllers is very complex; it even leads to PCI slot/function differences between the OpenFirmware device paths exported by QEMU and the the UEFI device paths generated by edk2. The number of ports on the XHCI controller defaults to 4, but it can be raised via the "p3" property to 15. In addition, several XHCI controllers can be grouped into a single-slot, multi-function PCI device. These allow for a good number of usb-storage devices, while their desired boot order remains recognizable to this patch. In the example below, we create two XHCI controllers, grouped into PCI slot 00:02 as functions 0 and 1. Both controllers are given 15 ports. We attach a "usb-storage" device to controller 1 at port 3 (ports are 1-based in QEMU, 0-based in edk2), and attach another "usb-storage" device to controller 2 at port 9. QEMU command line options (NB. they apply equally to aarch64/virt and x86_64/{i440fx,q35}): -device qemu-xhci,id=xhci1,p3=15,addr=02.0,multifunction=on \ -device qemu-xhci,id=xhci2,p3=15,addr=02.1 \ \ -drive id=disk1,if=none,format=qcow2,$DISK1_OPTIONS \ -drive id=disk2,if=none,format=qcow2,$DISK2_OPTIONS \ \ -device usb-storage,drive=disk1,bus=xhci1.0,port=3,bootindex=1 \ -device usb-storage,drive=disk2,bus=xhci2.0,port=9,bootindex=2 \ Libvirt domain XML fragment: <controller type='usb' index='1' model='qemu-xhci' ports='15'> <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0' multifunction='on'/> </controller> <controller type='usb' index='2' model='qemu-xhci' ports='15'> <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x1'/> </controller> <disk type='file' device='disk'> <driver name='qemu' type='qcow2'/> <source file='...'/> <target dev='sda' bus='usb'/> <boot order='1'/> <address type='usb' bus='1' port='3'/> </disk> <disk type='file' device='disk'> <driver name='qemu' type='qcow2'/> <source file='...'/> <target dev='sdb' bus='usb'/> <boot order='2'/> <address type='usb' bus='2' port='9'/> </disk> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
2017-09-20OvmfPkg/QemuVideoDxe/VbeShim: handle PAM1 register on Q35 correctlyLaszlo Ersek2-2/+28
In commit db27e9f3d8f0 ("OvmfPkg/LegacyRegion: Support legacy region manipulation of Q35", 2016-03-15), Ray extended the OvmfPkg/Csm/CsmSupportLib PAM register manipulation to Q35. However, we missed that the same should be done to the QemuVideoDxe VBE Shim as well. The omission has caused no problems in practice on Q35, because QEMU has let us write to the ROM area, regardless of the PAM1 setting, all this time. This has now changed with recent QEMU commit 208fa0e43645 ("pc: make 'pc.rom' readonly when machine has PCI enabled", 2017-07-28). The QEMU commit exposes the OVMF bug when Windows 7 is started on Q35, using QEMU 2.10 -- the VBE Shim is no longer put in place and Windows 7 cannot find it. To remedy this, assign the "Pam1Address" local variable a PciLib address that matches the board type (i440fx vs. q35). Regarding the PcdLib dependency: QemuVideoDxe already uses PcdLib, both directly (see "PcdDriverSupportedEfiVersion") and indirectly (e.g. via the DxePciLibI440FxQ35 PciLib instance). Add PcdLib to [LibraryClasses] for completeness. Cc: Aleksei Kovura <alex3kov@zoho.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Igor Mammedov <imammedo@redhat.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Ruiyu Ni <ruiyu.ni@intel.com> Ref: https://bugs.launchpad.net/qemu/+bug/1715700 Reported-by: Aleksei Kovura <alex3kov@zoho.com> Special-thanks-to: Gerd Hoffmann <kraxel@redhat.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Tested-by: Aleksei Kovura <alex3kov@zoho.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
2017-09-20OvmfPkg/QemuVideoDxe/VbeShim: rename Status to Segment0AllocationStatusLaszlo Ersek1-7/+15
This clarifies the purpose of the local variable in InstallVbeShim(). Cc: Aleksei Kovura <alex3kov@zoho.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Igor Mammedov <imammedo@redhat.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Ruiyu Ni <ruiyu.ni@intel.com> Ref: https://bugs.launchpad.net/qemu/+bug/1715700 Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Tested-by: Aleksei Kovura <alex3kov@zoho.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
2017-09-20OvmfPkg/CsmSupportLib: move PAM register addresses to IndustryStandardLaszlo Ersek4-52/+53
* Introduce the PIIX4_PAM* and MCH_PAM* macros under "OvmfPkg/Include/IndustryStandard". These macros capture the PAM register offsets (in PCI config space) on the respective Memory Controller B/D/F, from the respective data sheets. * Under IndustryStandard, introduce the PMC_REGISTER_PIIX4() macro for PIIX4. (For Q35, we already have DRAMC_REGISTER_Q35().) In both cases, the B/D/F is 0/0/0. * Under CsmSupportLib, replace the "PAMRegOffset" field (UINT8) in the PAM_REGISTER_VALUE structure with "PAMRegPciLibAddress" (UINTN). The new field contains the return value of the PCI_LIB_ADDRESS() macro. * Under CsmSupportLib, replace the "mRegisterValues440" elements as follows: REG_PAMx_OFFSET_440, ReadEnableData, WriteEnableData --> PMC_REGISTER_PIIX4 (PIIX4_PAMx), ReadEnableData, WriteEnableData * Under CsmSupportLib, replace the "mRegisterValuesQ35" elements as follows: REG_PAMx_OFFSET_Q35, ReadEnableData, WriteEnableData --> DRAMC_REGISTER_Q35 (MCH_PAMx), ReadEnableData, WriteEnableData * Under CsmSupportLib, update the register address calculations as follows (for all of PciOr8(), PciAnd8() and PciRead8()): PCI_LIB_ADDRESS ( PAM_PCI_BUS, PAM_PCI_DEV, PAM_PCI_FUNC, mRegisterValues[Index].PAMRegOffset ) --> mRegisterValues[Index].PAMRegPciLibAddress * Under CsmSupportLib, remove the PAM_PCI_* and REG_PAM*_OFFSET_* macros. Technically speaking, these changes could be split into three patches (IndustryStandard macro additions, CsmSupportLib code updates, CsmSupportLib macro removals). However, the patch is not big, and in this case it is actually helpful to present the code movement / refactoring in one step, for easier verification. Cc: Aleksei Kovura <alex3kov@zoho.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Igor Mammedov <imammedo@redhat.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Ruiyu Ni <ruiyu.ni@intel.com> Ref: https://bugs.launchpad.net/qemu/+bug/1715700 Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Tested-by: Aleksei Kovura <alex3kov@zoho.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
2017-09-14OvmfPkg/VirtioNetDxe: negotiate VIRTIO_F_IOMMU_PLATFORMBrijesh Singh1-2/+3
VirtioNetDxe driver has been updated to use IOMMU-like member functions from VIRTIO_DEVICE_PROTOCOL to translate the system physical address to device address. We do not need to do anything special when VIRTIO_F_IOMMU_PLATFORM bit is present hence treat it in parallel with VIRTIO_F_VERSION_1. Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Tom Lendacky <thomas.lendacky@amd.com> Cc: Laszlo Ersek <lersek@redhat.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Brijesh Singh <brijesh.singh@amd.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Regression-tested-by: Laszlo Ersek <lersek@redhat.com> Tested-by: Laszlo Ersek <lersek@redhat.com>
2017-09-14OvmfPkg/VirtioNetDxe: map caller-supplied Tx packet to device-addressBrijesh Singh2-13/+49
When device is behind the IOMMU, driver is require to pass the device address of caller-supplied transmit buffer for the bus master operations. The patch uses VirtioNetMapTxBuf() to map caller-supplied Tx packet to a device-address and enqueue the device address in VRING for transfer and perform the reverse mapping when transfer is completed so that we can return the caller-supplied buffer. Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Tom Lendacky <thomas.lendacky@amd.com> Cc: Laszlo Ersek <lersek@redhat.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Brijesh Singh <brijesh.singh@amd.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Regression-tested-by: Laszlo Ersek <lersek@redhat.com> Tested-by: Laszlo Ersek <lersek@redhat.com>
2017-09-14OvmfPkg/VirtioNetDxe: add Tx packet map/unmap helper functionsBrijesh Singh4-2/+279
When device is behind IOMMU, driver is require to pass the device address of TxBuf in the Tx VRING. The patch adds helper functions and data structure to map and unmap the TxBuf system physical address to a device address. Since the TxBuf is returned back to caller from VirtioNetGetStatus() hence we use OrderedCollection interface to save the TxBuf system physical to device address mapping. After the TxBuf is succesfully transmitted VirtioNetUnmapTxBuf() does the reverse lookup in OrderedCollection data structure to get the system physical address of TxBuf for a given device address. Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Tom Lendacky <thomas.lendacky@amd.com> Cc: Laszlo Ersek <lersek@redhat.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Brijesh Singh <brijesh.singh@amd.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Regression-tested-by: Laszlo Ersek <lersek@redhat.com> Tested-by: Laszlo Ersek <lersek@redhat.com>
2017-09-14OvmfPkg/VirtioNetDxe: update TechNotesBrijesh Singh1-7/+13
In next patches we will update Virtio transmit to use the device-mapped address of the caller-supplied packet. The patch documents the new model. Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Tom Lendacky <thomas.lendacky@amd.com> Cc: Laszlo Ersek <lersek@redhat.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Brijesh Singh <brijesh.singh@amd.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Regression-tested-by: Laszlo Ersek <lersek@redhat.com> Tested-by: Laszlo Ersek <lersek@redhat.com>
2017-09-14OvmfPkg/VirtioNetDxe: dynamically alloc transmit headerBrijesh Singh3-9/+65
Each network packet is submitted for transmission by pushing the head descriptor of a two-part descriptor chain to the Available Ring of the TX queue. VirtioNetInitTx() sets up the the descriptor chains for all queueable packets in advance, and points all the head descriptors to the same shared, never modified, VIRTIO_1_0_NET_REQ header object (or its initial VIRTIO_NET_REQ sub-object, dependent on virtio version). VirtioNetInitTx() currently uses the header object's system physical address for populating the head descriptors. When device is behind the IOMMU, VirtioNet driver is required to provide the device address of VIRTIO_1_0_NET_REQ header. In this patch we dynamically allocate the header using AllocateSharedPages() and map with BusMasterCommonBuffer so that header can be accessed by both processor and the device. We map the header object for CommonBuffer operation because, in order to stick with the current code order, we populate the head descriptors with the header's device address first, and fill in the header itself second. Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Tom Lendacky <thomas.lendacky@amd.com> Cc: Laszlo Ersek <lersek@redhat.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Brijesh Singh <brijesh.singh@amd.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Regression-tested-by: Laszlo Ersek <lersek@redhat.com> Tested-by: Laszlo Ersek <lersek@redhat.com>
2017-09-14OvmfPkg/VirtioNetDxe: alloc RxBuf using AllocateSharedPages()Brijesh Singh5-21/+75
When device is behind the IOMMU, VirtioNetDxe is required to use the device address in bus master operations. RxBuf is allocated using AllocatePool() which returns the system physical address. The patch uses VIRTIO_DEVICE_PROTOCOL.AllocateSharedPages() to allocate the RxBuf and map with VirtioMapAllBytesInSharedBuffer() so that we can obtain the device address for RxBuf. Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Tom Lendacky <thomas.lendacky@amd.com> Cc: Laszlo Ersek <lersek@redhat.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Brijesh Singh <brijesh.singh@amd.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Regression-tested-by: Laszlo Ersek <lersek@redhat.com> Tested-by: Laszlo Ersek <lersek@redhat.com>
2017-09-14OvmfPkg/VirtioNetDxe: map VRINGs using VirtioRingMap()Brijesh Singh5-19/+57
When device is behind the IOMMU then driver need to pass the device address when programing the bus master. The patch uses VirtioRingMap() to map the VRING system physical address[es] to device address[es]. Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Tom Lendacky <thomas.lendacky@amd.com> Cc: Laszlo Ersek <lersek@redhat.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Brijesh Singh <brijesh.singh@amd.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Regression-tested-by: Laszlo Ersek <lersek@redhat.com> Tested-by: Laszlo Ersek <lersek@redhat.com>
2017-09-14OvmfPkg/VirtioNetDxe: add helper VirtioNetUninitRing()Brijesh Singh5-6/+30
Consolidate the virtio VRING resource cleanup into VirtioNetUninitRing(). Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Tom Lendacky <thomas.lendacky@amd.com> Cc: Laszlo Ersek <lersek@redhat.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Brijesh Singh <brijesh.singh@amd.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Regression-tested-by: Laszlo Ersek <lersek@redhat.com> Tested-by: Laszlo Ersek <lersek@redhat.com>
2017-09-11OvmfPkg/SataControllerDxe: log informative message at DEBUG_INFO levelLaszlo Ersek1-1/+12
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. (In fact it is so much an expected condition that recent USWG Mantis ticket <https://mantis.uefi.org/mantis/view.php?id=1815> will codify its additional edk2-specific behavior, namely to output the protocol interface at once.) 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, "SataControllerStart START", and "SataControllerStart END status = %r" (at which point Status can only be EFI_SUCCESS). Cc: Jordan Justen <jordan.l.justen@intel.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Laszlo Ersek <lersek@redhat.com>
2017-09-11OvmfPkg/PlatformBootManagerLib: log informative message at DEBUG_INFO lvlLaszlo Ersek1-1/+1
"Boot Mode:%x" is an informative message, not an error report. Set its debug mask to DEBUG_INFO. Cc: Jordan Justen <jordan.l.justen@intel.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Laszlo Ersek <lersek@redhat.com>
2017-09-11OvmfPkg/PlatformPei: log informative message at DEBUG_INFO levelLaszlo Ersek1-1/+1
"Platform PEIM Loaded" is an informative message, not an error report. Set its debug mask to DEBUG_INFO. Cc: Jordan Justen <jordan.l.justen@intel.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Laszlo Ersek <lersek@redhat.com>
2017-09-11OvmfPkg/PlatformDebugLibIoPort: write messages with IoWriteFifo8()Laszlo Ersek1-12/+8
Since commit 19c6d9feaaf8 ("MdePkg: Expand BaseIoLibIntrinsic (IoLib class) library", 2017-01-14), IoWriteFifo8() has been widely available to modules. Use it to print debug messages and assertion failures to the QEMU debug port, rather than open-coded loops. In the general case this speeds up logging, because debug messages will now trap to QEMU once per message (as opposed to once per character), due to "REP OUTSB" in "MdePkg/Library/BaseIoLibIntrinsic/*/IoFifoSev.nasm". In SEV guests, there is no speedup (SEV doesn't support the REP prefix). SEV is detected internally to BaseIoLibIntrinsic. Cc: Brijesh Singh <brijesh.singh@amd.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Acked-by: Brijesh Singh <brijesh.singh@amd.com>
2017-09-08OvmfPkg: Enable UDF file system supportPaulo Alcantara6-0/+6
This patch enables UDF file system support by default. Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Paulo Alcantara <pcacjr@zytor.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com>
2017-09-08OvmfPkg/IoMmuDxe: unmap all IOMMU mappings at ExitBootServices()Laszlo Ersek1-0/+145
Register an ExitBootServices() callback that tears down all IOMMU mappings, without modifying the UEFI memory map. The trick is that in the ExitBootServices() callback, we don't immediately do the work; instead we signal another (private) event. Normally the dispatch order of ExitBootServices() callbacks is unspecified (within the same task priority level anyway). By queueing another function, we delay the unmapping until after all PciIo and Virtio drivers abort -- in their own ExitBootServices() callbacks -- the pending DMA operations of their respective controllers. Furthermore, the fact that IoMmuUnmapWorker() rewrites client-owned memory when it unmaps a Write or CommonBuffer bus master operation, is safe even in this context. The existence of any given "MapInfo" in "mMapInfos" implies that the client buffer pointed-to by "MapInfo->CryptedAddress" was live when ExitBootServices() was entered. And, after entering ExitBootServices(), nothing must have changed the UEFI memory map, hence the client buffer at "MapInfo->CryptedAddress" still exists. Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Brijesh Singh <brijesh.singh@amd.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Brijesh Singh <brijesh.singh@amd.com> Tested-by: Brijesh Singh <brijesh.singh@amd.com>
2017-09-08OvmfPkg/IoMmuDxe: generalize IoMmuUnmap() to IoMmuUnmapWorker()Laszlo Ersek1-7/+53
IoMmuUnmapWorker() is identical to IoMmuUnmap(), it just takes an additional BOOLEAN parameter called "MemoryMapLocked". If the memory map is locked, IoMmuUnmapWorker() does its usual job, but it purposely leaks memory rather than freeing it. This makes it callable from ExitBootServices() context. Turn IoMmuUnmap() into a thin wrapper around IoMmuUnmapWorker() that passes constant FALSE for "MemoryMapLocked". Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Brijesh Singh <brijesh.singh@amd.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Brijesh Singh <brijesh.singh@amd.com> Tested-by: Brijesh Singh <brijesh.singh@amd.com>
2017-09-08OvmfPkg/IoMmuDxe: track all mappingsLaszlo Ersek1-31/+18
The "mRecycledMapInfos" list implements an internal pool of unused MAP_INFO structures between the IoMmuUnmap() and IoMmuMap() functions. The original goal was to allow IoMmuUnmap() to tear down CommonBuffer mappings without releasing any memory: IoMmuUnmap() would recycle the MAP_INFO structure to the list, and IoMmuMap() would always check the list first, before allocating a brand new MAP_INFO structure. In one of the following patches, we'll change OvmfPkg/IoMmuDxe so that it unmaps all existent bus master operations (CommonBuffer, Read, Write) at ExitBootServices(), strictly after the individual device drivers abort pending DMA on the devices they manage, in their own ExitBootServices() notification functions. For this, rename and repurpose the list to track all live mappings. This means that IoMmuUnmap() will always release a MAP_INFO structure (even when cleaning up a CommonBuffer operation). That's fine (for now), because device drivers are no longer expected to call Unmap() in their ExitBootServices() notification functions. In theory, we could also move the allocation and freeing of the stash buffer from IoMmuAllocateBuffer() and IoMmuFreeBuffer(), respectively, to IoMmuMap() and IoMmuUnmap(). However, this would require allocating and freeing a stash buffer in *both* IoMmuMap() and IoMmuUnmap(), as IoMmuMap() performs in-place decryption for CommonBuffer operations, and IoMmuUnmap() performs in-place encryption for the same. By keeping the stash buffer allocation as-is, not only do we keep the code almost fully undisturbed, but - we also continue to guarantee that IoMmuUnmap() succeeds: allocating a stash buffer in IoMmuUnmap(), for in-place encryption after a CommonBuffer operation, could fail; - we also keep IoMmuUnmap() largely reusable for ExitBootServices() callback context: allocating a stash buffer in IoMmuUnmap() would simply be forbidden in that context. Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Brijesh Singh <brijesh.singh@amd.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Brijesh Singh <brijesh.singh@amd.com> Tested-by: Brijesh Singh <brijesh.singh@amd.com>
2017-09-08OvmfPkg/VirtioScsiDxe: don't unmap VRING at ExitBootServices()Laszlo Ersek1-6/+1
In one of the following patches, we'll change OvmfPkg/IoMmuDxe so that it unmaps all existent bus master operations (CommonBuffer, Read, Write) at ExitBootServices(), strictly after the individual device drivers abort pending DMA on the devices they manage, in their own ExitBootServices() notification functions. In preparation, remove the explicit VIRTIO_DEVICE_PROTOCOL.UnmapSharedBuffer() call from VirtioScsiExitBoot(), originally added in commit fc2168feb248 ("OvmfPkg/VirtioScsiDxe: map VRING using VirtioRingMap()", 2017-08-31). Add a DEBUG message so we can observe the ordering between VirtioScsiExitBoot() and the upcoming cleanup of mappings in OvmfPkg/IoMmuDxe. Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Brijesh Singh <brijesh.singh@amd.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Brijesh Singh <brijesh.singh@amd.com> Tested-by: Brijesh Singh <brijesh.singh@amd.com>
2017-09-08OvmfPkg/VirtioRngDxe: don't unmap VRING at ExitBootServices()Laszlo Ersek1-6/+1
In one of the following patches, we'll change OvmfPkg/IoMmuDxe so that it unmaps all existent bus master operations (CommonBuffer, Read, Write) at ExitBootServices(), strictly after the individual device drivers abort pending DMA on the devices they manage, in their own ExitBootServices() notification functions. In preparation, remove the explicit VIRTIO_DEVICE_PROTOCOL.UnmapSharedBuffer() call from VirtioRngExitBoot(), originally added in commit 0a568ccbcbd1 ("OvmfPkg/VirtioRngDxe: map host address to device address", 2017-08-23). Add a DEBUG message so we can observe the ordering between VirtioRngExitBoot() and the upcoming cleanup of mappings in OvmfPkg/IoMmuDxe. Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Brijesh Singh <brijesh.singh@amd.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Brijesh Singh <brijesh.singh@amd.com> Tested-by: Brijesh Singh <brijesh.singh@amd.com>
2017-09-08OvmfPkg/VirtioGpuDxe: don't unmap VRING & BackingStore at ExitBootServicesLaszlo Ersek1-22/+1
In one of the following patches, we'll change OvmfPkg/IoMmuDxe so that it unmaps all existent bus master operations (CommonBuffer, Read, Write) at ExitBootServices(), strictly after the individual device drivers abort pending DMA on the devices they manage, in their own ExitBootServices() notification functions. In preparation, remove the explicit VIRTIO_DEVICE_PROTOCOL.UnmapSharedBuffer() calls from VirtioGpuExitBoot(), originally added in commit 9bc5026c19a5 ("OvmfPkg/VirtioGpuDxe: map VRING for bus master common buffer operation", 2017-08-26) and commit f10ae923665f ("OvmfPkg/VirtioGpuDxe: map backing store to bus master device address", 2017-08-26). Add a DEBUG message so we can observe the ordering between VirtioGpuExitBoot() and the upcoming cleanup of mappings in OvmfPkg/IoMmuDxe. Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Brijesh Singh <brijesh.singh@amd.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Brijesh Singh <brijesh.singh@amd.com> Tested-by: Brijesh Singh <brijesh.singh@amd.com>
generated by cgit v1.1 at 2024-11-14 05:53:03 +0000