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. > Maybe we are doing lots of things horribly wrong in our OVMF ACPI > 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 -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
