From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:34515) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UwvVt-0003hw-5f for qemu-devel@nongnu.org; Wed, 10 Jul 2013 10:37:06 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UwvVn-0004kI-LE for qemu-devel@nongnu.org; Wed, 10 Jul 2013 10:37:01 -0400 Received: from mx1.redhat.com ([209.132.183.28]:24304) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UwvVn-0004jt-Cp for qemu-devel@nongnu.org; Wed, 10 Jul 2013 10:36:55 -0400 Message-ID: <51DD720F.5030305@redhat.com> Date: Wed, 10 Jul 2013 16:39:11 +0200 From: Laszlo Ersek MIME-Version: 1.0 References: <1371803227-20852-1-git-send-email-mchang@suse.com> <51C845A6.2020103@redhat.com> <51C8B7AF.2020503@redhat.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [Qemu-devel] OVMF NvVars in flash, on KVM [was: OvmfPkg/NvVarsFileLib: handle the inital file not found] List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jordan Justen , Gleb Natapov , Paolo Bonzini , Anthony Liguori Cc: "edk2-devel@lists.sourceforge.net" , "qemu-devel@nongnu.org" I'm derailing this preexistent edk2-devel thread for public benefit :) On 06/24/13 23:36, Jordan Justen wrote: > On Mon, Jun 24, 2013 at 2:18 PM, Laszlo Ersek > wrote: >> On 06/24/13 23:06, Jordan Justen wrote: >>> We could consider yanking all these hacks out, and just forcing >>> people to use QEMU with flash support when that eventually gets >>> finished. >>> >>> But, some people like the idea that the 'disk image' can decide the >>> boot order, so I'm not sure what the eventual solution will be. >> >> I think we should keep (improving) the on-disk NvVars stuff until the >> flash support is complete. >> >> BTW could you please summarize the status on that? I believe KVM and >> qemu already have the necessary commits (could you identify them >> perhaps?) > > Yes, it is currently supported on QEMU master. For non-KVM, it > should work since QEMU 1.2. For KVM, it should work as of the > next QEMU release (1.6) whenever that happens. > > But, recently someone noted a regression with this support, so > I need to investigate this. > >> and that you have a WIP series for OVMF -- what needs to be >> done there? > > 2 things I know of: > * Clean up or perhaps just push fwd my ovmf-nvvars branch > https://github.com/jljusten/edk2/tree/ovmf-nvvars > * Push fwd a fix for a boot issue with X64 page tables residing > in the 'ROM/flash' memory with the newer KVM read-only > memory support. (The same support that makes flash possible > on KVM causes OVMF to not boot for me.) I have a fix for > this. >>From a more recent discussion, On 07/10/13 15:19, Gleb Natapov wrote: > On Wed, Jul 10, 2013 at 02:45:21PM +0200, Laszlo Ersek wrote: >> I'm still very confused about the interplay between emulated flash >> and KVM. If anyone can post a summary, I'd be grateful. >> > If you want to run code from emulated flash you need RO memory support > in KVM. It is possible to implement flash without RO memory, but you > will not be able to put UEFI code into it. I do not know where > requirement that UEFI and non-volatile variables should be on the same > flash is coming from. Can we put UEFI into a ROM and provide separate > flash to store non-volatile variables? I have no idea what to answer, but I desperately want this to work :) Currently I can't spend much time on it (and of course I'm not prodding anyone to do it for me), I'd just like to understand the status. So, what *exact* upstream Linux commit adds RO memory support to KVM (on x86_64)? How would a single *hardware* flash device store both (compressed) UEFI code and (rewriteable) non-volatile variables? What else do flash + KVM depend on? Can you guys please talk to each other directly and let me just listen in? :) Thanks! Laszlo