From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:45265) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Uj4ox-0002fm-4j for qemu-devel@nongnu.org; Sun, 02 Jun 2013 05:43:31 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Uj4os-0007Qm-2u for qemu-devel@nongnu.org; Sun, 02 Jun 2013 05:43:27 -0400 Received: from mx1.redhat.com ([209.132.183.28]:32844) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Uj4or-0007Pm-QY for qemu-devel@nongnu.org; Sun, 02 Jun 2013 05:43:21 -0400 Date: Sun, 2 Jun 2013 12:43:08 +0300 From: "Michael S. Tsirkin" Message-ID: <20130602094308.GA9550@redhat.com> 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 Content-Disposition: inline In-Reply-To: <51A88D73.1090302@redhat.com> Subject: Re: [Qemu-devel] KVM call agenda for 2013-05-28 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Laszlo Ersek Cc: KVM devel mailing list , Juan Quintela , David Woodhouse , seabios@seabios.org, qemu-devel qemu-devel , Kevin O'Connor , ddutile@redhat.com, Anthony Liguori , Jordan Justen 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