From: Gleb Natapov <gleb@redhat.com>
To: Jordan Justen <jljusten@gmail.com>
Cc: qemu-devel <qemu-devel@nongnu.org>
Subject: Re: [Qemu-devel] OVMF, SeaBIOS & non-CSM based legacy boot
Date: Thu, 24 Mar 2011 20:36:38 +0200 [thread overview]
Message-ID: <20110324183638.GC14544@redhat.com> (raw)
In-Reply-To: <AANLkTimDwdwf7sBVEnmBF7e5Zu9U3_hgWRBS0kD=LGOL@mail.gmail.com>
On Thu, Mar 24, 2011 at 09:46:09AM -0700, Jordan Justen wrote:
> 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.
KVM preserve memory during reset, but we better not rely on that.
>
> What we really need is flash memory. (See my 'hw/pc: Support system
> flash memory' patch.)
Storing boot file only on flash memory will require to distribute the
flash image along with disk image.
>
> 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.
>
This will still require at least one reboot for variables to be saved in
a filesystem, but this is better then nothing.
> 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. :)
>
Firmware updates in a VM is very easy, so not a big deal.
--
Gleb.
next prev parent reply other threads:[~2011-03-24 18:36 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
2011-03-24 18:36 ` Gleb Natapov [this message]
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=20110324183638.GC14544@redhat.com \
--to=gleb@redhat.com \
--cc=jljusten@gmail.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.