[Qemu-devel] RFC: emulation of system flash

[Qemu-devel] RFC: emulation of system flash

[Jordan Justen]

Hi all,

I have documented a simple flash-like device which I think could be
useful for qemu/kvm in some cases.  (Particularly for allowing
persistent UEFI non-volatile variables.)

http://wiki.qemu.org/Features/System_Flash

Let me know if you have any suggestions or concerns.

Thanks for your time,

-Jordan

[Qemu-devel] Re: RFC: emulation of system flash

[Avi Kivity]

On 03/10/2011 06:51 AM, Jordan Justen wrote:
> Hi all,
>
> I have documented a simple flash-like device which I think could be
> useful for qemu/kvm in some cases.  (Particularly for allowing
> persistent UEFI non-volatile variables.)
>
> http://wiki.qemu.org/Features/System_Flash
>
> Let me know if you have any suggestions or concerns.

Looks pretty nice.  Two suggestions:

- make the flash storage a standard qemu block device.  This allows 
snapshotting, block-live-migration, and other nice features.
- make the programming interface the same as an existing device

-- 
error compiling committee.c: too many arguments to function

[Qemu-devel] Re: RFC: emulation of system flash

[Gleb Natapov]

On Wed, Mar 09, 2011 at 08:51:23PM -0800, Jordan Justen wrote:
> Hi all,
> 
> I have documented a simple flash-like device which I think could be
> useful for qemu/kvm in some cases.  (Particularly for allowing
> persistent UEFI non-volatile variables.)
> 
> http://wiki.qemu.org/Features/System_Flash
> 
> Let me know if you have any suggestions or concerns.
> 

Two things. First You suggest to replace -bios with -flash. This will
make firmware upgrade painful process that will have to be performed
from inside the guest since the same flash image will contain both
firmware and whatever data was stored on a flash which presumably you
want to reuse after upgrading a firmware. My suggestion is to extend
-bios option like this:

-bios bios.bin,flash=flash.bin,flash_base=addr

flash.bin will be mapped at address flash_base, or, if flash_base is not
present, just below bios.bin.

Second. I asked how flash is programmed because interfaces like CFI
where you write into flash memory address range to issue commands cannot
be emulated efficiently in KVM. KVM supports either regular memory slots
or IO memory, but in your proposal the same memory behaves as IO on
write and regular memory on read. Better idea would be to present
non-volatile flash as ISA virtio device. Should be simple to implement.
 
--
			Gleb.

[Qemu-devel] Re: RFC: emulation of system flash

[Jan Kiszka]

On 2011-03-10 10:47, Gleb Natapov wrote:
> On Wed, Mar 09, 2011 at 08:51:23PM -0800, Jordan Justen wrote:
>> Hi all,
>>
>> I have documented a simple flash-like device which I think could be
>> useful for qemu/kvm in some cases.  (Particularly for allowing
>> persistent UEFI non-volatile variables.)
>>
>> http://wiki.qemu.org/Features/System_Flash
>>
>> Let me know if you have any suggestions or concerns.
>>
> 
> Two things. First You suggest to replace -bios with -flash. This will
> make firmware upgrade painful process that will have to be performed
> from inside the guest since the same flash image will contain both
> firmware and whatever data was stored on a flash which presumably you
> want to reuse after upgrading a firmware. My suggestion is to extend
> -bios option like this:
> 
> -bios bios.bin,flash=flash.bin,flash_base=addr
> 
> flash.bin will be mapped at address flash_base, or, if flash_base is not
> present, just below bios.bin.

...or define -flash in a way that allows mapping the bios image as an
overlay to the otherwise guest-managed flash image.

> 
> Second. I asked how flash is programmed because interfaces like CFI
> where you write into flash memory address range to issue commands cannot
> be emulated efficiently in KVM. KVM supports either regular memory slots
> or IO memory, but in your proposal the same memory behaves as IO on
> write and regular memory on read. Better idea would be to present
> non-volatile flash as ISA virtio device. Should be simple to implement.

Why not enhancing KVM memory slots to support direct read access while
writes are trapped and forwarded to a user space device model? Virtio
means that you have to patch the guest (which might be something else
than flexible Linux...).

Jan

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux

[Qemu-devel] Re: RFC: emulation of system flash

[Jan Kiszka]

On 2011-03-10 12:27, Jan Kiszka wrote:
> On 2011-03-10 10:47, Gleb Natapov wrote:
>> On Wed, Mar 09, 2011 at 08:51:23PM -0800, Jordan Justen wrote:
>>> Hi all,
>>>
>>> I have documented a simple flash-like device which I think could be
>>> useful for qemu/kvm in some cases.  (Particularly for allowing
>>> persistent UEFI non-volatile variables.)
>>>
>>> http://wiki.qemu.org/Features/System_Flash
>>>
>>> Let me know if you have any suggestions or concerns.
>>>
>>
>> Two things. First You suggest to replace -bios with -flash. This will
>> make firmware upgrade painful process that will have to be performed
>> from inside the guest since the same flash image will contain both
>> firmware and whatever data was stored on a flash which presumably you
>> want to reuse after upgrading a firmware. My suggestion is to extend
>> -bios option like this:
>>
>> -bios bios.bin,flash=flash.bin,flash_base=addr
>>
>> flash.bin will be mapped at address flash_base, or, if flash_base is not
>> present, just below bios.bin.
> 
> ...or define -flash in a way that allows mapping the bios image as an
> overlay to the otherwise guest-managed flash image.

Better define flash chips as qdev devices and make the attributes qdev
properties:

    -device flash,image=...,base=...,overlay=...,overlay_start=...

Images should be addressed by block device IDs and created via '-drive'
(likely requires a new interface type 'flash'). That way you could
define the bios overlay as "snapshot" so that the guest could happily
corrupt it, but restarting the VM would pick up a well-defined version
again.

Jan

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux

[Qemu-devel] Re: RFC: emulation of system flash

[Gleb Natapov]

On Thu, Mar 10, 2011 at 12:27:55PM +0100, Jan Kiszka wrote:
> On 2011-03-10 10:47, Gleb Natapov wrote:
> > On Wed, Mar 09, 2011 at 08:51:23PM -0800, Jordan Justen wrote:
> >> Hi all,
> >>
> >> I have documented a simple flash-like device which I think could be
> >> useful for qemu/kvm in some cases.  (Particularly for allowing
> >> persistent UEFI non-volatile variables.)
> >>
> >> http://wiki.qemu.org/Features/System_Flash
> >>
> >> Let me know if you have any suggestions or concerns.
> >>
> > 
> > Two things. First You suggest to replace -bios with -flash. This will
> > make firmware upgrade painful process that will have to be performed
> > from inside the guest since the same flash image will contain both
> > firmware and whatever data was stored on a flash which presumably you
> > want to reuse after upgrading a firmware. My suggestion is to extend
> > -bios option like this:
> > 
> > -bios bios.bin,flash=flash.bin,flash_base=addr
> > 
> > flash.bin will be mapped at address flash_base, or, if flash_base is not
> > present, just below bios.bin.
> 
> ...or define -flash in a way that allows mapping the bios image as an
> overlay to the otherwise guest-managed flash image.
> 
It is not much different from what I proposed. The result will be the
same. Even option syntax will probably be the same :)

> > 
> > Second. I asked how flash is programmed because interfaces like CFI
> > where you write into flash memory address range to issue commands cannot
> > be emulated efficiently in KVM. KVM supports either regular memory slots
> > or IO memory, but in your proposal the same memory behaves as IO on
> > write and regular memory on read. Better idea would be to present
> > non-volatile flash as ISA virtio device. Should be simple to implement.
> 
> Why not enhancing KVM memory slots to support direct read access while
> writes are trapped and forwarded to a user space device model?
Yes we can make memory slot that will be treated as memory on read and
IO on write, but first relying on that will prevent using flash interface
on older kernels and second it is not enough to implement the proposal.
When magic value is written into an address, the address become IO for
reading too, but KVM slot granularity is page, not byte, so KVM will
have to remove the slot to make it IO, but KVM can't execute code from
IO region (yet), so we will not be able to run firmware from flash and
simultaneously write into the flash. 

>                                                                 Virtio
> means that you have to patch the guest (which might be something else
> than flexible Linux...).
> 
This intended to be used by firmware only and we control that.

--
			Gleb.

[Qemu-devel] Re: RFC: emulation of system flash

[Paolo Bonzini]

On 03/10/2011 12:46 PM, Jan Kiszka wrote:
> Better define flash chips as qdev devices and make the attributes qdev
> properties:
>
>      -device flash,image=...,base=...,overlay=...,overlay_start=...
>
> Images should be addressed by block device IDs and created via '-drive'
> (likely requires a new interface type 'flash').

if=none will do.

Paolo

[Qemu-devel] Re: RFC: emulation of system flash

[Jan Kiszka]

