On 11/07/13 17:28, Laszlo Ersek wrote:
> On 11/06/13 23:29, Jordan Justen wrote:
>> https://github.com/jljusten/edk2.git ovmf-nvvars-v2
>>
>> This series implements support for QEMU's emulated
>> system flash.
>>
>> This allows for persistent UEFI non-volatile variables.
>>
>> Previously we attempted to emulate non-volatile
>> variables in a few ways, but each of them would fail
>> in particular situations.
>>
>> To support flash based variable storage, we:
>> * Reserve space in the firmware device image
>> * Add a new flash firmware volume block driver
>> * Disable EmuVariableFvbRuntimeDxe (at runtime) if QEMU
>> flash is available.
>>
>> To use:
>> * QEMU version 1.1 or newer is required without KVM
>> * KVM support requires Linux 3.7 and QEMU 1.6
>> * Run QEMU with -pflash OVMF.fd instead of -L or -bios
>> or use OvmfPkg/build.sh --enable-flash qemu ...
>> * If QEMU is 1.6 or newer, then OvmfPkg/build.sh will
>> automatically enable flash when running QEMU, so in
>> that case --enable-flash is not required.
>>
>> See also:
>> * http://wiki.qemu.org/Features/PC_System_Flash
>>
>> v2:
>> * Replace
>> "OvmfPkg/AcpiPlatformDxe/Qemu: Allow high runtime memory regions"
>> with
>> "OvmfPkg/AcpiPlatformDxe/Qemu: Decrease upper limit for PCI window 32"
>> * Separate portions of
>> "OvmfPkg/build.sh: Support --enable-flash switch"
>> out into a new patch
>> "OvmfPkg/build.sh: Enable flash for QEMU >= 1.6"
>> * Add "OvmfPkg/README: Add information about OVMF flash layout"
>> * Update "OvmfPkg: Add NV Variable storage within FD" to also change the
>> size of PcdVariableStoreSize
>> * Update commit messages on a couple patches for better clarity
>
> Tested in the following configurations:
>
> (1) RHEL-6 host (no KVM support, no qemu support -- that is, regression
> test): RHEL-6, Fedora 19, Windows 2008 R2 (needs CSM), Windows 2012 R2
> boot tests work OK.
>
> (2) 3.10-based host kernel, qemu v1.7.0-rc0, Xeon W3550 host CPU:
> Unfortunately qemu dies with the following KVM trace:
>
> KVM internal error. Suberror: 1
> emulation failure
> EAX=00000000 EBX=00000000 ECX=00000000 EDX=00000623
> ESI=00000000 EDI=00000000 EBP=00000000 ESP=00000000
> EIP=0000fff0 EFL=00000002 [-------] CPL=0 II=0 A20=1 SMM=0 HLT=0
> ES =0000 00000000 0000ffff 00009300
> CS =f000 ffff0000 0000ffff 00009b00
> SS =0000 00000000 0000ffff 00009300
> DS =0000 00000000 0000ffff 00009300
> FS =0000 00000000 0000ffff 00009300
> GS =0000 00000000 0000ffff 00009300
> LDT=0000 00000000 0000ffff 00008200
> TR =0000 00000000 0000ffff 00008b00
> GDT= 00000000 0000ffff
> IDT= 00000000 0000ffff
> CR0=60000010 CR2=00000000 CR3=00000000 CR4=00000000
> DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000
> DR3=0000000000000000
> DR6=00000000ffff0ff0 DR7=0000000000000400
> EFER=0000000000000000
> Code=ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff <ff> ff ff
> ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> ff
>
> I'm quite unsure, but the CS:IP value seems to point at the reset
> vector, no? However, the Code=... log only shows 0xFF bytes.
>
> (3) 3.10.17 host kernel, qemu v1.7.0-rc0, Athlon II X2 B22 host CPU:
> almost identical KVM error, with the following difference:
>
> --- vmx 2013-11-07 17:23:45.612973935 +0100
> +++ svm 2013-11-07 17:24:17.237973059 +0100
> @@ -1,6 +1,6 @@
> KVM internal error. Suberror: 1
> emulation failure
> -EAX=00000000 EBX=00000000 ECX=00000000 EDX=00000623
> +EAX=00000000 EBX=00000000 ECX=00000000 EDX=00000663
> ESI=00000000 EDI=00000000 EBP=00000000 ESP=00000000
> EIP=0000fff0 EFL=00000002 [-------] CPL=0 II=0 A20=1 SMM=0 HLT=0
> ES =0000 00000000 0000ffff 00009300
>
> Any ideas?
I.
This is a QEMU regression (somewhere between v1.6.0 and v1.7.0-rc0),
I'll have to bisect it.
II.
So, in addition to the successful regression test in (1), I tested the
feature in the following environments:
(2) 3.10-based host kernel, qemu v1.6.1, Xeon W3550 host CPU:
- successful RHEL-7 boot,
- my "personal" CSM build runs into an assert (triggered by one of the
CSM patches) -- this would be needed for Windows 2008 R2.
(3) 3.10.17 host kernel, qemu v1.6.1, Athlon II X2 B22 host CPU:
- successful Fedora 19 boot.
The CSM patches I've been using are not official (they are not in the
tree). I'll have to look what's wrong with them, when this series is
applied, but they should certainly not block the series.
Therefore:
series
Tested-by: Laszlo Ersek <[email protected]>
I also wanted to test secure boot (see if the enrolled keys survive a
cold reboot), but I noticed that this series doesn't disable the "load
variables from the NvVars file" functionality.
I added the attached patch on top of this series, and this way the
enrolled keys seem to persist. I could fully secure-boot Fedora 19 on my
SVM host with it, even after a full VM shutdown. Do you think the patch
has merit?
Thanks
Laszlo
From 8007b83217c6671737cdf6ce0d7b6664f6c5785b Mon Sep 17 00:00:00 2001
From: Laszlo Ersek <[email protected]>
Date: Thu, 7 Nov 2013 18:18:43 +0100
Subject: [PATCH] OvmfPkg/BdsPlatform: don't restore NvVars from disk if we
have working flash
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <[email protected]>
---
OvmfPkg/Library/PlatformBdsLib/BdsPlatform.c | 15 ++++++++++-----
OvmfPkg/Library/PlatformBdsLib/PlatformBdsLib.inf | 1 +
2 files changed, 11 insertions(+), 5 deletions(-)
diff --git a/OvmfPkg/Library/PlatformBdsLib/BdsPlatform.c
b/OvmfPkg/Library/PlatformBdsLib/BdsPlatform.c
index ba6af2c..c146a64 100644
--- a/OvmfPkg/Library/PlatformBdsLib/BdsPlatform.c
+++ b/OvmfPkg/Library/PlatformBdsLib/BdsPlatform.c
@@ -1073,11 +1073,16 @@ Returns:
ConnectRootBridge ();
- //
- // Try to restore variables from the hard disk early so
- // they can be used for the other BDS connect operations.
- //
- PlatformBdsRestoreNvVarsFromHardDisk ();
+ if (PcdGet64 (PcdFlashNvStorageVariableBase64) == 0) {
+ //
+ // Try to restore variables from the hard disk early so
+ // they can be used for the other BDS connect operations.
+ //
+ PlatformBdsRestoreNvVarsFromHardDisk ();
+ } else {
+ DEBUG ((EFI_D_INFO, "PlatformBdsPolicyBehavior: not restoring NvVars "
+ "from disk since flash variables appear to be supported.\n"));
+ }
//
// Init the time out value
diff --git a/OvmfPkg/Library/PlatformBdsLib/PlatformBdsLib.inf
b/OvmfPkg/Library/PlatformBdsLib/PlatformBdsLib.inf
index 7f7f473..1151bc4 100644
--- a/OvmfPkg/Library/PlatformBdsLib/PlatformBdsLib.inf
+++ b/OvmfPkg/Library/PlatformBdsLib/PlatformBdsLib.inf
@@ -57,6 +57,7 @@
gEfiIntelFrameworkModulePkgTokenSpaceGuid.PcdPlatformBootTimeOut
gEfiIntelFrameworkModulePkgTokenSpaceGuid.PcdLogoFile
gUefiOvmfPkgTokenSpaceGuid.PcdEmuVariableEvent
+ gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageVariableBase64
[Pcd.IA32, Pcd.X64]
gEfiMdePkgTokenSpaceGuid.PcdFSBClock
--
1.8.3.1
------------------------------------------------------------------------------
November Webinars for C, C++, Fortran Developers
Accelerate application performance with scalable programming models. Explore
techniques for threading, error checking, porting, and tuning. Get the most
from the latest Intel processors and coprocessors. See abstracts and register
http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk
_______________________________________________
edk2-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/edk2-devel
