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

[Jan Kiszka <jan.kiszka@siemens.com>]

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