From: Laszlo Ersek <lersek@redhat.com>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: 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 13:12:33 +0100 [thread overview]
Message-ID: <528F4A31.3050707@redhat.com> (raw)
In-Reply-To: <528F467B.2000202@redhat.com>
On 11/22/13 12:56, Paolo Bonzini wrote:
> Il 22/11/2013 12:46, Laszlo Ersek ha scritto:
>>> 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).
>
> Suppose OVMF.fd is already the default. To add a non-volatile store,
> you would have to do one of the following:
>
> * -pflash /path/to/OVMF.fd -pflash NVVARSTORE.fd
>
>
> Or alternatively, pc and q35 could use the current semantics forever.
> UEFI-by-default will be tied to a separate machine type (pc-uefi, or
> q35-uefi, or a different chipset) where -bios will also create a
> cfi_pflash01 device and all pflash drives will be mapped below the
> BIOS's. So you would have one of the following:
>
> * -M pc -pflash /path/to/OVMF.fd -pflash NVVARSTORE.fd
>
> * -M pc-uefi -pflash NVVARSTORE.fd
>
>> You don't specify OVMF.fd twice.
>
> I meant the first time is inside QEMU, the second is on the command line.
>
>> I think I don't fully understand your point.
>
> I probably didn't express it well, also because I have no real idea to
> offer (I don't like the "-M pc-uefi" either).
Ah sorry, I get it now. You'd change the default bios in qemu itself
(that would be the first specification), to OVMF.fd, and then adding
NVVARSTORE.fd on the command line would be the second specification.
I didn't think of this because I didn't consider changing the bios
default in qemu at all. Now that you mentioned it, my first reaction was
"use a new machine type" :)
I realize we're currently changing (refreshing) SeaBIOS builds without
introducing new machine types all the time. Maybe OVMF would justify a
change (if you indeed want to change the in-qemu default).
Hm... If you just change the default bios file name in qemu, that will
still result in an (implicit) -bios option. Whereas for
OVMF.fd+NVVARSTORE.fd, you need zero -bios options, and two -pflash
options. (Considering even a single OVMF.fd, you'd still pass it with
one -pflash option and zero -bios options, otherwise you'd have no
chance at all at a flash variable store.)
Currently, adding (one or more) -pflash option(s) on the command line,
for the PCI-enabled pc machine type(s), makes any -bios option a no-op
-- old_pc_system_rom_init() is not called.
So, I think if you want to change the default in qemu, changing just the
bios filename wouldn't be enough, it might have to include changing from
-bios to -pflash as well. But this would certainly need a new machine
type, no?
(What I managed (not) to describe with oh so many words is basically "pc
and q35 could use the current semantics forever", ie. your 2nd and 3rd
alternatives.)
Thanks,
Laszlo
next prev parent reply other threads:[~2013-11-22 12:12 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
2013-11-22 11:56 ` Paolo Bonzini
2013-11-22 12:12 ` Laszlo Ersek [this message]
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=528F4A31.3050707@redhat.com \
--to=lersek@redhat.com \
--cc=crobinso@redhat.com \
--cc=edk2-devel@lists.sourceforge.net \
--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).