On 2011-03-10 12:48, Gleb Natapov wrote:
> On Thu, Mar 10, 2011 at 12:27:55PM +0100, Jan Kiszka wrote:
>> On 2011-03-10 10:47, Gleb Natapov wrote:
>>> On Wed, Mar 09, 2011 at 08:51:23PM -0800, Jordan Justen wrote:
>>>> Hi all,
>>>>
>>>> I have documented a simple flash-like device which I think could be
>>>> useful for qemu/kvm in some cases.  (Particularly for allowing
>>>> persistent UEFI non-volatile variables.)
>>>>
>>>> http://wiki.qemu.org/Features/System_Flash
>>>>
>>>> Let me know if you have any suggestions or concerns.
>>>>
>>>
>>> Two things. First You suggest to replace -bios with -flash. This will
>>> make firmware upgrade painful process that will have to be performed
>>> from inside the guest since the same flash image will contain both
>>> firmware and whatever data was stored on a flash which presumably you
>>> want to reuse after upgrading a firmware. My suggestion is to extend
>>> -bios option like this:
>>>
>>> -bios bios.bin,flash=flash.bin,flash_base=addr
>>>
>>> flash.bin will be mapped at address flash_base, or, if flash_base is not
>>> present, just below bios.bin.
>>
>> ...or define -flash in a way that allows mapping the bios image as an
>> overlay to the otherwise guest-managed flash image.
>>
> It is not much different from what I proposed. The result will be the
> same. Even option syntax will probably be the same :)

-bios is PC-centric, the new command should be generic.

> 
>>>
>>> Second. I asked how flash is programmed because interfaces like CFI
>>> where you write into flash memory address range to issue commands cannot
>>> be emulated efficiently in KVM. KVM supports either regular memory slots
>>> or IO memory, but in your proposal the same memory behaves as IO on
>>> write and regular memory on read. Better idea would be to present
>>> non-volatile flash as ISA virtio device. Should be simple to implement.
>>
>> Why not enhancing KVM memory slots to support direct read access while
>> writes are trapped and forwarded to a user space device model?
> Yes we can make memory slot that will be treated as memory on read and
> IO on write, but first relying on that will prevent using flash interface
> on older kernels and second it is not enough to implement the proposal.
> When magic value is written into an address, the address become IO for
> reading too, but KVM slot granularity is page, not byte, so KVM will
> have to remove the slot to make it IO, but KVM can't execute code from
> IO region (yet), so we will not be able to run firmware from flash and
> simultaneously write into the flash. 

Yeah, right. I remember that this was also hairy over TCG if you tried
to optimize flash emulation so that writing doesn't take orders of
magnitude longer than on real HW.

BTW, the programming granularity is not bytes but chips with common CFI.
But that's still tricky if you want to run code from the same chip while
updating parts of it. The easiest workaround would be handling the
overlay regions as ROM all the time. Not accurate but realizable without
kernel changes.

> 
>>                                                                 Virtio
>> means that you have to patch the guest (which might be something else
>> than flexible Linux...).
>>
> This intended to be used by firmware only and we control that.

I'm thinking beyond this use case, beyond firmware flashes, beyond x86.

Jan

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux

[Qemu-devel] Re: RFC: emulation of system flash

[Jan Kiszka]

On 2011-03-10 12:53, Paolo Bonzini wrote:
> On 03/10/2011 12:46 PM, Jan Kiszka wrote:
>> Better define flash chips as qdev devices and make the attributes qdev
>> properties:
>>
>>      -device flash,image=...,base=...,overlay=...,overlay_start=...
>>
>> Images should be addressed by block device IDs and created via '-drive'
>> (likely requires a new interface type 'flash').
> 
> if=none will do.

Yeah, of course (already used for other host interfaces, if!=none is for
legacy use only).

Jan

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux

[Qemu-devel] Re: RFC: emulation of system flash

[Gleb Natapov]

On Thu, Mar 10, 2011 at 01:06:14PM +0100, Jan Kiszka wrote:
> On 2011-03-10 12:48, Gleb Natapov wrote:
> > On Thu, Mar 10, 2011 at 12:27:55PM +0100, Jan Kiszka wrote:
> >> On 2011-03-10 10:47, Gleb Natapov wrote:
> >>> On Wed, Mar 09, 2011 at 08:51:23PM -0800, Jordan Justen wrote:
> >>>> Hi all,
> >>>>
> >>>> I have documented a simple flash-like device which I think could be
> >>>> useful for qemu/kvm in some cases.  (Particularly for allowing
> >>>> persistent UEFI non-volatile variables.)
> >>>>
> >>>> http://wiki.qemu.org/Features/System_Flash
> >>>>
> >>>> Let me know if you have any suggestions or concerns.
> >>>>
> >>>
> >>> Two things. First You suggest to replace -bios with -flash. This will
> >>> make firmware upgrade painful process that will have to be performed
> >>> from inside the guest since the same flash image will contain both
> >>> firmware and whatever data was stored on a flash which presumably you
> >>> want to reuse after upgrading a firmware. My suggestion is to extend
> >>> -bios option like this:
> >>>
> >>> -bios bios.bin,flash=flash.bin,flash_base=addr
> >>>
> >>> flash.bin will be mapped at address flash_base, or, if flash_base is not
> >>> present, just below bios.bin.
> >>
> >> ...or define -flash in a way that allows mapping the bios image as an
> >> overlay to the otherwise guest-managed flash image.
> >>
> > It is not much different from what I proposed. The result will be the
> > same. Even option syntax will probably be the same :)
> 
> -bios is PC-centric, the new command should be generic.
> 
Well, I tried to reuse the option we already have instead of introducing
another one. -bios can be extended beyond PC and represent general
firmware specification. But I like the option you proposed in other
email too, so I am not going to defend this one.


> > 
> >>>
> >>> Second. I asked how flash is programmed because interfaces like CFI
> >>> where you write into flash memory address range to issue commands cannot
> >>> be emulated efficiently in KVM. KVM supports either regular memory slots
> >>> or IO memory, but in your proposal the same memory behaves as IO on
> >>> write and regular memory on read. Better idea would be to present
> >>> non-volatile flash as ISA virtio device. Should be simple to implement.
> >>
> >> Why not enhancing KVM memory slots to support direct read access while
> >> writes are trapped and forwarded to a user space device model?
> > Yes we can make memory slot that will be treated as memory on read and
> > IO on write, but first relying on that will prevent using flash interface
> > on older kernels and second it is not enough to implement the proposal.
> > When magic value is written into an address, the address become IO for
> > reading too, but KVM slot granularity is page, not byte, so KVM will
> > have to remove the slot to make it IO, but KVM can't execute code from
> > IO region (yet), so we will not be able to run firmware from flash and
> > simultaneously write into the flash. 
> 
> Yeah, right. I remember that this was also hairy over TCG if you tried
> to optimize flash emulation so that writing doesn't take orders of
> magnitude longer than on real HW.
> 
> BTW, the programming granularity is not bytes but chips with common CFI.
> But that's still tricky if you want to run code from the same chip while
> updating parts of it. The easiest workaround would be handling the
> overlay regions as ROM all the time. Not accurate but realizable without
> kernel changes.
> 
So flash will be always IO and overlay will be always ROM. This will
work, except BIOS upgrade from inside the guest will not be possible,
but since we do not support this today too it doesn't bother me to much.

> > 
> >>                                                                 Virtio
> >> means that you have to patch the guest (which might be something else
> >> than flexible Linux...).
> >>
> > This intended to be used by firmware only and we control that.
> 
> I'm thinking beyond this use case, beyond firmware flashes, beyond x86.
> 
OK, but since both interfaces (virtio and one proposed in the wiki) are PV
I fail to see the difference between them for any use case. If we
implement CFI then it will be another story.

--
			Gleb.

[Qemu-devel] Re: RFC: emulation of system flash

[Jan Kiszka]

