From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=51777 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PxoNJ-0005Vc-T2 for qemu-devel@nongnu.org; Thu, 10 Mar 2011 17:30:30 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PxoNI-0007zi-Dz for qemu-devel@nongnu.org; Thu, 10 Mar 2011 17:30:29 -0500 Received: from mailout-de.gmx.net ([213.165.64.23]:40050) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1PxoNH-0007zF-Vz for qemu-devel@nongnu.org; Thu, 10 Mar 2011 17:30:28 -0500 Message-ID: <4D79513F.2090008@gmx.net> Date: Thu, 10 Mar 2011 23:31:27 +0100 From: Carl-Daniel Hailfinger MIME-Version: 1.0 Subject: Re: [Qemu-devel] Re: RFC: emulation of system flash References: <4D789588.1060108@redhat.com> <4D794819.1060001@gmx.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jordan Justen Cc: Gleb Natapov , Stefan Hajnoczi , qemu-devel , Michal Suchanek , Kevin O'Connor , Avi Kivity Auf 10.03.2011 23:14, Jordan Justen schrieb: > On Thu, Mar 10, 2011 at 13:52, Carl-Daniel Hailfinger > 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/