qemu-devel
[Top][All Lists]
Advanced

[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 13:12:33 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20131118 Thunderbird/17.0.11

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]