On 2011-03-10 13:17, Gleb Natapov wrote:
> On Thu, Mar 10, 2011 at 01:06:14PM +0100, Jan Kiszka wrote:
>> On 2011-03-10 12:48, Gleb Natapov wrote:
>>> On Thu, Mar 10, 2011 at 12:27:55PM +0100, Jan Kiszka wrote:
>>>> On 2011-03-10 10:47, Gleb Natapov wrote:
>>>>> On Wed, Mar 09, 2011 at 08:51:23PM -0800, Jordan Justen wrote:
>>>>>> Hi all,
>>>>>>
>>>>>> I have documented a simple flash-like device which I think could be
>>>>>> useful for qemu/kvm in some cases.  (Particularly for allowing
>>>>>> persistent UEFI non-volatile variables.)
>>>>>>
>>>>>> http://wiki.qemu.org/Features/System_Flash
>>>>>>
>>>>>> Let me know if you have any suggestions or concerns.
>>>>>>
>>>>>
>>>>> Two things. First You suggest to replace -bios with -flash. This will
>>>>> make firmware upgrade painful process that will have to be performed
>>>>> from inside the guest since the same flash image will contain both
>>>>> firmware and whatever data was stored on a flash which presumably you
>>>>> want to reuse after upgrading a firmware. My suggestion is to extend
>>>>> -bios option like this:
>>>>>
>>>>> -bios bios.bin,flash=flash.bin,flash_base=addr
>>>>>
>>>>> flash.bin will be mapped at address flash_base, or, if flash_base is not
>>>>> present, just below bios.bin.
>>>>
>>>> ...or define -flash in a way that allows mapping the bios image as an
>>>> overlay to the otherwise guest-managed flash image.
>>>>
>>> It is not much different from what I proposed. The result will be the
>>> same. Even option syntax will probably be the same :)
>>
>> -bios is PC-centric, the new command should be generic.
>>
> Well, I tried to reuse the option we already have instead of introducing
> another one. -bios can be extended beyond PC and represent general
> firmware specification. But I like the option you proposed in other
> email too, so I am not going to defend this one.
> 
> 
>>>
>>>>>
>>>>> Second. I asked how flash is programmed because interfaces like CFI
>>>>> where you write into flash memory address range to issue commands cannot
>>>>> be emulated efficiently in KVM. KVM supports either regular memory slots
>>>>> or IO memory, but in your proposal the same memory behaves as IO on
>>>>> write and regular memory on read. Better idea would be to present
>>>>> non-volatile flash as ISA virtio device. Should be simple to implement.
>>>>
>>>> Why not enhancing KVM memory slots to support direct read access while
>>>> writes are trapped and forwarded to a user space device model?
>>> Yes we can make memory slot that will be treated as memory on read and
>>> IO on write, but first relying on that will prevent using flash interface
>>> on older kernels and second it is not enough to implement the proposal.
>>> When magic value is written into an address, the address become IO for
>>> reading too, but KVM slot granularity is page, not byte, so KVM will
>>> have to remove the slot to make it IO, but KVM can't execute code from
>>> IO region (yet), so we will not be able to run firmware from flash and
>>> simultaneously write into the flash. 
>>
>> Yeah, right. I remember that this was also hairy over TCG if you tried
>> to optimize flash emulation so that writing doesn't take orders of
>> magnitude longer than on real HW.
>>
>> BTW, the programming granularity is not bytes but chips with common CFI.
>> But that's still tricky if you want to run code from the same chip while
>> updating parts of it. The easiest workaround would be handling the
>> overlay regions as ROM all the time. Not accurate but realizable without
>> kernel changes.
>>
> So flash will be always IO and overlay will be always ROM. This will

Yes, and once we have KVM support for read-RAM/write-IO slots, flash
will be able to switch between ROM and IO mode just like it already does
under TCG.

> work, except BIOS upgrade from inside the guest will not be possible,
> but since we do not support this today too it doesn't bother me to much.
> 
>>>
>>>>                                                                 Virtio
>>>> means that you have to patch the guest (which might be something else
>>>> than flexible Linux...).
>>>>
>>> This intended to be used by firmware only and we control that.
>>
>> I'm thinking beyond this use case, beyond firmware flashes, beyond x86.
>>
> OK, but since both interfaces (virtio and one proposed in the wiki) are PV
> I fail to see the difference between them for any use case. If we
> implement CFI then it will be another story.

I'm proposing CFI (which already exists) with BIOS exception to avoid PV
as far as possible.

Jan

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux

[Qemu-devel] Re: RFC: emulation of system flash

[Jordan Justen]

On Thu, Mar 10, 2011 at 01:10, Avi Kivity <avi@redhat.com> wrote:
> On 03/10/2011 06:51 AM, Jordan Justen wrote:
>>
>> http://wiki.qemu.org/Features/System_Flash
>>
>
> - make the programming interface the same as an existing device

How strongly do you feel about this?

For one thing, real devices are not as flexible as QEMU for flash
sizes.  QEMU allows for any 64kb multiple bios size.  Real world
devices generally only support powers of 2 sizes.

Firmware hub devices are somewhat simplistic to emulate, but I think
they use 16MB of address space, while only providing <= 1MB of flash
storage.

SPI devices are available in many sizes, so it might be possible to
choose a 16MB device to emulate.  But, it would be a lot more complex
to emulate as it would it involve emulating an SPI contoller + the
device.

I thought this might be a case where deviation from real hardware
emulation could better serve the VM's needs.

-Jordan

[Qemu-devel] Re: RFC: emulation of system flash

[Jordan Justen]

On Thu, Mar 10, 2011 at 01:47, Gleb Natapov <gleb@redhat.com> wrote:
> Two things. First You suggest to replace -bios with -flash. This will
> make firmware upgrade painful process that will have to be performed
> from inside the guest since the same flash image will contain both
> firmware and whatever data was stored on a flash which presumably you
> want to reuse after upgrading a firmware.

Yes, this definitely could add firmware upgrade issues, but I thought
this could be the responsibility of the firmware itself.  For example,
OVMF could have an outside of VM tool to merge new releases, or it
could have an inside of VM firmware update process.

> My suggestion is to extend
> -bios option like this:
>
> -bios bios.bin,flash=flash.bin,flash_base=addr
>
> flash.bin will be mapped at address flash_base, or, if flash_base is not
> present, just below bios.bin.

I did not intend to replace -bios.  I intended to override -bios
usage.  So, if -flash is not used, then it would operate as today.  If
-flash is used, then it would override the -bios file.

So, for the firmware update issues mentioned above, it would not
impact, say SeaBIOS...

> Second. I asked how flash is programmed because interfaces like CFI
> where you write into flash memory address range to issue commands cannot
> be emulated efficiently in KVM. KVM supports either regular memory slots
> or IO memory, but in your proposal the same memory behaves as IO on
> write and regular memory on read. Better idea would be to present
> non-volatile flash as ISA virtio device. Should be simple to implement.

I would be concerned about performance for KVM.  In my proposal, all
reads would probably have to be treated as MMIO, since reads are
involved in the programming sequences.

If the flash device was 1MB, and it was read entirely via MMIO
trapping would there be a significant performance hit on KVM?  If so,
I think I will have to consider a hybrid approach like you mentioned
above, where most of the firmware is mapped as memory (copied from
bios.bin), while a small amount of memory below this is available as
flash.

But, in real systems, accessing the flash memory is significantly
slower than RAM, so the real question is, how bad would the
performance be?

Thanks,

-Jordan

[Qemu-devel] Re: RFC: emulation of system flash

[Jordan Justen]

On Thu, Mar 10, 2011 at 03:46, Jan Kiszka <jan.kiszka@siemens.com> wrote:
> On 2011-03-10 12:27, Jan Kiszka wrote:
>> On 2011-03-10 10:47, Gleb Natapov wrote:
>>> My suggestion is to extend
>>> -bios option like this:
>>>
>>> -bios bios.bin,flash=flash.bin,flash_base=addr
>>>
>>> flash.bin will be mapped at address flash_base, or, if flash_base is not
>>> present, just below bios.bin.
>>
>> ...or define -flash in a way that allows mapping the bios image as an
>> overlay to the otherwise guest-managed flash image.
>
> Better define flash chips as qdev devices and make the attributes qdev
> properties:
>
>    -device flash,image=...,base=...,overlay=...,overlay_start=...

I was hoping it would not necessarily require a script to run OVMF. :)

The original proposal would have allowed for:

qemu -L . -flash ovmf.fd

-Jordan

[Qemu-devel] Re: RFC: emulation of system flash

[Jordan Justen]

On Thu, Mar 10, 2011 at 04:27, Jan Kiszka <jan.kiszka@siemens.com> wrote:
> On 2011-03-10 13:17, Gleb Natapov wrote:
>> So flash will be always IO and overlay will be always ROM. This will
>
> Yes, and once we have KVM support for read-RAM/write-IO slots, flash
> will be able to switch between ROM and IO mode just like it already does
> under TCG.

Interesting.  Will this allow the read-RAM to be converted to read-IO
if a write-IO triggers it?  And, then reverted to read-RAM again...

Thanks,

-Jordan

[Qemu-devel] Re: RFC: emulation of system flash

[Gleb Natapov]

On Thu, Mar 10, 2011 at 10:59:07AM -0800, Jordan Justen wrote:
> On Thu, Mar 10, 2011 at 01:47, Gleb Natapov <gleb@redhat.com> wrote:
> > Two things. First You suggest to replace -bios with -flash. This will
> > make firmware upgrade painful process that will have to be performed
> > from inside the guest since the same flash image will contain both
> > firmware and whatever data was stored on a flash which presumably you
> > want to reuse after upgrading a firmware.
> 
> Yes, this definitely could add firmware upgrade issues, but I thought
> this could be the responsibility of the firmware itself.  For example,
> OVMF could have an outside of VM tool to merge new releases, or it
> could have an inside of VM firmware update process.
Why require another tool if can do without? I don't see any advantages
in storing firmware code and its non-volatile storage in the same image,
but I do see disadvantages.

> 
> > My suggestion is to extend
> > -bios option like this:
> >
> > -bios bios.bin,flash=flash.bin,flash_base=addr
> >
> > flash.bin will be mapped at address flash_base, or, if flash_base is not
> > present, just below bios.bin.
> 
> I did not intend to replace -bios.  I intended to override -bios
> usage.  So, if -flash is not used, then it would operate as today.  If
> -flash is used, then it would override the -bios file.
> 
> So, for the firmware update issues mentioned above, it would not
> impact, say SeaBIOS...
> 
OVMF is not different from SeaBIOS as far as KVM/qemu is concerned. SeaBIOS
want to have non-volatile storage too.

