From mboxrd@z Thu Jan 1 00:00:00 1970 From: Anthony Liguori Subject: Re: KVM call agenda for 2013-05-28 Date: Fri, 31 May 2013 07:58:36 -0500 Message-ID: <87ehcnmhkz.fsf@codemonkey.ws> References: <20130523124132.GA18596@redhat.com> <20130528235309.GA31648@morn.localdomain> <20130531023426.GB18156@morn.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Juan Quintela , KVM devel mailing list , qemu-devel qemu-devel , seabios@seabios.org, ddutile@redhat.com, dwmw2@infradead.org, lersek@redhat.com, "Michael S. Tsirkin" To: Kevin O'Connor Return-path: Received: from mail-ye0-f175.google.com ([209.85.213.175]:44247 "EHLO mail-ye0-f175.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753950Ab3EaM6k (ORCPT ); Fri, 31 May 2013 08:58:40 -0400 Received: by mail-ye0-f175.google.com with SMTP id q1so341531yen.6 for ; Fri, 31 May 2013 05:58:39 -0700 (PDT) In-Reply-To: <20130531023426.GB18156@morn.localdomain> Sender: kvm-owner@vger.kernel.org List-ID: Kevin O'Connor writes: > On Tue, May 28, 2013 at 07:53:09PM -0400, Kevin O'Connor wrote: >> There were discussions on potentially introducing a middle component >> to generate the tables. Coreboot was raised as a possibility, and >> David thought it would be okay to use coreboot for both OVMF and >> SeaBIOS. The possibility was also raised of a "rom" that lives in the >> qemu repo, is run in the guest, and generates the tables (which is >> similar to the hvmloader approach that Xen uses). > > Given the objections to implementing ACPI directly in QEMU, one > possible way forward would be to split the current SeaBIOS rom into > two roms: "qvmloader" and "seabios". The "qvmloader" would do the > qemu specific platform init (pci init, smm init, mtrr init, bios > tables) and then load and run the regular seabios rom. With this > split, qvmloader could be committed into the QEMU repo and maintained > there. This would be analogous to Xen's hvmloader with the seabios > code used as a starting point to implement it. What about a small change to the SeaBIOS build system to allow ACPI table generation to be done via a "plugin". This could be as simple as moving acpi.c and *.dsl into the QEMU build tree and then having a way to point the SeaBIOS makefiles to our copy of it. Then the logic is maintained stays in firmware but the churn happens in the QEMU tree instead of the SeaBIOS tree. Regards, Anthony Liguori > > With both the hardware implementation and acpi descriptions for that > hardware in the same source code repository, it would be possible to > implement changes to both in a single patch series. The fwcfg entries > used to pass data between qemu and qvmloader could also be changed in > a single patch and thus those fwcfg entries would not need to be > considered a stable interface. The qvmloader code also wouldn't need > the 16bit handlers that seabios requires and thus wouldn't need the > full complexity of the seabios build. Finally, it's possible that > both ovmf and seabios could use a single qvmloader implementation. > > On the down side, reboots can be a bit goofy today in kvm, and that > would need to be settled before something like qvmloader could be > implemented. Also, it may be problematic to support passing of bios > tables from qvmloader to seabios for guests with only 1 meg of ram. > > Thoughts? > -Kevin