On Sun, 2013-01-27 at 18:53 -0600, Anthony Liguori wrote:
Are you just trying to persist a single blob of a fixed maximum size?
That would suffice.
Why not just have a second flash device then?
Mostly because flash devices don't actually *work* with KVM.
Should I be looking at fixing *that*,
David Woodhouse dw...@infradead.org writes:
On Sun, 2013-01-27 at 18:53 -0600, Anthony Liguori wrote:
Are you just trying to persist a single blob of a fixed maximum size?
That would suffice.
Why not just have a second flash device then?
Mostly because flash devices don't actually *work*
On Mon, 2013-01-28 at 10:10 -0600, Anthony Liguori wrote:
Mostly because flash devices don't actually *work* with KVM.
They absolutely do. What doesn't work is executing ROM from flash if
the ROM cannot be treated as read-only memory.
Ah, great. In that case, that seems like the best
On Mon, Jan 28, 2013 at 8:10 AM, Anthony Liguori anth...@codemonkey.ws wrote:
David Woodhouse dw...@infradead.org writes:
On Sun, 2013-01-27 at 18:53 -0600, Anthony Liguori wrote:
Are you just trying to persist a single blob of a fixed maximum size?
That would suffice.
Why not just have a
On Mon, 2013-01-28 at 08:36 -0800, Jordan Justen wrote:
What is need is for pflash_cfi01 to start in plain rom/executable mode
while firmware executes from it during early boot.
Then later, after the rom has been shadowed, firmware will want to
write to that memory space to program it. At
Jordan Justen jljus...@gmail.com writes:
On Mon, Jan 28, 2013 at 8:10 AM, Anthony Liguori anth...@codemonkey.ws
wrote:
David Woodhouse dw...@infradead.org writes:
On Sun, 2013-01-27 at 18:53 -0600, Anthony Liguori wrote:
Are you just trying to persist a single blob of a fixed maximum size?
On Mon, Jan 28, 2013 at 10:10:06AM -0600, Anthony Liguori wrote:
David Woodhouse dw...@infradead.org writes:
On Sun, 2013-01-27 at 18:53 -0600, Anthony Liguori wrote:
Are you just trying to persist a single blob of a fixed maximum size?
That would suffice.
Why not just have a second
Gleb Natapov g...@redhat.com writes:
On Mon, Jan 28, 2013 at 10:10:06AM -0600, Anthony Liguori wrote:
David Woodhouse dw...@infradead.org writes:
On Sun, 2013-01-27 at 18:53 -0600, Anthony Liguori wrote:
Are you just trying to persist a single blob of a fixed maximum size?
That would
On Mon, Jan 28, 2013 at 12:48:43PM -0600, Anthony Liguori wrote:
Gleb Natapov g...@redhat.com writes:
On Mon, Jan 28, 2013 at 10:10:06AM -0600, Anthony Liguori wrote:
David Woodhouse dw...@infradead.org writes:
On Sun, 2013-01-27 at 18:53 -0600, Anthony Liguori wrote:
Are you just
On Sat, Jan 26, 2013 at 8:43 PM, David Woodhouse dw...@infradead.org wrote:
For OVMF we really want to have a way to store non-volatile variables,
other than the dirty hack that currently puts them on a file in the EFI
system partition.
It looks like we've supported writing to fw_cfg items
On Sun, 2013-01-27 at 15:14 +, Blue Swirl wrote:
It looks like this duplicates rom_add_file() and fw_cfg_add_file(), so
I don't see the point.
Both of those are read-only, surely? The firmware inside the guest can't
use them for non-volatile storage.
It doesn't duplicate fw_cfg_add_file();
On Sun, Jan 27, 2013 at 3:50 PM, David Woodhouse dw...@infradead.org wrote:
On Sun, 2013-01-27 at 15:14 +, Blue Swirl wrote:
It looks like this duplicates rom_add_file() and fw_cfg_add_file(), so
I don't see the point.
Both of those are read-only, surely? The firmware inside the guest
David Woodhouse dw...@infradead.org writes:
For OVMF we really want to have a way to store non-volatile variables,
other than the dirty hack that currently puts them on a file in the EFI
system partition.
It looks like we've supported writing to fw_cfg items fairly much since
they were
On Sun, 2013-01-27 at 16:02 +, Blue Swirl wrote:
On Sun, Jan 27, 2013 at 3:50 PM, David Woodhouse dw...@infradead.org wrote:
On Sun, 2013-01-27 at 15:14 +, Blue Swirl wrote:
It looks like this duplicates rom_add_file() and fw_cfg_add_file(), so
I don't see the point.
Both of
On Sun, 2013-01-27 at 10:29 -0600, Anthony Liguori wrote:
David Woodhouse dw...@infradead.org writes:
For OVMF we really want to have a way to store non-volatile variables,
other than the dirty hack that currently puts them on a file in the EFI
system partition.
It looks like we've
On Sun, Jan 27, 2013 at 4:38 PM, David Woodhouse dw...@infradead.org wrote:
On Sun, 2013-01-27 at 16:02 +, Blue Swirl wrote:
On Sun, Jan 27, 2013 at 3:50 PM, David Woodhouse dw...@infradead.org wrote:
On Sun, 2013-01-27 at 15:14 +, Blue Swirl wrote:
It looks like this duplicates
On Sun, 2013-01-27 at 16:55 +, Blue Swirl wrote:
That problem could be easily solved by allowing a combination of two
images with different RO/RW settings, for example -bios
bios.bin[,offset=0,ro] -bios flash.img, offset=0x8000,rw.
/me shudders at the idea of co-ordinating that with
On Sun, 2013-01-27 at 16:59 +, Blue Swirl wrote:
For example hw/spapr_nvram.c implements a similar device. If the user
does not specify any backing file for nvram, its contents will not be
saved.
I'll look at that; thanks.
--
dwmw2
smime.p7s
Description: S/MIME cryptographic signature
On Sun, Jan 27, 2013 at 4:47 PM, David Woodhouse dw...@infradead.org wrote:
On Sun, 2013-01-27 at 10:29 -0600, Anthony Liguori wrote:
David Woodhouse dw...@infradead.org writes:
For OVMF we really want to have a way to store non-volatile variables,
other than the dirty hack that currently
On Sun, Jan 27, 2013 at 8:38 AM, David Woodhouse dw...@infradead.org wrote:
On Sun, 2013-01-27 at 16:02 +, Blue Swirl wrote:
On Sun, Jan 27, 2013 at 3:50 PM, David Woodhouse dw...@infradead.org wrote:
On Sun, 2013-01-27 at 15:14 +, Blue Swirl wrote:
It looks like this duplicates
David Woodhouse dw...@infradead.org writes:
On Sun, 2013-01-27 at 10:29 -0600, Anthony Liguori wrote:
David Woodhouse dw...@infradead.org writes:
For OVMF we really want to have a way to store non-volatile variables,
other than the dirty hack that currently puts them on a file in the EFI
For OVMF we really want to have a way to store non-volatile variables,
other than the dirty hack that currently puts them on a file in the EFI
system partition.
It looks like we've supported writing to fw_cfg items fairly much since
they were introduced, but we've never actually made use of that.
22 matches
Mail list logo