> > Second. I asked how flash is programmed because interfaces like CFI
> > where you write into flash memory address range to issue commands cannot
> > be emulated efficiently in KVM. KVM supports either regular memory slots
> > or IO memory, but in your proposal the same memory behaves as IO on
> > write and regular memory on read. Better idea would be to present
> > non-volatile flash as ISA virtio device. Should be simple to implement.
> 
> I would be concerned about performance for KVM.  In my proposal, all
> reads would probably have to be treated as MMIO, since reads are
> involved in the programming sequences.
> 
> If the flash device was 1MB, and it was read entirely via MMIO
> trapping would there be a significant performance hit on KVM?  If so,
> I think I will have to consider a hybrid approach like you mentioned
> above, where most of the firmware is mapped as memory (copied from
> bios.bin), while a small amount of memory below this is available as
> flash.
> 
It is not even about performance (which will be very bad for 1MB). KVM
can't run code from MMIO region, so the part that contains firmware
has to be memory.

> But, in real systems, accessing the flash memory is significantly
> slower than RAM, so the real question is, how bad would the
> performance be?
> 
> Thanks,
> 
> -Jordan

--
			Gleb.

[Qemu-devel] Re: RFC: emulation of system flash

[Gleb Natapov]

On Thu, Mar 10, 2011 at 11:08:32AM -0800, Jordan Justen wrote:
> On Thu, Mar 10, 2011 at 04:27, Jan Kiszka <jan.kiszka@siemens.com> wrote:
> > On 2011-03-10 13:17, Gleb Natapov wrote:
> >> So flash will be always IO and overlay will be always ROM. This will
> >
> > Yes, and once we have KVM support for read-RAM/write-IO slots, flash
> > will be able to switch between ROM and IO mode just like it already does
> > under TCG.
> 
> Interesting.  Will this allow the read-RAM to be converted to read-IO
> if a write-IO triggers it?  And, then reverted to read-RAM again...
> 
Yes.

--
			Gleb.

Re: [Qemu-devel] Re: RFC: emulation of system flash

[Anthony Liguori]

On 03/10/2011 01:03 PM, Jordan Justen wrote:
> On Thu, Mar 10, 2011 at 03:46, Jan Kiszka<jan.kiszka@siemens.com>  wrote:
>> On 2011-03-10 12:27, Jan Kiszka wrote:
>>> On 2011-03-10 10:47, Gleb Natapov wrote:
>>>> My suggestion is to extend
>>>> -bios option like this:
>>>>
>>>> -bios bios.bin,flash=flash.bin,flash_base=addr
>>>>
>>>> flash.bin will be mapped at address flash_base, or, if flash_base is not
>>>> present, just below bios.bin.
>>> ...or define -flash in a way that allows mapping the bios image as an
>>> overlay to the otherwise guest-managed flash image.
>> Better define flash chips as qdev devices and make the attributes qdev
>> properties:
>>
>>     -device flash,image=...,base=...,overlay=...,overlay_start=...
> I was hoping it would not necessarily require a script to run OVMF. :)
>
> The original proposal would have allowed for:
>
> qemu -L . -flash ovmf.fd

If you implement a CSM for Tiano Core, then you won't need to use any 
special parameters because we can just use OVMF by default ;-)

Regards,

Anthony Liguori

> -Jordan
>

[Qemu-devel] Re: RFC: emulation of system flash

[Jordan Justen]

On Thu, Mar 10, 2011 at 11:12, Gleb Natapov <gleb@redhat.com> wrote:
> On Thu, Mar 10, 2011 at 10:59:07AM -0800, Jordan Justen wrote:
>> Yes, this definitely could add firmware upgrade issues, but I thought
>> this could be the responsibility of the firmware itself.  For example,
>> OVMF could have an outside of VM tool to merge new releases, or it
>> could have an inside of VM firmware update process.
> Why require another tool if can do without? I don't see any advantages
> in storing firmware code and its non-volatile storage in the same image,
> but I do see disadvantages.

I agree.  The implications of a firmware image getting out of sync
with qemu were a bit of a concern to me.  But, having both -bios +
-flash just below -bios was starting to seem a bit complicated.

And, I guess as a firmware developer, I thought it might be
interesting to consider enabling a firmware update process within the
VM. :)

How about?
1) Pure rom:
-bios bios.bin
2) Rom + flash below rom:
-bios bios.bin,flash=flash.bin
3) Pure flash:
-bios flash=flash.bin

Or, with a separate new -flash option:
1) Pure rom:
-bios bios.bin
or no -bios or -flash parameters
2) Rom + flash below rom:
-bios bios.bin -flash flash.bin
3) Pure flash:
-flash flash.bin

> It is not even about performance (which will be very bad for 1MB). KVM
> can't run code from MMIO region, so the part that contains firmware
> has to be memory.

Hmm.  That's good to know. :)

So, perhaps this feature should build upon the other feature you and
Jan are discussing.  When will it become available?

Thanks,

-Jordan

Re: [Qemu-devel] Re: RFC: emulation of system flash

[Jordan Justen]

On Thu, Mar 10, 2011 at 11:23, Anthony Liguori <anthony@codemonkey.ws> wrote:
> If you implement a CSM for Tiano Core, then you won't need to use any
> special parameters because we can just use OVMF by default ;-)

Sorry, but I can't do this.  This is unlikely to change anytime soon.

But, if someone seeks to put forth a serious effort around a CSM (or
most anything UEFI or edk2 related), then they ought to be able to
expect support from our tianocore community (which includes me).

If our tianocore community had an open source CSM available, I should
be able to include it in OVMF.  A BSD licensed CSM would be much
easier for OVMF to integrate directly, but any open-source CSM would
allow for the possibility of an OVMF fork with the CSM included.

-Jordan

Re: [Qemu-devel] Re: RFC: emulation of system flash

[Антон Кочков]

As I'm working on bootrom loading support for omap/arm platform, I'm
have suggestion about something more universal than -bios (and even
-flash) option. Because Flash can be NOR, can be NAND, but on-chip
memory is not flash memory. So may be something like -rom option?

Best regards,
Anton Kochkov.




On Thu, Mar 10, 2011 at 22:50, Jordan Justen <jljusten@gmail.com> wrote:
> On Thu, Mar 10, 2011 at 11:12, Gleb Natapov <gleb@redhat.com> wrote:
>> On Thu, Mar 10, 2011 at 10:59:07AM -0800, Jordan Justen wrote:
>>> Yes, this definitely could add firmware upgrade issues, but I thought
>>> this could be the responsibility of the firmware itself.  For example,
>>> OVMF could have an outside of VM tool to merge new releases, or it
>>> could have an inside of VM firmware update process.
>> Why require another tool if can do without? I don't see any advantages
>> in storing firmware code and its non-volatile storage in the same image,
>> but I do see disadvantages.
>
> I agree.  The implications of a firmware image getting out of sync
> with qemu were a bit of a concern to me.  But, having both -bios +
> -flash just below -bios was starting to seem a bit complicated.
>
> And, I guess as a firmware developer, I thought it might be
> interesting to consider enabling a firmware update process within the
> VM. :)
>
> How about?
> 1) Pure rom:
> -bios bios.bin
> 2) Rom + flash below rom:
> -bios bios.bin,flash=flash.bin
> 3) Pure flash:
> -bios flash=flash.bin
>
> Or, with a separate new -flash option:
> 1) Pure rom:
> -bios bios.bin
> or no -bios or -flash parameters
> 2) Rom + flash below rom:
> -bios bios.bin -flash flash.bin
> 3) Pure flash:
> -flash flash.bin
>
>> It is not even about performance (which will be very bad for 1MB). KVM
>> can't run code from MMIO region, so the part that contains firmware
>> has to be memory.
>
> Hmm.  That's good to know. :)
>
> So, perhaps this feature should build upon the other feature you and
> Jan are discussing.  When will it become available?
>
> Thanks,
>
> -Jordan
>
>

[Qemu-devel] Re: RFC: emulation of system flash

[Gleb Natapov]

On Thu, Mar 10, 2011 at 11:50:42AM -0800, Jordan Justen wrote:
> > It is not even about performance (which will be very bad for 1MB). KVM
> > can't run code from MMIO region, so the part that contains firmware
> > has to be memory.
> 
> Hmm.  That's good to know. :)
> 
> So, perhaps this feature should build upon the other feature you and
> Jan are discussing.  When will it become available?
> 
When somebody will be motivated enough to send patches. If this was the
only thing that stands in a way of QEMU having EFI firmware with CSM
support it would have happened much faster though.

--
			Gleb.

Re: [Qemu-devel] RFC: emulation of system flash

[Carl-Daniel Hailfinger]

Hi,

