From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=46043 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Q2pOn-0000Cr-57 for qemu-devel@nongnu.org; Thu, 24 Mar 2011 14:36:46 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Q2pOl-0005BA-Qg for qemu-devel@nongnu.org; Thu, 24 Mar 2011 14:36:44 -0400 Received: from mx1.redhat.com ([209.132.183.28]:57242) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Q2pOl-0005Ap-GA for qemu-devel@nongnu.org; Thu, 24 Mar 2011 14:36:43 -0400 Date: Thu, 24 Mar 2011 20:36:38 +0200 From: Gleb Natapov Subject: Re: [Qemu-devel] OVMF, SeaBIOS & non-CSM based legacy boot Message-ID: <20110324183638.GC14544@redhat.com> References: <4D87989D.70005@codemonkey.ws> <20110322080048.GQ10151@redhat.com> <20110322200720.GA16147@redhat.com> <20110323123656.GA7766@redhat.com> <20110324115300.GC32408@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In-Reply-To: List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jordan Justen Cc: qemu-devel On Thu, Mar 24, 2011 at 09:46:09AM -0700, Jordan Justen wrote: > 2011/3/24 Gleb Natapov : > > On Wed, Mar 23, 2011 at 03:32:41PM -0700, Jordan Justen wrote: > >> By the way, today OVMF attempts to store NV-Var data in a file on the > >> disk, but this cannot support variables at runtime. =9A(This is why I > >> sent in the patch for using -pflash on x86/x86-64.) > >> > > And this file is stored always at the same location? If it is then then > > problem is solved! But what do you mean by "this cannot support > > variables at runtime"? >=20 > The variables can be set while the OS is running, and the OS has > exclusive control over the disk at that time. Today in OVMF we set > variables into memory during this time, and hope that memory it still > around after a reset. This does not provide realistic non-volatile > UEFI variable support. KVM preserve memory during reset, but we better not rely on that. >=20 > What we really need is flash memory. (See my 'hw/pc: Support system > flash memory' patch.) Storing boot file only on flash memory will require to distribute the flash image along with disk image. >=20 > But, there is nothing stopping us from also storing the variables on > the disk (during the firmware boot), and also using them as a backup. >=20 This will still require at least one reboot for variables to be saved in a filesystem, but this is better then nothing. > Additionally, we can add yet another backup system of looking for > known os-loader executable paths. This would be needed if a disk > image were ever to be transferred from a real machine to a VM image. > But, this would require firmware updates as new UEFI OS loader install > paths are added. Also, let's hope no OS decides to generate a random > path for the OS loader. :) >=20 Firmware updates in a VM is very easy, so not a big deal. -- Gleb.