summaryrefslogtreecommitdiff
path: root/OvmfPkg
AgeCommit message (Collapse)Author
2013-08-30OvmfPkg NvVarsFileLib: Set NvVars variable after writing vars fileJordan Justen
The volatile 'NvVars' variable indicates that the variables do not need to be loaded from the file again. After we write the variables out to the file, there is clearly no need to load them back from the file. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Jordan Justen <jordan.l.justen@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Tested-by: Michael Chang <mchang@suse.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@14613 6f19259b-4bc3-4df7-8a09-765794883524
2013-08-281. Change default PCD in SecurityPkg to 4 (DENY_EXECUTE) in DEC file.Fu Siyuan
2. ASSERT if PCD value is set to 5 (QUERY_USER_ON_SECURITY_VIOLATION). 3. Update override PCD setting from 5 to 4 in platform DSC file. Signed-off-by: Fu Siyuan <siyuan.fu@intel.com> Reviewed-by: Ni Ruiyu <ruiyu.ni@intel.com> Reviewed-by: Ye Ting <ting.ye@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@14607 6f19259b-4bc3-4df7-8a09-765794883524
2013-08-23OvmfPkg: Virtio: load used ring element strictly after loading used indexLaszlo Ersek
Enforce in-order execution of these steps even on not sequentially consistent architectures, as discussed in [1]. These changes should be unnecessary on x86 (the only architecture OVMF currently supports), but they align the OVMF virtio code with the virtio specification and could be necessary for future OVMF ports. [1] http://lists.linuxfoundation.org/pipermail/virtualization/2013-June/024547.html Suggested-by: Stefan Hajnoczi <stefanha@redhat.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@14601 6f19259b-4bc3-4df7-8a09-765794883524
2013-08-23OvmfPkg: Build and use the UEFI shell by defaultJordan Justen
Previously OVMF included the older EFI shell binary when building. Now we will build and use the UEFI shell (ShellPkg) instead. v2: * Don't bother building UEFI shell when USE_OLD_SHELL is defined * Fix errors in OvmfPkgIa32X64.fdf Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Jordan Justen <jordan.l.justen@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@14600 6f19259b-4bc3-4df7-8a09-765794883524
2013-08-19OvmfPkg: Use the new DevicePathLib for all platformsRuiyu Ni
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ruiyu Ni <Ruiyu.ni@Intel.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@14558 6f19259b-4bc3-4df7-8a09-765794883524
2013-08-19OvmfPkg ResetSystemLib: Fix VS build errorRuiyu Ni
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ruiyu Ni <Ruiyu.ni@Intel.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@14557 6f19259b-4bc3-4df7-8a09-765794883524
2013-08-18OvmfPkg/SecureBootConfigDxe: Avoid illegal accessGary Ching-Pang Lin
When enrolling the certificate from a file, the suffix check function check the last 4 characters to filter out non-DER files. However, if the length of the file name is less than 4, the address prior to the file name will be accessed while it shouldn't. This commit checks the length of the file name to avoid illegal access. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Gary Ching-Pang Lin <glin@suse.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> Reviewed-by: Guo Dong <guo.dong@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@14556 6f19259b-4bc3-4df7-8a09-765794883524
2013-08-18OvmfPkg: allocate the EFI memory map for Linux as Loader DataLaszlo Ersek
In Linux, efi_memblock_x86_reserve_range() and efi_reserve_boot_services() expect that whoever allocates the EFI memmap allocates it in Loader Data type memory. Linux's own exit_boot()-->low_alloc() complies, but SetupLinuxMemmap() in LoadLinuxLib doesn't. The memory type discrepancy leads to efi_memblock_x86_reserve_range() and efi_reserve_boot_services() both trying to reserve the range backing the memmap, resulting in memmap entry truncation in efi_reserve_boot_services(). This fix also makes this allocation consistent with all other persistent allocations in "OvmfPkg/Library/LoadLinuxLib/Linux.c". Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reported-and-tested-by: Borislav Petkov <bp@suse.de> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@14555 6f19259b-4bc3-4df7-8a09-765794883524
2013-08-12Update OVMF platform to use new display engine and browser.Eric Dong
Signed-off-by: Eric Dong <eric.dong@intel.com> Reviewed-by: Liming Gao <liming.gao@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Tested-by: Laszlo Ersek <lersek@redhat.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@14541 6f19259b-4bc3-4df7-8a09-765794883524
2013-08-12Rollback patch 14537 & 14538, because patch 14537 is not tested by Laszlo ↵Eric Dong
Ersek, but i wrote it. Signed-off-by: Eric Dong <eric.dong@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@14539 6f19259b-4bc3-4df7-8a09-765794883524
2013-08-09Update Browser to provide the customization possibilities.Eric Dong
Signed-off-by: Eric Dong <eric.dong@intel.com> Reviewed-by: Liming Gao <liming.gao@intel.com> MdeModulePkg Patch Tested-by: Laszlo Ersek <lersek@redhat.com> OvmfPkg Patch Tested-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@14537 6f19259b-4bc3-4df7-8a09-765794883524
2013-07-26Update all the code to consume the ConvertDevicePathToText, ↵Ruiyu Ni
ConvertDevicePathNodeToText, ConvertTextToDevicePath and ConvertTextToDeviceNode APIs in DevicePathLib. Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com> Reviewed-by: Feng Tian <feng.tian@intel.com> Reviewed-by: Elvin Li <elvin.li@intel.com> Reviewed-by: Eric Dong <eric.dong@intel.com> Reviewed-by: Star Zeng <star.zeng@intel.com> Reviewed-by: Jaben Carsey <jaben.carsey@intel.com> Reviewed-by: Guo Dong <guo.dong@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@14505 6f19259b-4bc3-4df7-8a09-765794883524
2013-07-18OvmfPkg/Sec: Build identity mapped pages in RAM for X64Jordan Justen
This is based on MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.c. Previously we would run using page tables built into the firmware device. If a flash memory is available, it is unsafe for the page tables to be stored in memory since the processor may try to write to the page table data structures. Additionally, when KVM ROM support is enabled for the firmware device, then PEI fails to boot when the page tables are in the firmware device. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Jordan Justen <jordan.l.justen@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@14494 6f19259b-4bc3-4df7-8a09-765794883524
2013-07-18OvmfPkg: Add IndustryStandard/X64Paging.hJordan Justen
Taken from MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.h. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Jordan Justen <jordan.l.justen@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@14493 6f19259b-4bc3-4df7-8a09-765794883524
2013-07-18OvmfPkg ResetSystemLib: Fix shutdown via UEFI runtime servicesJordan Justen
When the PM base address was moved from 0x400 to 0xb000, this code was missed. This prevented shutdown's via the UEFI system call from working. (For example, at the EFI shell prompt: reset -s) We now use gUefiOvmfPkgTokenSpaceGuid.PcdAcpiPmBaseAddress which is currently set at 0xb000. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Jordan Justen <jordan.l.justen@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@14492 6f19259b-4bc3-4df7-8a09-765794883524
2013-07-16Fix IA32 build failure.Ruiyu Ni
Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@14472 6f19259b-4bc3-4df7-8a09-765794883524
2013-07-03OvmfPkg EmuVariableFvbRuntimeDxe: Let FaultTolerantWriteDxe to init working ↵Star Zeng
block header. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Star Zeng <star.zeng@intel.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@14458 6f19259b-4bc3-4df7-8a09-765794883524
2013-06-14OvmfPkg: Reduce PcdMaxVariableSize with secure boot to avoid assertJordan Justen
r14252 causes OVMF to crash if SECURE_BOOT_ENABLE is set, because PcdMaxVariableSize is set to a larger value than required. In other platforms, 0x2000 seems to be sufficient. Reported-by: Gary Ching-Pang Lin <glin@suse.com> Signed-off-by: Jordan Justen <jordan.l.justen@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Tested-by: Laszlo Ersek <lersek@redhat.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@14423 6f19259b-4bc3-4df7-8a09-765794883524
2013-06-14OvmfPkg: enable building VirtioNetDxeLaszlo Ersek
Also summarize the resultant NIC driver options in the README file. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@14421 6f19259b-4bc3-4df7-8a09-765794883524
2013-06-14OvmfPkg/VirtioNetDxe: Fix build errors on VS2012 (IA32 & X64)Jordan Justen
These changes were needed in addition to the silence.patch that Laszlo posted on May 28. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Jordan Justen <jordan.l.justen@intel.com> Signed-off-by: Laszlo Ersek <lersek@redhat.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@14420 6f19259b-4bc3-4df7-8a09-765794883524
2013-06-14OvmfPkg: VirtioNetDxe: fix some build errors emitted by Visual StudioLaszlo Ersek
These were found with the gcc-4.4 option "-Wconversion" after Jordan reported the build failure under Visual Studio. The patch was originally posted to edk2-devel as "silence.patch": http://thread.gmane.org/gmane.comp.bios.tianocore.devel/2804/focus=2972 Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@14419 6f19259b-4bc3-4df7-8a09-765794883524
2013-06-14OvmfPkg: VirtioNetDxe: complete driver with INF fileLaszlo Ersek
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@14418 6f19259b-4bc3-4df7-8a09-765794883524
2013-06-14OvmfPkg: VirtioNetDxe: WaitForPacket and EXIT_BOOT_SERVICES event callbacksLaszlo Ersek
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@14417 6f19259b-4bc3-4df7-8a09-765794883524
2013-06-14OvmfPkg: VirtioNetDxe: definitions of unsupported SNP member functionsLaszlo Ersek
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@14416 6f19259b-4bc3-4df7-8a09-765794883524
2013-06-14OvmfPkg: VirtioNetDxe: emulate Rx filter configuration: SNP.ReceiveFiltersLaszlo Ersek
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@14415 6f19259b-4bc3-4df7-8a09-765794883524
2013-06-14OvmfPkg: VirtioNetDxe: map multicast IP to MAC: SNP.McastIpToMacLaszlo Ersek
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@14414 6f19259b-4bc3-4df7-8a09-765794883524
2013-06-14OvmfPkg: VirtioNetDxe: implement Tx: SNP.Transmit and SNP.GetStatusLaszlo Ersek
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@14413 6f19259b-4bc3-4df7-8a09-765794883524
2013-06-14OvmfPkg: VirtioNetDxe: SNP.ReceiveLaszlo Ersek
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@14412 6f19259b-4bc3-4df7-8a09-765794883524
2013-06-14OvmfPkg: VirtioNetDxe: SNP.ShutdownLaszlo Ersek
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@14411 6f19259b-4bc3-4df7-8a09-765794883524
2013-06-14OvmfPkg: VirtioNetDxe: add SNP.Initialize and shared dependenciesLaszlo Ersek
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@14410 6f19259b-4bc3-4df7-8a09-765794883524
2013-06-14OvmfPkg: VirtioNetDxe: Simple Network Protocol members Start and StopLaszlo Ersek
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@14409 6f19259b-4bc3-4df7-8a09-765794883524
2013-06-14OvmfPkg: VirtioNetDxe: driver bindingLaszlo Ersek
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@14408 6f19259b-4bc3-4df7-8a09-765794883524
2013-06-14OvmfPkg: VirtioNetDxe: Component Name Protocol implementationLaszlo Ersek
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@14407 6f19259b-4bc3-4df7-8a09-765794883524
2013-06-14OvmfPkg: VirtioNetDxe: add entry pointLaszlo Ersek
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@14406 6f19259b-4bc3-4df7-8a09-765794883524
2013-06-14OvmfPkg: VirtioNetDxe: declarations and macro definitionsLaszlo Ersek
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@14405 6f19259b-4bc3-4df7-8a09-765794883524
2013-06-14OvmfPkg: VirtioNetDxe: add technical notesLaszlo Ersek
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@14404 6f19259b-4bc3-4df7-8a09-765794883524
2013-05-28OvmfPkg/SerializeVariablesLib: ignore secure variable restore errorsjljusten
OvmfPkg's file-based NvVar storage is read back as follows at boot (all paths under OvmfPkg/Library/): PlatformBdsPolicyBehavior() [PlatformBdsLib/BdsPlatform.c] PlatformBdsRestoreNvVarsFromHardDisk() VisitAllInstancesOfProtocol for each simple file system: VisitingFileSystemInstance() ConnectNvVarsToFileSystem() [NvVarsFileLib/NvVarsFileLib.c] LoadNvVarsFromFs() [NvVarsFileLib/FsAccess.c] ReadNvVarsFile() +-------------> SerializeVariablesSetSerializedVariables() [SerializeVariablesLib/SerializeVariablesLib.c] | SerializeVariablesIterateInstanceVariables() | +-------------> IterateVariablesInBuffer() | | for each loaded / deserialized variable: | +-|-----------------> IterateVariablesCallbackSetSystemVariable() | | | gRT->SetVariable() | | | | | IterateVariablesInBuffer() stops processing variables as soon as the | | first error is encountered from the callback function. | | | | In this case the callback function is | IterateVariablesCallbackSetSystemVariable(), selected by SerializeVariablesSetSerializedVariables(). The result is that no NvVar is restored from the file after the first gRT->SetVariable() failure. On my system such a failure - never happens in an OVMF build with secure boot disabled, - happens *immediately* with SECURE_BOOT_ENABLE, because the first variable to restore is "AuthVarKeyDatabase". "AuthVarKeyDatabase" has the EFI_VARIABLE_AUTHENTICATED_WRITE_ACCESS attribute set. Since the loop tries to restore it before any keys (PK, KEK etc) are enrolled, gRT->SetVariable() rejects it with EFI_SECURITY_VIOLATION. Consequently the NvVar restore loop terminates immediately, and we never reach non-authenticated variables such as Boot#### and BootOrder. Until work on KVM-compatible flash emulation converges between qemu and OvmfPkg, improve the SECURE_BOOT_ENABLE boot experience by masking EFI_SECURITY_VIOLATION in the callback: - authenticated variables continue to be rejected same as before, but - at least we allow the loop to progress and restore non-authenticated variables, for example boot options. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@14390 6f19259b-4bc3-4df7-8a09-765794883524
2013-05-15OvmfPkg: QemuBootOrder: recognize Ethernet OFW device pathsjljusten
Tested with the e1000, ne2k_pci, pcnet, rtl8139, and virtio iPXE UEFI oprom drivers distributed with qemu-1.5.0-rc1. Also tested with Intel's e1000 driver. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@14367 6f19259b-4bc3-4df7-8a09-765794883524
2013-05-15OvmfPkg: enable the generic network stack by defaultjljusten
DHCP, PXE, and StdLib socket apps are enabled in OVMF by the sum of: (a) a UEFI NIC driver, (b) the generic network stack. The only choice for (a) used to be the proprietary Intel E1000 driver, which is cumbersome to obtain and enable. The iPXE UEFI NIC drivers packaged with qemu-1.5 cover (a) for each NIC type supported by qemu, and are easy to obtain & configure, even for earlier qemu versions. Therefore enable (b) per default as well. This doesn't take up much space; the binaries (b) adds to the firmware don't seem to need -D FD_SIZE_2MB. Intel's e1000 driver remains an option, requested by the -D E1000_ENABLE build flag. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@14366 6f19259b-4bc3-4df7-8a09-765794883524
2013-05-15OvmfPkg: describe debug messages in the README filejljusten
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@14364 6f19259b-4bc3-4df7-8a09-765794883524
2013-05-15OvmfPkg: adapt VirtioFlush()'s leading comment to the coding stylejljusten
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@14362 6f19259b-4bc3-4df7-8a09-765794883524
2013-05-15OvmfPkg: adapt VirtioAppendDesc()'s leading comment to the coding stylejljusten
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@14361 6f19259b-4bc3-4df7-8a09-765794883524
2013-05-15OvmfPkg: adapt VirtioPrepare()'s leading comment to the coding stylejljusten
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@14360 6f19259b-4bc3-4df7-8a09-765794883524
2013-05-14OvmfPkg: VirtioLib: populate the Available Ring correctlyjljusten
The descriptor table (also known as "queue") consists of descriptors. (The corresponding type in the code is VRING_DESC.) An individual descriptor describes a contiguous buffer, to be transferred uni-directionally between host and guest. Several descriptors in the descriptor table can be linked into a descriptor chain, specifying a bi-directional scatter-gather transfer between host and guest. Such a descriptor chain is also known as "virtio request". (The descriptor table can host sereval descriptor chains (in-flight virtio requests) in parallel, but the OVMF driver supports at most one chain, at any point in time.) The first descriptor in any descriptor chain is called "head descriptor". In order to submit a number of parallel requests (= a set of independent descriptor chains) from the guest to the host, the guest must put *only* the head descriptor of each separate chain onto the Available Ring. VirtioLib currently places the head of its one descriptor chain onto the Available Ring repeatedly, once for each single (head *or* dependent) descriptor in said descriptor chain. If the descriptor chain comprises N descriptors, this error amounts to submitting the same entire chain N times in parallel. Available Ring Descriptor table Ptr to head ----> Desc#0 (head of chain) Ptr to head --/ Desc#1 (next in same chain) ... / ... Ptr to head / Desc#(N-1) (last in same chain) Anatomy of a single virtio-blk READ request (a descriptor chain with three descriptors): virtio-blk request header, prepared by guest: VirtioAppendDesc PhysAddr=3FBC6050 Size=16 Flags=1 Head=1232 Next=1232 payload to be filled in by host: VirtioAppendDesc PhysAddr=3B934C00 Size=32768 Flags=3 Head=1232 Next=1233 host status, to be filled in by host: VirtioAppendDesc PhysAddr=3FBC604F Size=1 Flags=2 Head=1232 Next=1234 Processing on the host side -- the descriptor chain is processed three times in parallel (its head is available to virtqueue_pop() thrice); the same chain is submitted/collected separately to/from AIO three times: virtio_queue_notify vdev VDEV vq VQ#0 virtqueue_pop vq VQ#0 elem EL#0 in_num 2 out_num 1 bdrv_aio_readv bs BDRV sector_num 585792 nb_sectors 64 opaque REQ#0 virtqueue_pop vq VQ#0 elem EL#1 in_num 2 out_num 1 bdrv_aio_readv bs BDRV sector_num 585792 nb_sectors 64 opaque REQ#1 virtqueue_pop vq VQ#0 elem EL#2 in_num 2 out_num 1 bdrv_aio_readv bs BDRV sector_num 585792 nb_sectors 64 opaque REQ#2 virtio_blk_rw_complete req REQ#0 ret 0 virtio_blk_req_complete req REQ#0 status 0 virtio_blk_rw_complete req REQ#1 ret 0 virtio_blk_req_complete req REQ#1 status 0 virtio_blk_rw_complete req REQ#2 ret 0 virtio_blk_req_complete req REQ#2 status 0 On my Thinkpad T510 laptop with RHEL-6 as host, this probably leads to simultaneous DMA transfers targeting the same RAM area. Even though the source of each transfer is identical, the data is corrupted in the destination buffer -- the CRC32 calculated over the buffer varies, even though the origin of the transfers is the same, never rewritten LBA. SynchronousRequest Lba=585792 BufSiz=32768 ReqIsWrite=0 Crc32=BF68A44D The problem is invisible on my HP Z400 workstation. Fix the request submission by: - building the only one descriptor chain supported by VirtioLib always at the beginning of the descriptor table, - ensuring the head descriptor of this chain is put on the Available Ring only once, - requesting the virtio spec's language to be cleaned up <http://lists.linuxfoundation.org/pipermail/virtualization/2013-April/024032.html>. Available Ring Descriptor table Ptr to head ----> Desc#0 (head of chain) Desc#1 (next in same chain) ... Desc#(N-1) (last in same chain) VirtioAppendDesc PhysAddr=3FBC6040 Size=16 Flags=1 Head=0 Next=0 VirtioAppendDesc PhysAddr=3B934C00 Size=32768 Flags=3 Head=0 Next=1 VirtioAppendDesc PhysAddr=3FBC603F Size=1 Flags=2 Head=0 Next=2 virtio_queue_notify vdev VDEV vq VQ#0 virtqueue_pop vq VQ#0 elem EL#0 in_num 2 out_num 1 bdrv_aio_readv bs BDRV sector_num 585792 nb_sectors 64 opaque REQ#0 virtio_blk_rw_complete req REQ#0 ret 0 virtio_blk_req_complete req REQ#0 status 0 SynchronousRequest Lba=585792 BufSiz=32768 ReqIsWrite=0 Crc32=1EEB2B07 (The Crc32 was double-checked with edk2's and Linux's guest IDE driver.) Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@14356 6f19259b-4bc3-4df7-8a09-765794883524
2013-04-03OvmfPkg: remove OvmfVideo.rom referencesjljusten
The README is rather extended than trimmed, so that users grepping for the file name have a pointer. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@14243 6f19259b-4bc3-4df7-8a09-765794883524
2013-03-04OvmfPkg: make sure ResetCold() and ResetWarm() never returnjljusten
Also, add a small delay after the 0xCF9 hard reset request -- on qemu/kvm the port access is translated to the qemu-internal system reset request by the CPU thread, and it might progress some more before the IO thread acts upon the system reset request. MicroSecondDelay() is implemented by OvmfPkg's own AcpiTimerLib. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@14158 6f19259b-4bc3-4df7-8a09-765794883524
2013-03-04OvmfPkg: attempt to trigger cold reset through PIIX3 reset control registerjljusten
The reset requested via the keyboard controller (port 0x64) is actually a soft reset, but qemu has supported it since forever (plus qemu has not distinguished between hard reset and soft reset, although this is changing now). Therefore leave the current IoWrite() in place for compatibility. On qemu versions with commit 1ec4ba74 ("PIIX3: reset the VM when the Reset Control Register's RCPU bit gets set"), use the PIIX3 RCR as first choice. In the future qemu will act differently on soft vs. hard reset requests, and we should honor that in ResetCold(). Writing to ioport 0xCF9 on qemu builds prior to commit 1ec4ba74 should have no effect. Access to the PCI host config register went through several implementations in qemu. Commit 9f6f0423 ("pci_host: rewrite using rwhandler") seems safe, both before and after. Commit d0ed8076 ("pci_host: convert conf index and data ports to memory API") inadvertently dropped the alignment/size check, causing a boot regression on NetBSD. It was fixed about six months later in commit cdde6ffc, which is current. Translating that to qemu releases, the bug was visible from v1.0 to v1.1.0. On physical hardware cycling between reset methods is sometimes necessary <http://mjg59.dreamwidth.org/3561.html>. On qemu the port access should trap immediately. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@14157 6f19259b-4bc3-4df7-8a09-765794883524
2013-03-04OvmfPkg: report support for the PIIX3 reset register in the FADTjljusten
The value to be written corresponds to hard reset, which is what the ACPI spec prescribes. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@14156 6f19259b-4bc3-4df7-8a09-765794883524
2013-03-04OvmfPkg: upgrade the FADT to ACPI 2.0 without functional changesjljusten
This conversion cannot be split very well into smaller patches. Comparing version 1 and version 2 (modulo the header fields): > --- EFI_ACPI_1_0_FIXED_ACPI_DESCRIPTION_TABLE > +++ EFI_ACPI_2_0_FIXED_ACPI_DESCRIPTION_TABLE > @@ -1,14 +1,14 @@ > EFI_ACPI_DESCRIPTION_HEADER Header; > UINT32 FirmwareCtrl; > UINT32 Dsdt; > - UINT8 IntModel; > - UINT8 Reserved1; > + UINT8 Reserved0; > + UINT8 PreferredPmProfile; The INT_MODEL field was present in ACPI 1.0, but eliminated in 2.0. According to the spec, "platforms should set this field to zero but field values of one are also allowed to maintain compatibility with ACPI 1.0". We're setting it to zero. About Preferred_PM_Profile (taking the place of an 1.0 reserved field), the specification says: This field is set by the OEM to convey the preferred power management profile to OSPM. OSPM can use this field to set default power management policy parameters during OS installation. >From <MdePkg/Include/IndustryStandard/Acpi20.h>: #define EFI_ACPI_2_0_PM_PROFILE_UNSPECIFIED 0 #define EFI_ACPI_2_0_PM_PROFILE_DESKTOP 1 #define EFI_ACPI_2_0_PM_PROFILE_MOBILE 2 #define EFI_ACPI_2_0_PM_PROFILE_WORKSTATION 3 #define EFI_ACPI_2_0_PM_PROFILE_ENTERPRISE_SERVER 4 #define EFI_ACPI_2_0_PM_PROFILE_SOHO_SERVER 5 #define EFI_ACPI_2_0_PM_PROFILE_APPLIANCE_PC 6 For a virtual machine, "unspecified" is the best choice. > UINT16 SciInt; > UINT32 SmiCmd; > UINT8 AcpiEnable; > UINT8 AcpiDisable; > UINT8 S4BiosReq; > - UINT8 Reserved2; > + UINT8 PstateCnt; We've been already treating this field as PSTATE_CNT. No change in value. > UINT32 Pm1aEvtBlk; > UINT32 Pm1bEvtBlk; > UINT32 Pm1aCntBlk; > @@ -20,11 +20,11 @@ > UINT8 Pm1EvtLen; > UINT8 Pm1CntLen; > UINT8 Pm2CntLen; > - UINT8 PmTmLen; > + UINT8 PmTmrLen; (Field renaming artifact.) > UINT8 Gpe0BlkLen; > UINT8 Gpe1BlkLen; > UINT8 Gpe1Base; > - UINT8 Reserved3; > + UINT8 CstCnt; We've been already treating this field as CST_CNT. No change in value. > UINT16 PLvl2Lat; > UINT16 PLvl3Lat; > UINT16 FlushSize; > @@ -34,7 +34,19 @@ > UINT8 DayAlrm; > UINT8 MonAlrm; > UINT8 Century; > - UINT8 Reserved4; > - UINT8 Reserved5; > - UINT8 Reserved6; > + UINT16 IaPcBootArch; > + UINT8 Reserved1; The first two octets are now merged into a 16-bit short; otherwise we've been treating those as boot architecture flags already (see SVN rev 13615). No change in value. > UINT32 Flags; The fixed feature flags are not modified, only the macro names (expanding to identical values) are updated to ACPI 2.0. The following fields are all new in ACPI 2.0: > + EFI_ACPI_2_0_GENERIC_ADDRESS_STRUCTURE ResetReg; > + UINT8 ResetValue; We don't claim support for the reset register yet. > + UINT8 Reserved2[3]; > + UINT64 XFirmwareCtrl; > + UINT64 XDsdt; The 64-bit physical addresses for the FACS and the DSDT are automatically filled at installation time, see AddTableToList() and DeleteTable() in "MdeModulePkg/Universal/Acpi/AcpiTableDxe/AcpiTableProtocol.c". > + EFI_ACPI_2_0_GENERIC_ADDRESS_STRUCTURE XPm1aEvtBlk; > + EFI_ACPI_2_0_GENERIC_ADDRESS_STRUCTURE XPm1bEvtBlk; > + EFI_ACPI_2_0_GENERIC_ADDRESS_STRUCTURE XPm1aCntBlk; > + EFI_ACPI_2_0_GENERIC_ADDRESS_STRUCTURE XPm1bCntBlk; > + EFI_ACPI_2_0_GENERIC_ADDRESS_STRUCTURE XPm2CntBlk; > + EFI_ACPI_2_0_GENERIC_ADDRESS_STRUCTURE XPmTmrBlk; > + EFI_ACPI_2_0_GENERIC_ADDRESS_STRUCTURE XGpe0Blk; > + EFI_ACPI_2_0_GENERIC_ADDRESS_STRUCTURE XGpe1Blk; We specify the extended addresses for the required and supported PM1a Event & Control, PM Timer, and GPE0 Register Blocks, and zero the rest, in accordance with the ACPI 1.0 fields. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@14155 6f19259b-4bc3-4df7-8a09-765794883524
2013-03-04OvmfPkg: fold macros of unsupported GPE1 register block into Facp.aslcjljusten
In the next patch we're going to specify Extended Addresses of register blocks in Generic Address Structure format. The GAS is easy to fill if we want to posit either "unsupported" (all zero) or a given address in a specific address space. However deriving "unsupported" just from a macro expanding to zero is unwieldy, so let's avoid the need. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@14154 6f19259b-4bc3-4df7-8a09-765794883524
generated by cgit v1.2.3 (git 2.25.1) at 2024-11-01 14:28:18 +0000