On Thu, Nov 21, 2013 at 2:21 PM, Laszlo Ersek ler...@redhat.com wrote:
Split the variable store off to a separate file when SPLIT_VARSTORE is
defined.
Is the goal to allow the central OVMF to be updated so the VM will
automatically be running the newest firmware? (While preserving
variables)
I
On 11/22/13 18:37, Jordan Justen wrote:
On Thu, Nov 21, 2013 at 2:21 PM, Laszlo Ersek ler...@redhat.com wrote:
Split the variable store off to a separate file when SPLIT_VARSTORE is
defined.
Is the goal to allow the central OVMF to be updated so the VM will
automatically be running the
On Fri, Nov 22, 2013 at 10:43 AM, Laszlo Ersek ler...@redhat.com wrote:
OTOH building all three FDs per default might be confusing for
end-users. We know for a fact that they usually don't read the README
(or not thoroughly enough). If we only give them one output file per
default, that's less
On 11/22/2013 01:51 PM, Jordan Justen wrote:
Tangentially related idea: if the user specifies -pflash to a
non-existent file, then QEMU could copy 'pflash-$(arch).bin' from the
roms folder into that file, and then the use it for the flash. It
could make using a flash almost as easy as using
On Fri, Nov 22, 2013 at 12:54 PM, Eric Blake ebl...@redhat.com wrote:
On 11/22/2013 01:51 PM, Jordan Justen wrote:
Tangentially related idea: if the user specifies -pflash to a
non-existent file, then QEMU could copy 'pflash-$(arch).bin' from the
roms folder into that file, and then the use
On 11/22/13 21:51, Jordan Justen wrote:
On Fri, Nov 22, 2013 at 10:43 AM, Laszlo Ersek ler...@redhat.com wrote:
OTOH building all three FDs per default might be confusing for
end-users. We know for a fact that they usually don't read the README
(or not thoroughly enough). If we only give them
On 11/22/13 21:51, Jordan Justen wrote:
Many of these scenarios were discussed in the past on qemu-devel, but
a single -pflash was the only thing that stuck. This has made me just
focus on making the single file pflash work.
I almost forgot to reflect on this -- I'm extremely grateful to you
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