[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [edk2] [edk2 PATCH] OvmfPkg: split the variable store t
From: |
Laszlo Ersek |
Subject: |
Re: [Qemu-devel] [edk2] [edk2 PATCH] OvmfPkg: split the variable store to a separate file |
Date: |
Fri, 22 Nov 2013 12:46:33 +0100 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20131118 Thunderbird/17.0.11 |
On 11/22/13 10:27, Paolo Bonzini wrote:
> Il 21/11/2013 23:21, Laszlo Ersek ha scritto:
>> Split the variable store off to a separate file when SPLIT_VARSTORE is
>> defined.
>>
>> Even in this case, the preexistent PCDs' values don't change. Qemu must
>> take care of contiguously mapping NVVARSTORE.fd + OVMF.fd so that when
>> concatenated they end exactly at 4GB.
>>
>> Contributed-under: TianoCore Contribution Agreement 1.0
>> Signed-off-by: Laszlo Ersek <address@hidden>
>
> It's good that this is so easy to do.
>
> The obvious question is, what happens if you only pass only OVMF.fd
> (which would be less than 2MB in size, right)?
Yes, when -D SPLIT_VARSTORE is passed, then NVVARSTORE.fd is built in
addition, and is 128KB in size, and OVMF.fd becomes 2MB-128KB == 1920KB
in size (unless you also passed -D FD_SIZE_1MB, in which case it's 896KB).
If you only pass the split OVMF.fd with -pflash to qemu, then it will be
mapped into the same place: [4GB-1920KB .. 4GB[.
It will scan the first 4KB (the first PcdOvmfFirmwareBlockSize bytes) at
4GB-2048KB -- ie. where NVVARSTORE would have been mapped had you not
forgotten to pass it.
OvmfPkg/QemuFlashFvbServicesRuntimeDxe/QemuFlash.c, QemuFlashDetected():
for (Offset = 0; Offset < mFdBlockSize; Offset++) {
Ptr = QemuFlashPtr (0, Offset);
ProbeUint8 = *Ptr;
if (ProbeUint8 != CLEAR_STATUS_CMD &&
ProbeUint8 != READ_STATUS_CMD &&
ProbeUint8 != CLEARED_ARRAY_STATUS) {
break;
}
}
if (Offset >= mFdBlockSize) {
DEBUG ((EFI_D_INFO, "QEMU Flash: Failed to find probe location\n"));
return FALSE;
}
It looks for a byte in [4GB-2048KB .. 4GB-2044KB[ that's different from
all of those values. CLEARED_ARRAY_STATUS is zero. The flash driver will
not install, and the on-disk NvVars emulation will be enabled. The guest
should then boot with this original NvVars emulation.
It does in my testing anyway; this is the OVMF log:
QEMU Flash: Failed to find probe location
QEMU flash was not detected. Writable FVB is not being installed.
[...]
FsAccess.c: LoadNvVarsFromFs
[...]
> Also, I see a command line compatibility problem, especially if one
> wants OVMF.fd to become the default firmware.
I don't understand. If you use the un-split build, you use the original
command line (single -pflash or -drive if=pflash option).
If you use the split build, then you:
- extend the first -drive if=pflash option with ",readonly" -- this is
optional but recommended,
- you add a second option after the first, pointing it to NVVARSTORE.fd
(ie. its VM-specific, private copy).
> Then, having to specify
> it again on the command line would be strange.
You don't specify OVMF.fd twice. The second option refers to NVVARSTORE.fd.
I think I don't fully understand your point.
Do you want any switching between un-split OVMF.fd and split
(OVMF.fd+NVVARSTORE.fd) to be transparent to the qemu command line user?
(Be it a person or libvirt?)
Laszlo
Re: [Qemu-devel] [qemu PATCH] hw/i386/pc_sysfw: support more than one flash drive, Eric Blake, 2013/11/21