From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=38694 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Pxexd-0001Rt-M1 for qemu-devel@nongnu.org; Thu, 10 Mar 2011 07:29:44 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PxexZ-0007XU-7z for qemu-devel@nongnu.org; Thu, 10 Mar 2011 07:27:18 -0500 Received: from thoth.sbs.de ([192.35.17.2]:32409) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PxexY-0007Vq-NH for qemu-devel@nongnu.org; Thu, 10 Mar 2011 07:27:17 -0500 Message-ID: <4D78C39B.1060404@siemens.com> Date: Thu, 10 Mar 2011 13:27:07 +0100 From: Jan Kiszka MIME-Version: 1.0 References: <20110310094726.GB14805@redhat.com> <4D78B5BB.5020408@siemens.com> <20110310114801.GC14805@redhat.com> <4D78BEB6.6070208@siemens.com> <20110310121741.GD14805@redhat.com> In-Reply-To: <20110310121741.GD14805@redhat.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [Qemu-devel] Re: RFC: emulation of system flash List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Gleb Natapov Cc: Stefan Hajnoczi , qemu-devel , Michal Suchanek , Kevin O'Connor , Avi Kivity , Jordan Justen 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