On Mon, Jan 28, 2013 at 12:48:43PM -0600, Anthony Liguori wrote:
> Gleb Natapov writes:
>
> > On Mon, Jan 28, 2013 at 10:10:06AM -0600, Anthony Liguori wrote:
> >> David Woodhouse writes:
> >>
> >> > On Sun, 2013-01-27 at 18:53 -0600, Anthony Liguori wrote:
> >> >> Are you just trying to persis
Gleb Natapov writes:
> On Mon, Jan 28, 2013 at 10:10:06AM -0600, Anthony Liguori wrote:
>> David Woodhouse 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.
>> >
>>
On Mon, Jan 28, 2013 at 10:10:06AM -0600, Anthony Liguori wrote:
> David Woodhouse 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 fla
Jordan Justen writes:
> On Mon, Jan 28, 2013 at 8:10 AM, Anthony Liguori
> wrote:
>> David Woodhouse 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
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
On Mon, Jan 28, 2013 at 8:10 AM, Anthony Liguori wrote:
> David Woodhouse 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?
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 a
David Woodhouse 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* with KVM.
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 writes:
> On Sun, 2013-01-27 at 10:29 -0600, Anthony Liguori wrote:
>> David Woodhouse 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.
>> >
On Sun, Jan 27, 2013 at 8:38 AM, David Woodhouse wrote:
> On Sun, 2013-01-27 at 16:02 +, Blue Swirl wrote:
>> On Sun, Jan 27, 2013 at 3:50 PM, David Woodhouse wrote:
>> > On Sun, 2013-01-27 at 15:14 +, Blue Swirl wrote:
>> >> It looks like this duplicates rom_add_file() and fw_cfg_add_fil
On Sun, Jan 27, 2013 at 4:47 PM, David Woodhouse wrote:
> On Sun, 2013-01-27 at 10:29 -0600, Anthony Liguori wrote:
>> David Woodhouse 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 EF
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 signatu
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 wit
On Sun, Jan 27, 2013 at 4:38 PM, David Woodhouse wrote:
> On Sun, 2013-01-27 at 16:02 +, Blue Swirl wrote:
>> On Sun, Jan 27, 2013 at 3:50 PM, David Woodhouse wrote:
>> > On Sun, 2013-01-27 at 15:14 +, Blue Swirl wrote:
>> >> It looks like this duplicates rom_add_file() and fw_cfg_add_fil
On Sun, 2013-01-27 at 10:29 -0600, Anthony Liguori wrote:
> David Woodhouse 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
On Sun, 2013-01-27 at 16:02 +, Blue Swirl wrote:
> On Sun, Jan 27, 2013 at 3:50 PM, David Woodhouse 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
David Woodhouse 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 introduced, but we
On Sun, Jan 27, 2013 at 3:50 PM, David Woodhouse 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 can't
> use them
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 Sat, Jan 26, 2013 at 8:43 PM, David Woodhouse 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 fairly much since
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
