From mboxrd@z Thu Jan 1 00:00:00 1970 From: Kevin O'Connor Subject: Re: KVM call agenda for 2013-05-28 Date: Fri, 31 May 2013 23:11:38 -0400 Message-ID: <20130601031138.GA6131@morn.localdomain> References: <20130523124132.GA18596@redhat.com> <20130528235309.GA31648@morn.localdomain> <20130531023426.GB18156@morn.localdomain> <87ehcnmhkz.fsf@codemonkey.ws> 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: Anthony Liguori Return-path: Received: from mail-qe0-f52.google.com ([209.85.128.52]:44280 "EHLO mail-qe0-f52.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1758448Ab3FADLl (ORCPT ); Fri, 31 May 2013 23:11:41 -0400 Received: by mail-qe0-f52.google.com with SMTP id 1so1360441qec.11 for ; Fri, 31 May 2013 20:11:40 -0700 (PDT) Content-Disposition: inline In-Reply-To: <87ehcnmhkz.fsf@codemonkey.ws> Sender: kvm-owner@vger.kernel.org List-ID: On Fri, May 31, 2013 at 07:58:36AM -0500, Anthony Liguori wrote: > Kevin O'Connor writes: > > 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. > What about a small change to the SeaBIOS build system to allow ACPI > table generation to be done via a "plugin". Using a runtime plugin (eg, "qplugin") would require a more complex handoff then qvmloader. With qplugin, seabios would need to know what memory qplugin is compiled to run in and make sure it didn't allocate anything there. Similarly, qplugin would need to not stomp on seabios while it runs, and it would need to coordinate with seabios where to place the final tables. With qvmloader, there is no need to coordinate memory addresses, so it can run anywhere, deploy the tables in their final location, and then launch seabios. > 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. I don't see how that would work. It would complicate the seabios build (as it would require a copy of qemu source to compile), and the resulting seabios binary would be strongly tied to the qemu version it was compiled with and vice-versa. This would break distro seabios rpms. It would also cause great pain when bisecting and would be confusing even during regular compile/debug cycles. Internal seabios calls (eg, memory allocations, pci config accesses) would need to be static interfaces, etc. -Kevin