From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:39102) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UmTSU-0003s9-Ia for qemu-devel@nongnu.org; Tue, 11 Jun 2013 14:38:20 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UmTSQ-0002j4-Mh for qemu-devel@nongnu.org; Tue, 11 Jun 2013 14:38:18 -0400 Received: from mail-oa0-x22a.google.com ([2607:f8b0:4003:c02::22a]:36200) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UmTSQ-0002ik-JF for qemu-devel@nongnu.org; Tue, 11 Jun 2013 14:38:14 -0400 Received: by mail-oa0-f42.google.com with SMTP id n12so2797691oag.15 for ; Tue, 11 Jun 2013 11:38:13 -0700 (PDT) From: Anthony Liguori In-Reply-To: <20130611154551.GA2756@redhat.com> References: <20130604132431.GA24301@redhat.com> <20130611154551.GA2756@redhat.com> Date: Tue, 11 Jun 2013 13:38:11 -0500 Message-ID: <878v2gqyr0.fsf@codemonkey.ws> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [Qemu-devel] KVM call agenda for 2013-06-11 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Michael S. Tsirkin" , Juan Quintela Cc: KVM devel mailing list , dwmw2@infradead.org, seabios@seabios.org, qemu-devel , Kevin O'Connor , ddutile@redhat.com, lersek@redhat.com "Michael S. Tsirkin" writes: > On Tue, Jun 04, 2013 at 04:24:31PM +0300, Michael S. Tsirkin wrote: >> Juan is not available now, and Anthony asked for >> agenda to be sent early. >> So here comes: >> >> Agenda for the meeting Tue, June 11: >> >> - Generating acpi tables, redux > > Not so much notes as a quick summary of the call: > > There are the following reasons to generate ACPI tables in QEMU: > > - sharing code with e.g. ovmf > Anthony thinks this is not a valid argument > > - so we can make tables more dynamic and move away from iasl > Anthony thinks this is not a valid reason too, > since qemu and seabios have access to same info > MST noted several info not accessible to bios. > Anthony said they can be added, e.g. by exposing > QOM to the bios. > > - even though most tables are static, hardcoded > they are likely to change over time > Anthony sees this as justified > > To summarize, there's a concensus now that generating ACPI > tables in QEMU is a good idea. I would say best worst idea ;-) I am deeply concerned about the complexity it introduces but I don't see many other options. > > Two issues that need to be addressed: > - original patches break cross-version migration. Need to fix that. > > - Anthony requested that patchset is merged together with > some new feature. I'm not sure the reasoning is clear: > current a version intentionally generates tables > that are bug for bug compatible with seabios, > to simplify testing. I expect that there will be additional issues that need to be worked out and want to see a feature that actually uses the infrastructure before we add it. > It seems clear we have users for this such as > hotplug of devices behind pci bridges, so > why keep the infrastructure out of tree? It's hard to evaluate the infrastructure without a user. > Looking for something additional, smaller as the hotplug patch > is a bit big, so might delay merging. > > > Going forward - would we want to move > smbios as well? Everyone seems to think it's a > good idea. Yes, independent of ACPI, I think QEMU should be generating the SMBIOS tables. Regards, Anthony Liguori > -- > MST