as the lead developer of the open source flashrom utility
<http://www.flashrom.org/> I have to say that it would be nice to have
Qemu emulate a flash chip. Right now flashrom is using its own flash
chip emulator for testing, and being able to use flashrom in Qemu would
be a nice addition.

Auf 10.03.2011 05:51, Jordan Justen schrieb:
> I have documented a simple flash-like device which I think could be
> useful for qemu/kvm in some cases.  (Particularly for allowing
> persistent UEFI non-volatile variables.)
>
> http://wiki.qemu.org/Features/System_Flash
>
> Let me know if you have any suggestions or concerns.
>   

Is there any reason why you chose to invent an interface for the flash
chip which is more complicated than the interface used by common flash
chips out there?
Maybe some EFI requirement?

Regards,
Carl-Daniel

Re: [Qemu-devel] Re: RFC: emulation of system flash

[Carl-Daniel Hailfinger]

Auf 10.03.2011 12:48, Gleb Natapov schrieb:
> On Thu, Mar 10, 2011 at 12:27:55PM +0100, Jan Kiszka wrote:
>   
>> On 2011-03-10 10:47, Gleb Natapov wrote:
>>     
>>> Second. I asked how flash is programmed because interfaces like CFI
>>> where you write into flash memory address range to issue commands cannot
>>> be emulated efficiently in KVM. KVM supports either regular memory slots
>>> or IO memory, but in your proposal the same memory behaves as IO on
>>> write and regular memory on read. Better idea would be to present
>>> non-volatile flash as ISA virtio device. Should be simple to implement.
>>>       
>> Why not enhancing KVM memory slots to support direct read access while
>> writes are trapped and forwarded to a user space device model?
>>     
> Yes we can make memory slot that will be treated as memory on read and
> IO on write, but first relying on that will prevent using flash interface
> on older kernels and second it is not enough to implement the proposal.
> When magic value is written into an address, the address become IO for
> reading too, but KVM slot granularity is page, not byte, so KVM will
> have to remove the slot to make it IO, but KVM can't execute code from
> IO region (yet), so we will not be able to run firmware from flash and
> simultaneously write into the flash.
>   

If you have a Parallel/LPC/FWH flash chip in your mainboard, it is
technically impossible to execute code from flash while you are writing
to _any_ part of the flash chip because every single read from the flash
chip during an active write will toggle one bit of the read data.
So if your code already runs on real x86, you will never hit that problem.

