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 -- 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
