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
