Re: [Qemu-devel] KVM call agenda for 2013-05-28

[Anthony Liguori <anthony@codemonkey.ws>]

Laszlo Ersek <lersek@redhat.com> writes:

> On 05/31/13 09:09, Jordan Justen wrote:
>
> Due to licensing differences I can't just port code from SeaBIOS to
> OVMF

<soapbox>

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.

</soapbox>

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