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

[Michael S. Tsirkin]

On Fri, May 31, 2013 at 01:45:55PM +0200, Laszlo Ersek wrote:
> On 05/31/13 09:09, Jordan Justen wrote:
> 
> > Why is updating the ACPI tables in seabios viewed as such a burden?
> > Either qemu does it, or seabios... (And, OVMF too, but I don't think
> > you guys are concerned with that. :)
> 
> I am :)
> 
> > On the flip side, why is moving the ACPI tables to QEMU such an issue?
> > It seems like Xen and virtualbox both already do this. Why is running
> > iasl not an issue for them?
> 
> I think something was mentioned about iasl having problems on BE
> machines? I could be easily wrong but I *guess* qemu's hosts x targets
> (emulate what on what) set is a proper superset of xen's and
> virtualbox's. Presumably if you want to run an x86 guest on a MIPS host,
> and also want to build qemu on the same MIPS (or SPARC) host, you'd have
> to run iasl there too.

You guys should take a look at the patch series I posted.

That's solved there by the means of keeping iasl output in qemu git tree.
configure checks for a working iasl and enables/disables
using this pre-processed output accordingly.
Everyone developing ASL code would still need working iasl
but that's already the case today.

> > tables :)
> 
> Impossible. :)
> 
> In earnest, I think what we have now is (mostly) correct, just not
> extensive / flexible enough. No support for PCI hotplug or CPU hotplug,
> none for S3 (although all of these tie into UEFI deeply), no MTRR setup,
> no MPTABLE; let alone a non-PIIX chipset. (Well maybe I shouldn't lump
> these under the "ACPI umbrella".)
> 
> > but I haven't seen it as much of a burden. (Of course,
> > Laszlo has helped out with many of the ACPI changes in OVMF, so his
> > opinion should be taken into consideration too. :)
> 
> It hasn't been a "burden" in the sense of me not liking the activity; I
> actually like fiddling with knobs. It has certainly been extra work to
> bring OVMF's ACPI tables closer to SeaBIOS's functionality / flexibility
> (and we still lag behind it quite.).
> 
> Due to licensing differences I can't just port code from SeaBIOS to OVMF
> (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