summaryrefslogtreecommitdiff
path: root/OvmfPkg
AgeCommit message (Collapse)Author
2013-12-12OvmfPkg: Virtio drivers: fix incorrect casts in init functionsLaszlo Ersek
The recent patch OvmfPkg: Make the VirtIo devices use the new VIRTIO_DEVICE_PROTOCOL was fixed up at commit time, in order to silence warnings issued by the Visual Studio compiler. Differences between the posted and committed patch: > diff --git a/OvmfPkg/VirtioBlkDxe/VirtioBlk.c b/OvmfPkg/VirtioBlkDxe/VirtioBlk.c > -index 17b9f71..96a0d9f 100644 > +index 17b9f71..f09b0d1 100644 > --- a/OvmfPkg/VirtioBlkDxe/VirtioBlk.c > +++ b/OvmfPkg/VirtioBlkDxe/VirtioBlk.c > @@ -23,7 +23,6 @@ > @@ -994,7 +998,7 @@ > + // step 4c -- Report GPFN (guest-physical frame number) of queue. > + // > + Status = Dev->VirtIo->SetQueueAddress (Dev->VirtIo, > -+ (UINTN) Dev->Ring.Base >> EFI_PAGE_SHIFT); > ++ (UINT32)(UINTN) Dev->Ring.Base >> EFI_PAGE_SHIFT); > + if (EFI_ERROR (Status)) { > + goto ReleaseQueue; > + } > @@ -1495,7 +1499,7 @@ > goto Exit; > } > diff --git a/OvmfPkg/VirtioNetDxe/SnpInitialize.c b/OvmfPkg/VirtioNetDxe/SnpInitialize.c > -index 6cee014..8dcf9da 100644 > +index 6cee014..4203fbd 100644 > --- a/OvmfPkg/VirtioNetDxe/SnpInitialize.c > +++ b/OvmfPkg/VirtioNetDxe/SnpInitialize.c > @@ -57,14 +57,15 @@ VirtioNetInitRing ( > @@ -1539,7 +1543,7 @@ > - Status = VIRTIO_CFG_WRITE (Dev, Generic.VhdrQueueAddress, > - (UINTN) Ring->Base >> EFI_PAGE_SHIFT); > + Status = Dev->VirtIo->SetQueueAddress (Dev->VirtIo, > -+ (UINTN) Ring->Base >> EFI_PAGE_SHIFT); > ++ (UINT32)(UINTN) Ring->Base >> EFI_PAGE_SHIFT); > if (EFI_ERROR (Status)) { > - VirtioRingUninit (Ring); > + goto ReleaseQueue; > @@ -1721,7 +1725,7 @@ > Exit: > gBS->RestoreTPL (OldTpl); > diff --git a/OvmfPkg/VirtioScsiDxe/VirtioScsi.c b/OvmfPkg/VirtioScsiDxe/VirtioScsi.c > -index b836fb3..bcec676 100644 > +index b836fb3..2223c9c 100644 > --- a/OvmfPkg/VirtioScsiDxe/VirtioScsi.c > +++ b/OvmfPkg/VirtioScsiDxe/VirtioScsi.c > @@ -38,7 +38,6 @@ > @@ -1908,7 +1912,7 @@ > + // step 4c -- Report GPFN (guest-physical frame number) of queue. > + // > + Status = Dev->VirtIo->SetQueueAddress (Dev->VirtIo, > -+ (UINTN) Dev->Ring.Base >> EFI_PAGE_SHIFT); > ++ (UINT32)(UINTN) Dev->Ring.Base >> EFI_PAGE_SHIFT); > if (EFI_ERROR (Status)) { > goto ReleaseQueue; > } These casts are incorrect -- they throw away address bits >=32 before shifting, which can break the drivers in guests with more than 4GB RAM. The bug is clearly an artifact of the edk2 coding style, which requires cast expressions to be written as (type) expression rather than the usual (type)expression The latter correctly reflects that casts have one of the strongest bindings in C. The former actively obscures that fact. Cf. (type) expr1 >> expr2 vs. (type)expr1 >> expr2 Make sure we shift before we truncate. 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://svn.code.sf.net/p/edk2/code/trunk/edk2@14970 6f19259b-4bc3-4df7-8a09-765794883524
2013-12-11OvmfPkg/Virtio: Removed VirtioReadDevice() / VirtIoWriteDevice() functionsOlivier Martin
These functions did not provide much more than the new protocol functions VIRTIO_DEVICE_PROTOCOL.ReadDevice() / VIRTIO_DEVICE_PROTOCOL.WriteDevice(). Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Olivier Martin <olivier.martin@arm.com> Reviewed-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@14968 6f19259b-4bc3-4df7-8a09-765794883524
2013-12-11OvmfPkg/Virtio.h: Removed definition of VIRTIO_HDROlivier Martin
This definition is specific to VirtIo over PCI. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Olivier Martin <olivier.martin@arm.com> Reviewed-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@14967 6f19259b-4bc3-4df7-8a09-765794883524
2013-12-11OvmfPkg: Make the VirtIo devices use the new VIRTIO_DEVICE_PROTOCOLOlivier Martin
This change replaces the accesses to the PCI bus from the Block, Scsi and Net drivers by the use of the new VIRTIO_DEVICE_PROTOCOL protocol that abstracts the transport layer. It means these drivers can be used on PCI and MMIO transport layer. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Olivier Martin <olivier.martin@arm.com> v5: - VirtioFlush(): update comment block in VirtioLib.[hc]; error code is propagated from VirtIo->SetQueueNotify(). - VirtioBlkInit(): jump to Failed label if SetPageSize() fails - VirtioBlkInit(): fixup comment, and add error handling, near SetQueueNum() call - VirtioBlkDriverBindingStart(): remove redundant (always false) check for a subsystem device ID different from VIRTIO_SUBSYSTEM_BLOCK_DEVICE; VirtioBlkDriverBindingSupported() handles it already - VirtioNetGetFeatures(): update stale comment block - VirtioNetGetFeatures(): retrieve MAC address byte for byte (open-coded loop) - VirtioNetDriverBindingStart(): remove redundant (always false) check for a subsystem device ID different from VIRTIO_SUBSYSTEM_NETWORK_CARD; VirtioNetDriverBindingSupported() handles it already - VirtioNetInitRing(): call SetQueueNum() and SetQueueAlign() for proper MMIO operation - VirtioNetInitialize(): fix destination error label for when SetPageSize() fails - VirtioScsi.c: fix comment block of VIRTIO_CFG_WRITE()/VIRTIO_CFG_READ() - VirtioScsiInit(): fix destination error label for when SetPageSize() fails - VirtioScsiInit(): call SetQueueNum() and SetQueueAlign() for proper MMIO operation 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://svn.code.sf.net/p/edk2/code/trunk/edk2@14966 6f19259b-4bc3-4df7-8a09-765794883524
2013-12-11OvmfPkg/VirtioMmioDeviceLib: Implement VIRTIO_DEVICE_PROTOCOL for VirtIo ↵Olivier Martin
Devices over MMIO Why is the virtio-mmio implementation of the protocol a library, instead of a driver binary? The UEFI driver model would encourage to create a virtio-mmio driver instead of a library. But the reasons why I created a library are: - A virtio-mmio driver would imply an additional protocol that would probably have a single attribute field: typedef struct { PHYSICAL_ADDRESS BaseAddress; } VIRTIO_MMIO_DEVICE_PROTOCOL; - There is no (easy) way to scan the available VirtIo devices on a platform. So, the UEFI firmware for this platform would need a driver to produce instances for every virtio devices it wants to expose in UEFI. A single call to a helper library (ie: VirtioMmioDeviceLib) make the porting easier. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Olivier Martin <olivier.martin@arm.com> v5: - typo fix in VirtioMmioInstallDevice() comment block - plug MmioDevice leak in VirtioMmioUninstallDevice() - return EFI_INVALID_PARAMETER in VirtioMmioGetQueueAddress() if QueueAddress is NULL - VirtioMmioSetQueueSize(): fix return value (it's a status code) - VirtioMmioSetPageSize(): check against EFI_PAGE_SIZE with "if" plus EFI_UNSUPPORTED, rather than ASSERT() - VirtioMmioDeviceWrite(), VirtioMmioDeviceRead(): remove redundant (FieldSize > 8) checks - VirtioMmioDeviceLib.inf: drop UefiDriverEntryPoint library dependency 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://svn.code.sf.net/p/edk2/code/trunk/edk2@14965 6f19259b-4bc3-4df7-8a09-765794883524
2013-12-11OvmfPkg/VirtioPciDeviceDxe: Implement VIRTIO_DEVICE_PROTOCOL for VirtIo ↵Olivier Martin
Devices over PCI This change implements the VIRTIO_DEVICE_PROTOCOL for the PCI transport layer. The VirtIo device drivers will interact with the PCI-based VirtIo devices through this protocol implementation. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Olivier Martin <olivier.martin@arm.com> v5: - updated comment block on VirtioPciDeviceRead() - return EFI_UNSUPPORTED instead of failed ASSERT() in VirtioPciSetPageSize() - VirtioPciIoRead(): restore the original requirement that FieldSize equal BufferSize exactly (not only divide it). The looping added in v4 did not match the comment block, and the only place that used it in v4 (ie. VirtioNetGetFeatures()) needs an open-coded loop anyway (will be done in a later part of v5). 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://svn.code.sf.net/p/edk2/code/trunk/edk2@14964 6f19259b-4bc3-4df7-8a09-765794883524
2013-12-11OvmfPkg/VirtioDevice.h: Introduced VIRTIO_DEVICE_PROTOCOL protocolOlivier Martin
This protocol introduces an abstraction to access the VirtIo Configuration and Device spaces. The registers in these spaces are located at a different offset and have a different width whether the transport layer is either PCI or MMIO. This protocol would also allow to support VirtIo PCI devices with MSI-X capability in a transparent way (Device space is at a different offset when a PCIe device has MSI-X capability). Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Olivier Martin <olivier.martin@arm.com> v5: - add disclaimer (two instances) about the protocol being work in progress 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://svn.code.sf.net/p/edk2/code/trunk/edk2@14963 6f19259b-4bc3-4df7-8a09-765794883524
2013-12-08OvmfPkg: enable Xen specific pathWei Liu
This patch sets PcdPciDisableBusEnumeration to true then makes use of PublishPeiMemory and XenMemMapInitialization to construct memory map for Xen guest. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Wei Liu <wei.liu2@citrix.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@14946 6f19259b-4bc3-4df7-8a09-765794883524
2013-12-08OvmfPkg: introduce XenMemMapInitializationWei Liu
This function parses E820 map provided by Xen and arrange memory maps accordingly. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Wei Liu <wei.liu2@citrix.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> [jordan.l.justen@intel.com: XenGetE820Map: VS2010 compat; add assert] Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@14945 6f19259b-4bc3-4df7-8a09-765794883524
2013-12-08OvmfPkg: introduce PublishPeiMemoryWei Liu
MemDetect actully does too many things, the underlying platform might want to have more control over memory layout. Extract the functionality of publishing PEI memory to a dedicated function. Also fixed wrong comment while I was there. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Wei Liu <wei.liu2@citrix.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@14944 6f19259b-4bc3-4df7-8a09-765794883524
2013-12-08OvmfPkg: detect Xen earlierWei Liu
This is useful for initializing memory map. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Wei Liu <wei.liu2@citrix.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@14943 6f19259b-4bc3-4df7-8a09-765794883524
2013-12-08OvmfPkg: define EFI_XEN_OVMF_INFOWei Liu
EFI_XEN_OVMF_INFO is defined to accept configurations from hvmloader. It must match the definition on Xen side. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Wei Liu <wei.liu2@citrix.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@14942 6f19259b-4bc3-4df7-8a09-765794883524
2013-12-08OvmfPkg: introduce E820.hWei Liu
E820 definitions copied from IntelFrameworkModulePkg/Csm/ LegacyBiosDxe/LegacyBiosInterface.h. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Wei Liu <wei.liu2@citrix.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@14941 6f19259b-4bc3-4df7-8a09-765794883524
2013-11-22Updated OvmfPkg to use suitable CPU Exception Handler Library instances.Jeff Fan
Signed-off-by: Jeff Fan <jeff.fan@intel.com> Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@14887 6f19259b-4bc3-4df7-8a09-765794883524
2013-11-20OvmfPkg/QemuVideoDxe: don't leak descriptors returned by GetBarAttributesLaszlo 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> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@14877 6f19259b-4bc3-4df7-8a09-765794883524
2013-11-12OvmfPkg/BdsPlatform: don't restore NvVars from disk when flash is presentLaszlo Ersek
QemuFlashFvbServicesRuntimeDxe provides actual persistent storage for non-volatile variables. When it is active, any on-disk NvVars file counts as a stale source of variables -- hence don't load these files in BDS. This also allows Secure Boot settings (eg. enrolled keys) to survive cold VM reboots. 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://svn.code.sf.net/p/edk2/code/trunk/edk2@14844 6f19259b-4bc3-4df7-8a09-765794883524
2013-11-12OvmfPkg: indicate enablement of flash variables with a dedicated PCDLaszlo Ersek
PcdFlashNvStorageVariableBase64 is used to arbitrate between QemuFlashFvbServicesRuntimeDxe and EmuVariableFvbRuntimeDxe, but even the latter driver sets it if we fall back to it. Allow code running later than the startup of these drivers to know about the availability of flash variables, through a dedicated PCD. 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://svn.code.sf.net/p/edk2/code/trunk/edk2@14843 6f19259b-4bc3-4df7-8a09-765794883524
2013-11-12OvmfPkg/build.sh: Enable flash for QEMU >= 1.6Jordan Justen
If the QEMU version is found to be >= 1.6, then automatically enable flash (using the QEMU pflash command line parameter). QEMU supports flash since 1.2, but only if KVM is disabled. As of QEMU 1.6, flash support should also be enabled when KVM is used. Therefore it is safest to only enable flash for QEMU 1.6 and newer. 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@14842 6f19259b-4bc3-4df7-8a09-765794883524
2013-11-12OvmfPkg/build.sh: Support --enable-flash switchJordan Justen
If this argument is used, then when QEMU is run, the -pflash parameter will be used with QEMU to enable QEMU's flash mode. It should be used before the 'qemu' argument, since it is not a QEMU parameter, but instead it updates how build.sh runs QEMU. 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@14841 6f19259b-4bc3-4df7-8a09-765794883524
2013-11-12OvmfPkg: Add QemuFlashFvbServicesRuntimeDxe to firmware imageJordan Justen
This driver will support a flash FVB implementation if QEMU flash is detected. The driver is added to the apriori list to make sure it runs before the EmuVariableFvbRuntimeDxe driver. If this driver detects flash support, then it will disable the EmuVariableFvbRuntimeDxe driver by setting PcdFlashNvStorageVariableBase64. 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@14840 6f19259b-4bc3-4df7-8a09-765794883524
2013-11-12OvmfPkg: Add QemuFlashFvbServicesRuntimeDxe driverJordan Justen
If QEMU flash is detected, this module will install FirmwareVolumeBlock support for the QEMU flash device. It will also set PCDs with the results that: 1. OvmfPkg/EmuVariableFvbRuntimeDxe will be disabled 2. MdeModulePkg variable services will read/write flash directly Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Jordan Justen <jordan.l.justen@intel.com> Acked-by: Laszlo Ersek <lersek@redhat.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@14839 6f19259b-4bc3-4df7-8a09-765794883524
2013-11-12OvmfPkg/EmuVariableFvbRuntimeDxe: Disable if flash variables are supportedJordan Justen
If QEMU flash is supported, then the PcdFlashNvStorageVariableBase64 will be set by the flash FVB driver. If it is set to a non-zero value, then we disable memory based variables. In future patches we will add the flash FVB driver and force it to run before this driver. Therefore, if QEMU flash writing is supported, then this driver will be disabled. 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@14838 6f19259b-4bc3-4df7-8a09-765794883524
2013-11-12OvmfPkg/AcpiPlatformDxe/Qemu: Decrease upper limit for PCI window 32Jordan Justen
In a later patch we will want to mark the flash memory as a runtime services data memory range. This will allow a new runtime services firmware block driver to read & write flash memory when the OS has set up virtual memory protection. Since this memory range will appear as runtime services data, we need to adjust the limit when scanning for PCI window 32 down to just below the flash device. If we don't adjust the limit, then the algorithm in PopulateFwData will fail because it will see a EfiGcdMemoryTypeSystemMemory memory range just below 4GB. v2: * This patch replaces the v1 patch: "OvmfPkg/AcpiPlatformDxe/Qemu: Allow high runtime memory regions" 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@14837 6f19259b-4bc3-4df7-8a09-765794883524
2013-11-12OvmfPkg/README: Add information about OVMF flash layoutJordan Justen
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@14836 6f19259b-4bc3-4df7-8a09-765794883524
2013-11-12OvmfPkg: Add NV Variable storage within FDJordan Justen
This is to prepare for QEMU flash support which will allow non-volatile variables to be saved in the flash image. Note two size changes: * NV Varstore size increased from 0xc000 to 0xe000 * FTW work size decreased from 0x2000 to 0x1000 The reason for this change is that the fault-tolerant write support requires that the work area fit within the block just before the fault-tolerant write spare storage blocks. Since QEMU flash blocks have a size of 0x1000, this means that the maximum FTW work size is 0x1000. v2: * Update commit message and PcdVariableStoreSize 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@14835 6f19259b-4bc3-4df7-8a09-765794883524
2013-11-12OvmfPkg: Add flash PCD itemsJordan Justen
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@14834 6f19259b-4bc3-4df7-8a09-765794883524
2013-11-12OvmfPkg: Increase DEBUG build size to 2MB by defaultJordan Justen
The 1MB image with full debug and the shell included is too large to implement flash based non-volatile variable. After this change, building with -D FD_SIZE_1MB will force the smaller flash size. The default size for RELEASE build remains at 1MB, so using -b RELEASE on the build command line will result in a 1MB flash size. For RELEASE builds -D FD_SIZE_2MB can be used to produce a 2MB flash image. 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@14833 6f19259b-4bc3-4df7-8a09-765794883524
2013-11-06OvmfPkg/build.sh: Use QEMU_COMMAND environment variableJordan Justen
If the user has set the QEMU_COMMAND environment variable, then use it when running QEMU. This can be useful for running OVMF with development builds of QEMU. 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@14825 6f19259b-4bc3-4df7-8a09-765794883524
2013-10-29OvmfPkg/Virtio.h: Added the Virtio Vendor and MMIO IDsOlivier Martin
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Olivier Martin <olivier.martin@arm.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@14809 6f19259b-4bc3-4df7-8a09-765794883524
2013-10-29OvmfPkg/Virtio.h: Added PCI/MMIO Virtio Headers OffsetsOlivier Martin
Offsets are different between the PCI and MMIO transport layer. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Olivier Martin <olivier.martin@arm.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@14808 6f19259b-4bc3-4df7-8a09-765794883524
2013-10-29OvmfPkg/Virtio.h: Added the macros that define the Device Specific ↵Olivier Martin
Configuration Offset The Device Specific Configuration region is located at different locations for the VirtIo devices over PCI, PCI with MSI-X capability, MMIO. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Olivier Martin <olivier.martin@arm.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@14807 6f19259b-4bc3-4df7-8a09-765794883524
2013-10-29OvmfPkg/PlatformPei: emulated NV storage must be EfiRuntimeServicesDataLaszlo Ersek
SVN r14770 ("OvmfPkg/PlatformPei: correctly align emulated NV storage") made sure the emulated NV storage was allocated with correct alignment. However, the AllocateRuntimePool() -> AllocateAlignedPages() change flipped the memory type from EfiRuntimeServicesData to EfiBootServicesData. This causes variable services to access freed storage at runtime. It crashes Windows 2008 R2 early at boot, for example. Keep the alignment, but restore the memory type to EfiRuntimeServicesData, by calling AllocateAlignedRuntimePages(). These helper functions are implemeted and documented in "MdePkg/Library/PeiMemoryAllocationLib/MemoryAllocationLib.c". 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://svn.code.sf.net/p/edk2/code/trunk/edk2@14806 6f19259b-4bc3-4df7-8a09-765794883524
2013-10-14OvmfPkg/PlatformPei: correctly align emulated NV storageWei Liu
Per 2c4b18e ("MdeModulePkg: Add the alignment check for FTW spare area address and length, and add the check for PcdFlashNvStorageVariableSize <= PcdFlashNvStorageFtwSpareSize."), FTWDxe refuses to initialize if spare space base address or size is not aligned to block size. Depending on configuration, memory for FTWDxe might be dynamically allocated in PlatformPei. This patch makes sure that the allocated memory region is aligned. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Wei Liu <wei.liu2@citrix.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@14770 6f19259b-4bc3-4df7-8a09-765794883524
2013-09-30OvmfPkg: Removed magic values for the Virtio Sub-System ID in the PCI device ↵Olivier Martin
drivers Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Olivier Martin <olivier.martin@arm.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@14742 6f19259b-4bc3-4df7-8a09-765794883524
2013-09-30OvmfPkg/Virtio.h: Added VirtIo Subsystem IDsOlivier Martin
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Olivier Martin <olivier.martin@arm.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@14741 6f19259b-4bc3-4df7-8a09-765794883524
2013-09-30OvmfPkg/IndustryStandard: Fixed 'VirtioNet.h' line endingsOlivier Martin
EDK2 files must use CRLF line ending. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Olivier Martin <olivier.martin@arm.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@14740 6f19259b-4bc3-4df7-8a09-765794883524
2013-09-24OvmfPkg: EFI handover flags are in Bp->hdr.xloadflagsMatt Fleming
LoadLinux() is looking at the wrong field for the kernel's EFI handover protocol flags. It's not currently possible for JumpToUefiKernel() to ever be called (even accidentally) because BIT2 and BIT3 of Bp->hdr.load_flags are never set in modern kernels, which means that control is always transferred to the kernel via the legacy entry point. Look at the correct field so that the EFI handover protocol is used whenever it's available. Contributed-under: TianoCore Contribution Agreement 1.0 Cc: David Woodhouse <David.Woodhouse@intel.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Borislav Petkov <bp@suse.de> Signed-off-by: Matt Fleming <matt.fleming@intel.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@14721 6f19259b-4bc3-4df7-8a09-765794883524
2013-09-24OvmfPkg: Remove IndustryStandard/X64Paging.hJordan Justen
Since we no longer building page tables in SEC C code, we no longer need this file. This reverts commit r14493. 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: Laszlo Ersek <lersek@redhat.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@14720 6f19259b-4bc3-4df7-8a09-765794883524
2013-09-24OvmfPkg/Sec: Stop building identity mapped pages in SECJordan Justen
Now for X64 we use a VTF0 ResetVector which puts the page tables in RAM. Therefore SEC no longer needs to do this. This reverts commit r14494. 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: Laszlo Ersek <lersek@redhat.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@14719 6f19259b-4bc3-4df7-8a09-765794883524
2013-09-24OvmfPkg X64: Convert 24KB from uncompressed to compressed storageJordan Justen
Since we no longer require flash tables to be stored uncompressed in the flash image, we can now give extra space to the main/compressed storage area. 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: Laszlo Ersek <lersek@redhat.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@14718 6f19259b-4bc3-4df7-8a09-765794883524
2013-09-24OvmfPkg: For OvmfPkgX64, use OvmfPkg/ResetVectorJordan Justen
This reset vector code will build page tables in RAM at address 0x80000, rather than relying on page tables to be present within the flash image. 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: Laszlo Ersek <lersek@redhat.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@14717 6f19259b-4bc3-4df7-8a09-765794883524
2013-09-24OvmfPkg/ResetVector: enable caching in initial page tablesLaszlo Ersek
In UEFI X64 we use other mechanisms to disable caching. (CD/NW in CR0 and MTRRs.) This fixes a slow boot issue with SVM. 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://svn.code.sf.net/p/edk2/code/trunk/edk2@14716 6f19259b-4bc3-4df7-8a09-765794883524
2013-09-24OvmfPkg: Add platform specific reset vector code for X64Jordan Justen
KVM has a bug that prevents using page tables in the ROM if the ROM region utilizes the KVM READONLY memory feature. Therefore, we avoid using page tables stored in the ROM. Since OVMF doesn't require memory initialization, we just build page table entries in RAM at 0x80000 very early in the OVMF boot process. This address is just after the 'temp RAM' which is set up by the SEC module. Currently we only set up 4GB of page tables for OVMF's PEI, but DxeIpl will build identity mapped page tables that cover all of the available processor physical address space. Reported-by: Gary Ching-Pang Lin <glin@suse.com> 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: Laszlo Ersek <lersek@redhat.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@14715 6f19259b-4bc3-4df7-8a09-765794883524
2013-09-21OvmfPkg: resolve TpmMeasurementLib dependency introduced in r14687Laszlo Ersek
(1) OVMF depends on MdeModulePkg/Universal/SecurityStubDxe/SecurityStubDxe.inf unconditionally. (2) When OVMF is built with -D SECURE_BOOT_ENABLE, then SecurityPkg/Library/DxeImageVerificationLib/DxeImageVerificationLib.inf is injected into SecurityStubDxe above. (3) SVN r14687 ("Add TPM2 implementation.") has made DxeImageVerificationLib dependent on TpmMeasurementLib. Currently the last link of the OVMF -> SecurityStubDxe -> DxeImageVerificationLib -> TpmMeasurementLib dependency chain is unresolved: build.py... /.../OvmfPkg/OvmfPkgX64.dsc(...): error 4000: Instance of library class [TpmMeasurementLib] is not found in [/.../SecurityPkg/Library/DxeImageVerificationLib/DxeImageVerificationLib.inf] [X64] consumed by module [/.../MdeModulePkg/Universal/SecurityStubDxe/SecurityStubDxe.inf] Let's provide a library instance for TpmMeasurementLib the same way as "SecurityPkg/SecurityPkg.dsc" does (SVN r13964.) 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://svn.code.sf.net/p/edk2/code/trunk/edk2@14690 6f19259b-4bc3-4df7-8a09-765794883524
2013-09-13OvmfPkg: QemuBootOrder: keep some boot options that have not been selectedLaszlo Ersek
Some of the active boot options that have not been selected over fw_cfg should be preserved at the end of the boot order. For now we're adding back everything that starts with neither PciRoot() nor HD(). This includes the UEFI shell, memory-mapped from the firmware image. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Tested-by: Michael Chang <mchang@suse.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@14668 6f19259b-4bc3-4df7-8a09-765794883524
2013-09-13OvmfPkg: QemuBootOrder: mark UEFI boot options selected by fw_cfgLaszlo Ersek
This will allow us to identify those UEFI boot options (while keeping their relative order) that have *not* been selected by fw_cfg. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Tested-by: Michael Chang <mchang@suse.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@14667 6f19259b-4bc3-4df7-8a09-765794883524
2013-09-13OvmfPkg: QemuBootOrder: collect active UEFI boot options in advanceLaszlo Ersek
In preparation for the next patch, collect active UEFI boot options in advance into a new array. Rebase the current inner loop (the matching loop) to this array. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Tested-by: Michael Chang <mchang@suse.com> [jordan.l.justen@intel.com: initialize *ActiveOption for GCC IA32 warning] Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@14666 6f19259b-4bc3-4df7-8a09-765794883524
2013-09-13OvmfPkg: QemuBootOrder: expand relative device paths in UEFI boot optionsLaszlo Ersek
The prefix matching logic in Match() [OvmfPkg/Library/PlatformBdsLib/QemuBootOrder.c] expects UEFI boot options to specify full (absolute) device paths. However, partial (relative) device paths starting with a HD() node are valid for booting. By not recognizing them, QemuBootOrder.c misses (and deletes) valid boot options that would otherwise match the user's preference. Just like BdsLibBootViaBootOption() expands such paths with the BdsExpandPartitionPartialDevicePathToFull() function for booting, do the same in QemuBootOrder.c for prefix matching. This moves the very first call to BdsExpandPartitionPartialDevicePathToFull() to an earlier point. The following call tree explains it: BdsEntry() [IntelFrameworkModulePkg/Universal/BdsDxe/BdsEntry.c] PlatformBdsPolicyBehavior() [OvmfPkg/Library/PlatformBdsLib/BdsPlatform.c] SetBootOrderFromQemu() [OvmfPkg/Library/PlatformBdsLib/QemuBootOrder.c] Match() [OvmfPkg/Library/PlatformBdsLib/QemuBootOrder.c] BdsExpandPartitionPartialDevicePathToFull() [IntelFrameworkModulePkg/Library/GenericBdsLib/BdsBoot.c] BdsBootDeviceSelect() [IntelFrameworkModulePkg/Universal/BdsDxe/BdsEntry.c] BdsLibBootViaBootOption() [IntelFrameworkModulePkg/Library/GenericBdsLib/BdsBoot.c] BdsExpandPartitionPartialDevicePathToFull() [IntelFrameworkModulePkg/Library/GenericBdsLib/BdsBoot.c] This should be fine, for two reasons: - the new, earlier call is still under BdsEntry(), - BdsExpandPartitionPartialDevicePathToFull() expects to be called repeatedly, even with the same set of HD() device paths. This function implements its own caching for device paths, likely for performance reasons. That fits this patch well because whatever device paths we expand under PlatformBdsPolicyBehavior() can be quickly looked up in BdsBootDeviceSelect(), so no work (ie. BdsLibConnectAllDriversToAllControllers()) should be wasted. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Tested-by: Michael Chang <mchang@suse.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@14665 6f19259b-4bc3-4df7-8a09-765794883524
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
generated by cgit v1.2.3 (git 2.25.1) at 2025-01-15 15:04:13 +0000