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 08:04:10 -0500 Message-ID: <87bo7rmhbp.fsf@codemonkey.ws> References: <20130523124132.GA18596@redhat.com> <20130528235309.GA31648@morn.localdomain> <20130531023426.GB18156@morn.localdomain> <51A88D73.1090302@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Kevin O'Connor , Juan Quintela , KVM devel mailing list , qemu-devel qemu-devel , seabios@seabios.org, ddutile@redhat.com, David Woodhouse , "Michael S. Tsirkin" To: Laszlo Ersek , Jordan Justen Return-path: Received: from mail-yh0-f44.google.com ([209.85.213.44]:48420 "EHLO mail-yh0-f44.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750837Ab3EaNEO (ORCPT ); Fri, 31 May 2013 09:04:14 -0400 Received: by mail-yh0-f44.google.com with SMTP id 29so387117yhl.3 for ; Fri, 31 May 2013 06:04:14 -0700 (PDT) In-Reply-To: <51A88D73.1090302@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: Laszlo Ersek writes: > On 05/31/13 09:09, Jordan Justen wrote: > > Due to licensing differences I can't just port code from SeaBIOS to > OVMF Fork OVMF, drop the fat module, and just add GPL code. It's an easily solvable problem. Rewriting BSD implementations of everything is silly. Every other vendor that uses TianoCore has a proprietary fork. Maintaining a GPL fork seems just as reasonable. Regards, Anthony Liguori > (and I never have without explicit permission), so it's been a lot of > back and forth with acpidump / iasl -d in guests (massage OVMF, boot > guest, check guest dmesg / lspci, dump tables, compare, repeat), brain > picking colleagues, the ACPI and PIIX specs and so on. I have a page on > the RH intranet dedicated to this. When something around these parts is > being changed (or looks like it could be changed) in SeaBIOS, or between > qemu and SeaBIOS, I always must be alert and consider reimplementing it > in, or porting it with permission to, OVMF. (Most recent example: > pvpanic device -- currently only in SeaBIOS.) > > It worries me that if I slack off, or am busy with something else, or > simply don't notice, then the gap will widen again. I appreciate > learning a bunch about ACPI, and don't mind the days of work that went > into some of my simple-looking ACPI patches for OVMF, but had the tables > come from a common (programmatic) source, none of this would have been > an issue, and I wouldn't have felt even occasionally that ACPI patches > for OVMF were both duplicate work *and* futile (considering how much > ahead SeaBIOS was). > > I don't mind reimplementing stuff, or porting it with permission, going > forward, but the sophisticated parts in SeaBIOS are a hard nut. For > example I'll never be able to auto-extract offsets from generated AML > and patch the AML using those offsets; the edk2 build tools (a project > separate from edk2) don't support this, and it takes several months to > get a thing as simple as gcc-47 build flags into edk2-buildtools. > > Instead I have to write template ASL, compile it to AML, hexdump the > result, verify it against the AML grammar in the ACPI spec (offsets > aren't obvious, BytePrefix and friends are a joy), define & initialize a > packed struct or array in OVMF, and patch the template AML using fixed > field names or array subscripts. Workable, but dog slow. If the ACPI > payload came from up above, we might be as well provided with a list of > (canonical name, offset, size) triplets, and could perhaps blindly patch > the contents. (Not unlike Michael's linker code for connecting tables > into a hierarchy.) > > AFAIK most recently iasl got built-in support for offset extraction (and > in the process the current SeaBIOS build method was broken...), so that > part might get easier in the future. > > Oh well it's Friday, sorry about this rant! :) I'll happily do what I > can in the current status quo, but frequently, it won't amount to much. > > Thanks, > Laszlo