(SPI flash is an exception, but it uses out-of-band access anyway,
usually via some southbridge interface, and that means the IO vs.
execution conflict won't happen there either.)

Regards,
Carl-Daniel

-- 
http://www.hailfinger.org/

Re: [Qemu-devel] Re: RFC: emulation of system flash

[Carl-Daniel Hailfinger]

Auf 10.03.2011 13:06, Jan Kiszka schrieb:
> BTW, the programming granularity is not bytes but chips with common CFI.
> But that's still tricky if you want to run code from the same chip while
> updating parts of it. The easiest workaround would be handling the
> overlay regions as ROM all the time. Not accurate but realizable without
> kernel changes.
>   

I've yet to see CFI chips on x86.


>> On Thu, Mar 10, 2011 at 12:27:55PM +0100, Jan Kiszka wrote:
>>     
>>> Virtio
>>> means that you have to patch the guest (which might be something else
>>> than flexible Linux...).
>>>
>>>       
>> This intended to be used by firmware only and we control that.
>>     
> I'm thinking beyond this use case, beyond firmware flashes, beyond x86.
>   

If you're thinking beyond x86, most flash is probably using SPI nowadays
because the reduced PCB footprint can save lots of money. And for SPI
you only need OOB access for write and the memory region itself is readonly.

Regards,
Carl-Daniel

-- 
http://www.hailfinger.org/

Re: [Qemu-devel] Re: RFC: emulation of system flash

[Carl-Daniel Hailfinger]

Auf 10.03.2011 19:43, Jordan Justen schrieb:
> On Thu, Mar 10, 2011 at 01:10, Avi Kivity <avi@redhat.com> wrote:
>   
>> On 03/10/2011 06:51 AM, Jordan Justen wrote:
>>     
>>> http://wiki.qemu.org/Features/System_Flash
>>>
>>>       
>> - make the programming interface the same as an existing device
>>     
> How strongly do you feel about this?
>
> For one thing, real devices are not as flexible as QEMU for flash
> sizes.  QEMU allows for any 64kb multiple bios size.  Real world
> devices generally only support powers of 2 sizes.
>
> Firmware hub devices are somewhat simplistic to emulate, but I think
> they use 16MB of address space, while only providing <= 1MB of flash
> storage.
>   

Up to 4 MB on real hardware, and if you use Parallel flash devices,
there is no limit at all (except cost). The software interface is
identical for read/write/erase/probe.


> SPI devices are available in many sizes, so it might be possible to
> choose a 16MB device to emulate.  But, it would be a lot more complex
> to emulate as it would it involve emulating an SPI contoller + the
> device.
>   

I have written a SPI flash chip emulator (it emulates 3 different
real-world SPI flash chips) and am willing to contribute it to Qemu if
there is interest. The code is pretty small, and adding a SPI host
controller emulator should be a few lines of code extra. Not a big problem.


> I thought this might be a case where deviation from real hardware
> emulation could better serve the VM's needs.
>   

If we have to write the code anyway, and if it can work just fine with
current KVM/Qemu, is there a reason not to use the same interface as
real hardware?

Regards,
Carl-Daniel

-- 
http://www.hailfinger.org/

Re: [Qemu-devel] RFC: emulation of system flash

[Jordan Justen]

On Thu, Mar 10, 2011 at 13:37, Carl-Daniel Hailfinger
<c-d.hailfinger.devel.2006@gmx.net> wrote:
> Auf 10.03.2011 05:51, Jordan Justen schrieb:
>> I have documented a simple flash-like device which I think could be
>> useful for qemu/kvm in some cases.  (Particularly for allowing
>> persistent UEFI non-volatile variables.)
>>
>> http://wiki.qemu.org/Features/System_Flash
>>
>> Let me know if you have any suggestions or concerns.
>>
>
> Is there any reason why you chose to invent an interface for the flash
> chip which is more complicated than the interface used by common flash
> chips out there?
> Maybe some EFI requirement?

This is a simpler version than the flash devices I'm used to dealing
with for x86/x86-64 UEFI systems.  Can you suggest an alternative real
interface that is simpler?

Thanks,

-Jordan

Re: [Qemu-devel] Re: RFC: emulation of system flash

[Jordan Justen]

On Thu, Mar 10, 2011 at 13:41, Carl-Daniel Hailfinger
<c-d.hailfinger.devel.2006@gmx.net> wrote:
> Auf 10.03.2011 12:48, Gleb Natapov schrieb:
>> Yes we can make memory slot that will be treated as memory on read and
>> IO on write, but first relying on that will prevent using flash interface
>> on older kernels and second it is not enough to implement the proposal.
>> When magic value is written into an address, the address become IO for
>> reading too, but KVM slot granularity is page, not byte, so KVM will
>> have to remove the slot to make it IO, but KVM can't execute code from
>> IO region (yet), so we will not be able to run firmware from flash and
>> simultaneously write into the flash.
>>
>
> If you have a Parallel/LPC/FWH flash chip in your mainboard, it is
> technically impossible to execute code from flash while you are writing
> to _any_ part of the flash chip because every single read from the flash
> chip during an active write will toggle one bit of the read data.
> So if your code already runs on real x86, you will never hit that problem.
>
> (SPI flash is an exception, but it uses out-of-band access anyway,
> usually via some southbridge interface, and that means the IO vs.
> execution conflict won't happen there either.)

I've not seen a firmware that attempts to update flash while also
executing from flash.  For OVMF or UEFI, I don't would not think this
should be a requirement.  (Although, my proposal would support this.)

-Jordan

Re: [Qemu-devel] RFC: emulation of system flash

[Carl-Daniel Hailfinger]

Auf 10.03.2011 22:55, Jordan Justen schrieb:
> On Thu, Mar 10, 2011 at 13:37, Carl-Daniel Hailfinger
> <c-d.hailfinger.devel.2006@gmx.net> wrote:
>   
>> Auf 10.03.2011 05:51, Jordan Justen schrieb:
>>     
>>> I have documented a simple flash-like device which I think could be
>>> useful for qemu/kvm in some cases.  (Particularly for allowing
>>> persistent UEFI non-volatile variables.)
>>>
>>> http://wiki.qemu.org/Features/System_Flash
>>>
>>> Let me know if you have any suggestions or concerns.
>>>
>>>       
>> Is there any reason why you chose to invent an interface for the flash
>> chip which is more complicated than the interface used by common flash
>> chips out there?
>> Maybe some EFI requirement?
>>     
> This is a simpler version than the flash devices I'm used to dealing
> with for x86/x86-64 UEFI systems.  Can you suggest an alternative real
> interface that is simpler?
>   

Pseudocode for the real interface most common on x86 before SPI came along:

Write a page (256 bytes) or a few bytes:
chip_writeb(0xAA, bios_base + 0x5555);
chip_writeb(0x55, bios_base + 0x2AAA);
chip_writeb(0xA0, bios_base + 0x5555);
chip_writeb(databyte0, bios_base + addr);
chip_writeb(databyte1, bios_base + addr + 1);
chip_writeb(databyte2, bios_base + addr + 2);
chip_writeb(databyte3, bios_base + addr + 3);
... up to 256 databytes.
chip_readb(bios_base);
The last chip_readb(bios_base) is repeated until the result does not
change anymore.

For me, that looks pretty simple and straightforward, especially
compared to other more exotic flash chip interfaces.

Regards,
Carl-Daniel

-- 
http://www.hailfinger.org/

Re: [Qemu-devel] Re: RFC: emulation of system flash

[Scott Wood]

On Thu, 10 Mar 2011 22:46:34 +0100
Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net> wrote:

> Auf 10.03.2011 13:06, Jan Kiszka schrieb:
> > I'm thinking beyond this use case, beyond firmware flashes, beyond x86.
> >   
> 
> If you're thinking beyond x86, most flash is probably using SPI nowadays
> because the reduced PCB footprint can save lots of money. And for SPI
> you only need OOB access for write and the memory region itself is readonly.

CFI still seems pretty dominant, at least in evaluation boards, which seem
more likely to be a qemu target than custom hardware.

-Scott

Re: [Qemu-devel] Re: RFC: emulation of system flash

[Jordan Justen]

On Thu, Mar 10, 2011 at 13:52, Carl-Daniel Hailfinger
<c-d.hailfinger.devel.2006@gmx.net> wrote:
> Auf 10.03.2011 19:43, Jordan Justen schrieb:
>> I thought this might be a case where deviation from real hardware
>> emulation could better serve the VM's needs.
>>
>
> If we have to write the code anyway, and if it can work just fine with
> current KVM/Qemu, is there a reason not to use the same interface as
> real hardware?

If there was a real device emulated by qemu, I would gladly make use
of it in OVMF.

I just thought this proposal would be much easier to implement, and
not be restricted to any particular size.  (Since -bios currently
supports any size that is a multiple of 64kb.)  A real device is going
to imply a certain size.

-Jordan

Re: [Qemu-devel] RFC: emulation of system flash

[Jordan Justen]

On Thu, Mar 10, 2011 at 14:10, Carl-Daniel Hailfinger
<c-d.hailfinger.devel.2006@gmx.net> wrote:
> Auf 10.03.2011 22:55, Jordan Justen schrieb:
>> On Thu, Mar 10, 2011 at 13:37, Carl-Daniel Hailfinger
>> <c-d.hailfinger.devel.2006@gmx.net> wrote:
>>> Is there any reason why you chose to invent an interface for the flash
>>> chip which is more complicated than the interface used by common flash
>>> chips out there?
>>> Maybe some EFI requirement?
>>>
>> This is a simpler version than the flash devices I'm used to dealing
>> with for x86/x86-64 UEFI systems.  Can you suggest an alternative real
>> interface that is simpler?
>>
>
> Pseudocode for the real interface most common on x86 before SPI came along:
>
> Write a page (256 bytes) or a few bytes:
> chip_writeb(0xAA, bios_base + 0x5555);
> chip_writeb(0x55, bios_base + 0x2AAA);
> chip_writeb(0xA0, bios_base + 0x5555);
> chip_writeb(databyte0, bios_base + addr);
> chip_writeb(databyte1, bios_base + addr + 1);
> chip_writeb(databyte2, bios_base + addr + 2);
> chip_writeb(databyte3, bios_base + addr + 3);
> ... up to 256 databytes.
> chip_readb(bios_base);
> The last chip_readb(bios_base) is repeated until the result does not
> change anymore.
>
> For me, that looks pretty simple and straightforward, especially
> compared to other more exotic flash chip interfaces.

I disagree that you think my proposal is more complicated than this example.

But, I would agree, that all other things being equal, emulating a
real device would be preferable.

I would like to know what people's thoughts are regarding supporting
various devices sizes.  I think that right now -bios should support
files sizes that are multiples of 64kb up to ~16MB.  (Perhaps even
larger.)

A large -bios file can be interesting for embedding an OS image into
the rom/flash device...

Carl-Daniel, do you think we can address this while still supporting
real hardware emulation?

-Jordan

Re: [Qemu-devel] Re: RFC: emulation of system flash

[Carl-Daniel Hailfinger]

Auf 10.03.2011 23:14, Jordan Justen schrieb:
> On Thu, Mar 10, 2011 at 13:52, Carl-Daniel Hailfinger
> <c-d.hailfinger.devel.2006@gmx.net> wrote:
>   
>> Auf 10.03.2011 19:43, Jordan Justen schrieb:
>>     
>>> I thought this might be a case where deviation from real hardware
>>> emulation could better serve the VM's needs.
>>>       
>> If we have to write the code anyway, and if it can work just fine with
>> current KVM/Qemu, is there a reason not to use the same interface as
>> real hardware?
>>     
> If there was a real device emulated by qemu, I would gladly make use
> of it in OVMF.
>   

Nice. So should I dig up my flash emulator code and check which chips
are supported? Porting the code to Qemu shouldn't be too hard.


> I just thought this proposal would be much easier to implement, and
> not be restricted to any particular size.  (Since -bios currently
> supports any size that is a multiple of 64kb.)  A real device is going
> to imply a certain size.
>   

Right, the constant size argument is definitely a point we need to talk
about.

We could sidestep the issue by always using a 16 MByte flash device
which gets filled from the top with the firmware image, but I'm not sure
if that has other side effects.
Another way to solve this would be to emulate multiple flash chips, one
per power-of-two size between 128 kB and 16 MB. Some SPI flash chip
families encode the size into their ID, so determining the size
algorithmically is as simple as calculating
1 << idbyte3
and emulating this is equally simple.


Regards,
Carl-Daniel

-- 
http://www.hailfinger.org/

Re: [Qemu-devel] Re: RFC: emulation of system flash

[Jordan Justen]

On Thu, Mar 10, 2011 at 14:31, Carl-Daniel Hailfinger
<c-d.hailfinger.devel.2006@gmx.net> wrote:
> Right, the constant size argument is definitely a point we need to talk
> about.
>
> We could sidestep the issue by always using a 16 MByte flash device
> which gets filled from the top with the firmware image, but I'm not sure
> if that has other side effects.
> Another way to solve this would be to emulate multiple flash chips, one
> per power-of-two size between 128 kB and 16 MB. Some SPI flash chip
> families encode the size into their ID, so determining the size
> algorithmically is as simple as calculating
> 1 << idbyte3
> and emulating this is equally simple.

Power of 2 from 128kb to 16MB sounds reasonable to me.

How would the SPI host controller be discovered?  Would the firmware
be able to depend on having control of the device at OS runtime?  This
would be needed for UEFI non-volatile variables to make sure they can
always be written.

Thanks,

-Jordan

Re: [Qemu-devel] Re: RFC: emulation of system flash

[Carl-Daniel Hailfinger]

Auf 10.03.2011 23:58, Jordan Justen schrieb:
> On Thu, Mar 10, 2011 at 14:31, Carl-Daniel Hailfinger
> <c-d.hailfinger.devel.2006@gmx.net> wrote:
>   
>> Right, the constant size argument is definitely a point we need to talk
>> about.
>>
>> We could sidestep the issue by always using a 16 MByte flash device
>> which gets filled from the top with the firmware image, but I'm not sure
>> if that has other side effects.
>> Another way to solve this would be to emulate multiple flash chips, one
>> per power-of-two size between 128 kB and 16 MB. Some SPI flash chip
>> families encode the size into their ID, so determining the size
>> algorithmically is as simple as calculating
>> 1 << idbyte3
>> and emulating this is equally simple.
>>     
> Power of 2 from 128kb to 16MB sounds reasonable to me.
>
> How would the SPI host controller be discovered?

PCI ID of the ISA bridge of the chipset. AFAIK most flashing programs
out there use that criterion. There is one drawback, though: We should
use an interface which works well for all emulated chipsets in Qemu, and
that may a bit harder.
Is there a way to get PCI IDs of all emulated chipsets in Qemu so I can
take a look if there is a chance to to this correctly?



> Would the firmware
> be able to depend on having control of the device at OS runtime?  This
> would be needed for UEFI non-volatile variables to make sure they can
> always be written.
>   

UEFI _should not_ have control of the device at OS runtime on real
hardware for security reasons, unless UEFI slipped a rootkit into the
OS. Not sure about Windows, but I'm pretty sure Linux will not run any
UEFI code (except maybe during early init).

Think flash update. If some flash update software runs under your OS of
choice, and UEFI is allowed to perform read/write accesses to flash at
the same time, you will get random corruption. You could do it like some
AMD chipsets, and provide some sort of semaphore for flash access
coordination between a flash updater and the BIOS/EFI, but I don't think
any Intel chipset can do that. Newer Intel chipsets allow locking out
flash accesses not coming from the management engine, but UEFI does not
run in the management engine, so that feature won't help us here.

That said, if any OS out there indeed runs UEFI code regularly during OS
runtime, and that UEFI code wants to access flash, it has to hope that
nobody else is trying to access flash at the same time. An easy way out
would be to use the ACPI NVS region while the machine is running an OS,
but changes would not automatically be persistent without help from the
OS or some ACPI handler on shutdown.


Regards,
Carl-Daniel

-- 
http://www.hailfinger.org/

Re: [Qemu-devel] RFC: emulation of system flash

[Carl-Daniel Hailfinger]

Hi Jordan,

thanks for your insights.

Auf 10.03.2011 23:29, Jordan Justen schrieb:
> On Thu, Mar 10, 2011 at 14:10, Carl-Daniel Hailfinger
> <c-d.hailfinger.devel.2006@gmx.net> wrote:
>   
>> Auf 10.03.2011 22:55, Jordan Justen schrieb:
>>     
>>> On Thu, Mar 10, 2011 at 13:37, Carl-Daniel Hailfinger
>>> <c-d.hailfinger.devel.2006@gmx.net> wrote:
>>>       
>>>> Is there any reason why you chose to invent an interface for the flash
>>>> chip which is more complicated than the interface used by common flash
>>>> chips out there?
>>>> Maybe some EFI requirement?
>>>>         
>>> This is a simpler version than the flash devices I'm used to dealing
>>> with for x86/x86-64 UEFI systems.  Can you suggest an alternative real
>>> interface that is simpler?
>>>       
>> Pseudocode for the real interface most common on x86 before SPI came along:
>>
>> Write a page (256 bytes) or a few bytes:
>> chip_writeb(0xAA, bios_base + 0x5555);
>> chip_writeb(0x55, bios_base + 0x2AAA);
>> chip_writeb(0xA0, bios_base + 0x5555);
>> chip_writeb(databyte0, bios_base + addr);
>> chip_writeb(databyte1, bios_base + addr + 1);
>> chip_writeb(databyte2, bios_base + addr + 2);
>> chip_writeb(databyte3, bios_base + addr + 3);
>> ... up to 256 databytes.
>> chip_readb(bios_base);
>> The last chip_readb(bios_base) is repeated until the result does not
>> change anymore.
>>
>> For me, that looks pretty simple and straightforward, especially
>> compared to other more exotic flash chip interfaces.
>>     
> I disagree that you think my proposal is more complicated than this example.
>   

Upon rereading your proposal, I think the unfamiliarity of the proposed
interface and the index/data design triggered my "complicated" reflex.


> But, I would agree, that all other things being equal, emulating a
> real device would be preferable.
>
> I would like to know what people's thoughts are regarding supporting
> various devices sizes.  I think that right now -bios should support
> files sizes that are multiples of 64kb up to ~16MB.  (Perhaps even
> larger.)
>   

On recent Intel chipsets you are limited to 16 MB mapped to the top of
the 32bit address space. The same limitation exists for most other x86
chipsets as well. That said, some people may want bigger images, but for
x86 this may cause conflicts with the HPET region.


> A large -bios file can be interesting for embedding an OS image into
> the rom/flash device...
>   

I've seen people embed coreboot+Linux+X.org into a 4 MB image on x86, so
I think 16 MB are plenty (flash bigger than that is either NAND or
expensive or slow, and would require significant effort to emulate
correctly (NAND) or simply not exist in consumer equipment for
speed/money reasons).


> Carl-Daniel, do you think we can address this while still supporting
> real hardware emulation?
>   

If we restrict ourselves to the 128kB-16MB range, I think I can find a
flash chip family which has the criteria we want. 64 kByte flash chips
still exist, but usually not as part of a family which reaches 16 MByte.

We should decide first if we want SPI flash or Parallel flash, and then
I can try to find a matching flash chip family.

Regards,
Carl-Daniel

-- 
http://www.hailfinger.org/

[Qemu-devel] Re: RFC: emulation of system flash

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 1864 bytes --]

On 2011-03-10 23:10, Carl-Daniel Hailfinger wrote:
> Auf 10.03.2011 22:55, Jordan Justen schrieb:
>> On Thu, Mar 10, 2011 at 13:37, Carl-Daniel Hailfinger
>> <c-d.hailfinger.devel.2006@gmx.net> wrote:
>>   
>>> Auf 10.03.2011 05:51, Jordan Justen schrieb:
>>>     
>>>> I have documented a simple flash-like device which I think could be
>>>> useful for qemu/kvm in some cases.  (Particularly for allowing
>>>> persistent UEFI non-volatile variables.)
>>>>
>>>> http://wiki.qemu.org/Features/System_Flash
>>>>
>>>> Let me know if you have any suggestions or concerns.
>>>>
>>>>       
>>> Is there any reason why you chose to invent an interface for the flash
>>> chip which is more complicated than the interface used by common flash
>>> chips out there?
>>> Maybe some EFI requirement?
>>>     
>> This is a simpler version than the flash devices I'm used to dealing
>> with for x86/x86-64 UEFI systems.  Can you suggest an alternative real
>> interface that is simpler?
>>   
> 
> Pseudocode for the real interface most common on x86 before SPI came along:
> 
> Write a page (256 bytes) or a few bytes:
> chip_writeb(0xAA, bios_base + 0x5555);
> chip_writeb(0x55, bios_base + 0x2AAA);
> chip_writeb(0xA0, bios_base + 0x5555);
> chip_writeb(databyte0, bios_base + addr);
> chip_writeb(databyte1, bios_base + addr + 1);
> chip_writeb(databyte2, bios_base + addr + 2);
> chip_writeb(databyte3, bios_base + addr + 3);
> ... up to 256 databytes.
> chip_readb(bios_base);
> The last chip_readb(bios_base) is repeated until the result does not
> change anymore.

Hmm, I may oversee some subtle difference, but this looks pretty much
like CFI to me (see hw/pflash_cfi02.c).

At least it's an in-band interface, which is the better choice as we
currently only have a PIIX3 southbridge for x86, predating even FWHs.

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 259 bytes --]

