From: Laszlo Ersek <lersek@redhat.com>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: "Jordan Justen (Intel address)" <jordan.l.justen@intel.com>,
edk2-devel@lists.sourceforge.net, qemu-devel@nongnu.org,
crobinso@redhat.com
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 [thread overview]
Message-ID: <528F4419.6010504@redhat.com> (raw)
In-Reply-To: <528F2385.50300@redhat.com>
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 <lersek@redhat.com>
>
> 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
next prev parent reply other threads:[~2013-11-22 11:46 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-11-21 22:21 [Qemu-devel] [qemu PATCH] hw/i386/pc_sysfw: support more than one flash drive Laszlo Ersek
2013-11-21 22:21 ` [Qemu-devel] [edk2 PATCH] OvmfPkg: split the variable store to a separate file Laszlo Ersek
2013-11-22 9:27 ` [Qemu-devel] [edk2] " Paolo Bonzini
2013-11-22 11:46 ` Laszlo Ersek [this message]
2013-11-22 11:56 ` Paolo Bonzini
2013-11-22 12:12 ` Laszlo Ersek
2013-11-22 17:37 ` [Qemu-devel] " Jordan Justen
2013-11-22 18:43 ` Laszlo Ersek
2013-11-22 20:51 ` Jordan Justen
2013-11-22 20:54 ` Eric Blake
2013-11-22 21:18 ` Jordan Justen
2013-11-22 21:40 ` Laszlo Ersek
2013-11-22 21:45 ` Laszlo Ersek
2013-11-21 22:26 ` [Qemu-devel] [qemu PATCH] hw/i386/pc_sysfw: support more than one flash drive Eric Blake
2013-11-21 22:33 ` Laszlo Ersek
2013-11-22 12:21 ` Markus Armbruster
2013-11-22 18:30 ` Laszlo Ersek
2013-11-25 15:22 ` Markus Armbruster
2013-11-25 19:45 ` Laszlo Ersek
2013-11-26 12:36 ` Markus Armbruster
2013-11-26 13:32 ` Laszlo Ersek
2013-11-26 17:54 ` Jordan Justen
2013-11-27 13:52 ` Markus Armbruster
2013-11-27 14:01 ` Laszlo Ersek
2013-11-27 14:45 ` Markus Armbruster
2013-11-27 15:18 ` Laszlo Ersek
2013-11-27 17:22 ` Markus Armbruster
2013-11-27 17:34 ` Laszlo Ersek
2013-11-27 20:35 ` Markus Armbruster
2013-11-26 13:41 ` [Qemu-devel] [edk2] " Paolo Bonzini
2013-11-26 13:53 ` Laszlo Ersek
2013-11-26 14:06 ` Paolo Bonzini
2013-11-26 12:53 ` [Qemu-devel] " Markus Armbruster
2013-11-26 13:27 ` Laszlo Ersek
2013-11-27 13:49 ` Markus Armbruster
2013-11-27 14:01 ` Laszlo Ersek
2013-11-25 15:32 ` Markus Armbruster
2013-11-25 20:17 ` Laszlo Ersek
2013-11-26 13:11 ` Markus Armbruster
2013-11-26 13:39 ` Laszlo Ersek
2013-11-26 15:35 ` Markus Armbruster
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=528F4419.6010504@redhat.com \
--to=lersek@redhat.com \
--cc=crobinso@redhat.com \
--cc=edk2-devel@lists.sourceforge.net \
--cc=jordan.l.justen@intel.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).