From: Jordan Justen <jljusten@gmail.com>
To: Gleb Natapov <gleb@redhat.com>
Cc: qemu-devel <qemu-devel@nongnu.org>
Subject: Re: [Qemu-devel] OVMF, SeaBIOS & non-CSM based legacy boot
Date: Thu, 24 Mar 2011 09:46:09 -0700 [thread overview]
Message-ID: <AANLkTimDwdwf7sBVEnmBF7e5Zu9U3_hgWRBS0kD=LGOL@mail.gmail.com> (raw)
In-Reply-To: <20110324115300.GC32408@redhat.com>
2011/3/24 Gleb Natapov <gleb@redhat.com>:
> On Wed, Mar 23, 2011 at 03:32:41PM -0700, Jordan Justen wrote:
>> By the way, today OVMF attempts to store NV-Var data in a file on the
>> disk, but this cannot support variables at runtime. (This is why I
>> sent in the patch for using -pflash on x86/x86-64.)
>>
> And this file is stored always at the same location? If it is then then
> problem is solved! But what do you mean by "this cannot support
> variables at runtime"?
The variables can be set while the OS is running, and the OS has
exclusive control over the disk at that time. Today in OVMF we set
variables into memory during this time, and hope that memory it still
around after a reset. This does not provide realistic non-volatile
UEFI variable support.
What we really need is flash memory. (See my 'hw/pc: Support system
flash memory' patch.)
But, there is nothing stopping us from also storing the variables on
the disk (during the firmware boot), and also using them as a backup.
Additionally, we can add yet another backup system of looking for
known os-loader executable paths. This would be needed if a disk
image were ever to be transferred from a real machine to a VM image.
But, this would require firmware updates as new UEFI OS loader install
paths are added. Also, let's hope no OS decides to generate a random
path for the OS loader. :)
-Jordan
next prev parent reply other threads:[~2011-03-24 16:47 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-03-21 18:14 [Qemu-devel] OVMF, SeaBIOS & non-CSM based legacy boot Jordan Justen
2011-03-21 18:27 ` Anthony Liguori
2011-03-21 21:06 ` Stefan Hajnoczi
2011-03-21 21:17 ` Michael Brown
2011-03-21 21:31 ` Jordan Justen
2011-03-21 21:40 ` Stefan Hajnoczi
2011-03-21 23:14 ` Michael Brown
2011-03-21 21:23 ` Jordan Justen
2011-03-22 8:00 ` Gleb Natapov
2011-03-22 19:28 ` Jordan Justen
2011-03-22 20:07 ` Gleb Natapov
2011-03-22 21:53 ` Jordan Justen
2011-03-23 12:36 ` Gleb Natapov
2011-03-23 22:32 ` Jordan Justen
2011-03-24 11:53 ` Gleb Natapov
2011-03-24 16:46 ` Jordan Justen [this message]
2011-03-24 18:36 ` Gleb Natapov
2011-03-24 12:27 ` Michal Suchanek
2011-03-24 13:44 ` Gleb Natapov
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='AANLkTimDwdwf7sBVEnmBF7e5Zu9U3_hgWRBS0kD=LGOL@mail.gmail.com' \
--to=jljusten@gmail.com \
--cc=gleb@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).