[Qemu-devel] Re: RFC: emulation of system flash

[Carl-Daniel Hailfinger]

Auf 11.03.2011 01:19, Jan Kiszka schrieb:
> On 2011-03-10 23:10, Carl-Daniel Hailfinger wrote:
>   
>> Auf 10.03.2011 22:55, Jordan Justen schrieb:
>>     
>>> On Thu, Mar 10, 2011 at 13:37, Carl-Daniel Hailfinger
>>> <c-d.hailfinger.devel.2006@gmx.net> wrote:
>>>   
>>>       
>>>> Auf 10.03.2011 05:51, Jordan Justen schrieb:
>>>>     
>>>>         
>>>>> I have documented a simple flash-like device which I think could be
>>>>> useful for qemu/kvm in some cases.  (Particularly for allowing
>>>>> persistent UEFI non-volatile variables.)
>>>>>
>>>>> http://wiki.qemu.org/Features/System_Flash
>>>>>
>>>>> Let me know if you have any suggestions or concerns.
>>>>>
>>>>>       
>>>>>           
>>>> Is there any reason why you chose to invent an interface for the flash
>>>> chip which is more complicated than the interface used by common flash
>>>> chips out there?
>>>> Maybe some EFI requirement?
>>>>     
>>>>         
>>> This is a simpler version than the flash devices I'm used to dealing
>>> with for x86/x86-64 UEFI systems.  Can you suggest an alternative real
>>> interface that is simpler?
>>>   
>>>       
>> Pseudocode for the real interface most common on x86 before SPI came along:
>>
>> Write a page (256 bytes) or a few bytes:
>> chip_writeb(0xAA, bios_base + 0x5555);
>> chip_writeb(0x55, bios_base + 0x2AAA);
>> chip_writeb(0xA0, bios_base + 0x5555);
>> chip_writeb(databyte0, bios_base + addr);
>> chip_writeb(databyte1, bios_base + addr + 1);
>> chip_writeb(databyte2, bios_base + addr + 2);
>> chip_writeb(databyte3, bios_base + addr + 3);
>> ... up to 256 databytes.
>> chip_readb(bios_base);
>> The last chip_readb(bios_base) is repeated until the result does not
>> change anymore.
>>     
> Hmm, I may oversee some subtle difference, but this looks pretty much
> like CFI to me (see hw/pflash_cfi02.c).
>   

I thought CFI also implements a way to retrieve device size/geometry
with the Query (0x98) command, but that part is rarely implemented on
x86 flash (I didn't see any yet).
That said, the non-query commands are identical AFAICS.


> At least it's an in-band interface, which is the better choice as we
> currently only have a PIIX3 southbridge for x86, predating even FWHs.
>   

Right, that pretty much kills the option of using SPI unless someone
wants to emulate a flash translation controller (e.g. the ITE IT8716F
Super I/O). Can be done, would work, but the IT8716F has some quirks
(max 1 MB SPI flash chips) which make it a less desirable option for
emulation.


Regards,
Carl-Daniel

-- 
http://www.hailfinger.org/

Re: [Qemu-devel] Re: RFC: emulation of system flash

[Jordan Justen]

On Thu, Mar 10, 2011 at 15:41, Carl-Daniel Hailfinger
<c-d.hailfinger.devel.2006@gmx.net> wrote:
> Auf 10.03.2011 23:58, Jordan Justen schrieb:
>> Would the firmware
>> be able to depend on having control of the device at OS runtime?  This
>> would be needed for UEFI non-volatile variables to make sure they can
>> always be written.
>>
>
> UEFI _should not_ have control of the device at OS runtime on real
> hardware for security reasons, unless UEFI slipped a rootkit into the
> OS. Not sure about Windows, but I'm pretty sure Linux will not run any
> UEFI code (except maybe during early init).

UEFI non-volatile variables are a runtime service, meaning the OS
should be able to utilize them at any time.

It is up to the OS whether it wants to actually make use of the
runtime services, of course.  Both Windows and Linux do have
interfaces available to modify UEFI variables at runtime.

> Think flash update. If some flash update software runs under your OS of
> choice, and UEFI is allowed to perform read/write accesses to flash at
> the same time, you will get random corruption. You could do it like some
> AMD chipsets, and provide some sort of semaphore for flash access
> coordination between a flash updater and the BIOS/EFI, but I don't think
> any Intel chipset can do that. Newer Intel chipsets allow locking out
> flash accesses not coming from the management engine, but UEFI does not
> run in the management engine, so that feature won't help us here.

The UEFI systems (meaning motherboard+firmware) that I have worked on
generally do not allow the flash (code) to be modified while the OS is
running.  Instead, UEFI has a 'capsule' concept where firmware update
data is transfered to the firmware from the OS during a 'reboot' of
sorts.  The firmware validates the capsule data, and then flashes it
on the boot following the reset.

But, the sections of the flash which non-volatile variables are stored
in can be updated by the UEFI firmware, and there are mechanisms which
can restrict this access as well to prevent corruption of the NV
variables.

Unfortunately, I assume these security mechanisms often come into
conflict with useful tools like flashrom.  (At least during OS
runtime.)

> That said, if any OS out there indeed runs UEFI code regularly during OS
> runtime, and that UEFI code wants to access flash, it has to hope that
> nobody else is trying to access flash at the same time. An easy way out
> would be to use the ACPI NVS region while the machine is running an OS,
> but changes would not automatically be persistent without help from the
> OS or some ACPI handler on shutdown.

To be UEFI compatible, the non-volatile variable write should become
persistent immediately after the call returns successfully.  This has
been the case on most UEFI systems that I have worked on.

-Jordan

Re: [Qemu-devel] Re: RFC: emulation of system flash

[Jordan Justen]

On Thu, Mar 10, 2011 at 16:27, Carl-Daniel Hailfinger
<c-d.hailfinger.devel.2006@gmx.net> wrote:
> Auf 11.03.2011 01:19, Jan Kiszka schrieb:
>> At least it's an in-band interface, which is the better choice as we
>> currently only have a PIIX3 southbridge for x86, predating even FWHs.
>>
>
> Right, that pretty much kills the option of using SPI unless someone
> wants to emulate a flash translation controller (e.g. the ITE IT8716F
> Super I/O). Can be done, would work, but the IT8716F has some quirks
> (max 1 MB SPI flash chips) which make it a less desirable option for
> emulation.

I don't much like this, but we might consider adding the SPI host
controller MMIO just below the flash data.  For the firmware, we
usually will know the size of firmware device that we've built for.
It seems SPI flash is pretty common today, and it sounds like
Carl-Daniel may have some SPI emulation code.

Am I understanding correctly that CFI is programmed via MMIO in the
flash memory space?  How difficult would it be to emulate CFI?  Does
CFI have the same power-of-2 size flexibility as SPI?

-Jordan

[Qemu-devel] Re: RFC: emulation of system flash

[Jordan Justen]

On Thu, Mar 10, 2011 at 12:21, Gleb Natapov <gleb@redhat.com> wrote:
> On Thu, Mar 10, 2011 at 11:50:42AM -0800, Jordan Justen wrote:
>>
>> So, perhaps this feature should build upon the other feature you and
>> Jan are discussing.  When will it become available?
>>
> When somebody will be motivated enough to send patches. If this was the
> only thing that stands in a way of QEMU having EFI firmware with CSM
> support it would have happened much faster though.

Regarding the read-IO, write-IO, read-RAM, write-RAM slots feature for kvm...

Unfortunately, this is not much related to the CSM issue.

It sounds to me like this feature would be important for a good
implementation of flash support that covers both qemu & kvm.

How big is this task?  How can I find out more to see if I can help?

Thanks,

-Jordan

Re: [Qemu-devel] Re: RFC: emulation of system flash

[Michal Suchanek]

Hello,

On 11 March 2011 20:09, Jordan Justen <jljusten@gmail.com> wrote:
> On Thu, Mar 10, 2011 at 16:27, Carl-Daniel Hailfinger
> <c-d.hailfinger.devel.2006@gmx.net> wrote:
>> Auf 11.03.2011 01:19, Jan Kiszka schrieb:
>>> At least it's an in-band interface, which is the better choice as we
>>> currently only have a PIIX3 southbridge for x86, predating even FWHs.
>>>
>>
>> Right, that pretty much kills the option of using SPI unless someone
>> wants to emulate a flash translation controller (e.g. the ITE IT8716F
>> Super I/O). Can be done, would work, but the IT8716F has some quirks
>> (max 1 MB SPI flash chips) which make it a less desirable option for
>> emulation.
>
> I don't much like this, but we might consider adding the SPI host
> controller MMIO just below the flash data.  For the firmware, we
> usually will know the size of firmware device that we've built for.
> It seems SPI flash is pretty common today, and it sounds like
> Carl-Daniel may have some SPI emulation code.
>
> Am I understanding correctly that CFI is programmed via MMIO in the
> flash memory space?  How difficult would it be to emulate CFI?  Does
> CFI have the same power-of-2 size flexibility as SPI?
>

Maybe it would be more useful to implement Intel LPC controller and
attach the flash to that (I assume it is the place where it would be
attached). The LPC controller is useful on its own (eg OS X assumes it
exists).

I am not sure how difficult hardware it is, though.

Thanks

Michal

Re: [Qemu-devel] Re: RFC: emulation of system flash

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 1382 bytes --]

On 2011-03-11 20:09, Jordan Justen wrote:
> On Thu, Mar 10, 2011 at 16:27, Carl-Daniel Hailfinger
> <c-d.hailfinger.devel.2006@gmx.net> wrote:
>> Auf 11.03.2011 01:19, Jan Kiszka schrieb:
>>> At least it's an in-band interface, which is the better choice as we
>>> currently only have a PIIX3 southbridge for x86, predating even FWHs.
>>>
>>
>> Right, that pretty much kills the option of using SPI unless someone
>> wants to emulate a flash translation controller (e.g. the ITE IT8716F
>> Super I/O). Can be done, would work, but the IT8716F has some quirks
>> (max 1 MB SPI flash chips) which make it a less desirable option for
>> emulation.
> 
> I don't much like this, but we might consider adding the SPI host
> controller MMIO just below the flash data.  For the firmware, we
> usually will know the size of firmware device that we've built for.
> It seems SPI flash is pretty common today, and it sounds like
> Carl-Daniel may have some SPI emulation code.

We don't emulate a chipset yet that includes SPI. Adding an artificial
SPI master is like PV - the guests will require special drivers.

> 
> Am I understanding correctly that CFI is programmed via MMIO in the
> flash memory space?  How difficult would it be to emulate CFI?  Does

Check qemu/hw/pflash_cfi02.c.

> CFI have the same power-of-2 size flexibility as SPI?

Yes.

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 259 bytes --]

[Qemu-devel] Re: RFC: emulation of system flash

[Gleb Natapov]

On Fri, Mar 11, 2011 at 01:41:17PM -0800, Jordan Justen wrote:
> On Thu, Mar 10, 2011 at 12:21, Gleb Natapov <gleb@redhat.com> wrote:
> > On Thu, Mar 10, 2011 at 11:50:42AM -0800, Jordan Justen wrote:
> >>
> >> So, perhaps this feature should build upon the other feature you and
> >> Jan are discussing.  When will it become available?
> >>
> > When somebody will be motivated enough to send patches. If this was the
> > only thing that stands in a way of QEMU having EFI firmware with CSM
> > support it would have happened much faster though.
> 
> Regarding the read-IO, write-IO, read-RAM, write-RAM slots feature for kvm...
> 
> Unfortunately, this is not much related to the CSM issue.
> 
> It sounds to me like this feature would be important for a good
> implementation of flash support that covers both qemu & kvm.
> 
> How big is this task?  How can I find out more to see if I can help?
> 
Having BIOS (or executable part of a flash) to be mapped as memory and
rest of the flash to be IO does not require any special changes to KVM
or QEMU. This is just a matter of implementing command line parsing and
flash device emulation.

--
			Gleb.