From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:50956) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UmU2R-0004GJ-LQ for qemu-devel@nongnu.org; Tue, 11 Jun 2013 15:15:31 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UmU2N-000717-1R for qemu-devel@nongnu.org; Tue, 11 Jun 2013 15:15:27 -0400 Received: from mx1.redhat.com ([209.132.183.28]:10128) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UmU2M-00070y-Pg for qemu-devel@nongnu.org; Tue, 11 Jun 2013 15:15:22 -0400 Date: Tue, 11 Jun 2013 22:15:24 +0300 From: "Michael S. Tsirkin" Message-ID: <20130611191524.GA3098@redhat.com> References: <20130604132431.GA24301@redhat.com> <20130611154551.GA2756@redhat.com> <51B76717.1030502@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <51B76717.1030502@redhat.com> Subject: Re: [Qemu-devel] KVM call agenda for 2013-06-11 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Laszlo Ersek Cc: KVM devel mailing list , Juan Quintela , "Jordan Justen (Intel address)" , seabios@seabios.org, qemu-devel , Kevin O'Connor , ddutile@redhat.com, Anthony Liguori , dwmw2@infradead.org On Tue, Jun 11, 2013 at 08:06:15PM +0200, Laszlo Ersek wrote: > On 06/11/13 17:45, Michael S. Tsirkin wrote: > > > To summarize, there's a concensus now that generating ACPI > > tables in QEMU is a good idea. > > > > 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. > > Sorry about not following the series more closely -- is there now a qemu > interface available that allows any firmware just take the tables, maybe > to fix them up blindly / algorithmically, and to install them? Yes. > IOW, is the interface at such a point that in OVMF we could start > looking throwing out specific code, in favor of implementing the generic > fw-side algorithm? > > > It seems clear we have users for this such as > > hotplug of devices behind pci bridges, so > > why keep the infrastructure out of tree? > > > > 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. > > I think the current fw_cfg interface for SMBIOS tables is already good > enough to save a lot of work in OVMF. Namely, if all required tables > were generated (table template + field-wise patching) in qemu, and then > all exported over fw_cfg as verbatim tables, my SMBIOS series currently > pending for OVMF should be able to install them. > > This would save OVMF the coding of templates (and any necessary > patching) for types 3, 4 (especially nasty), 9, 16, 17, 19, and 32. > (Basically "all except type 0 and type 1", which are already implemented > (but verbatim tables from qemu would take priority even for type 0 and > type 1). Type 7 can be left out apparently; IIRC dmidecode doesn't > report it even under SeaBIOS.) > > I'm not implying anyone should start working on this (myself included > :)), but yeah, moving SMBIOS would save work in OVMF. (Provided there > was any reason to support said SMBIOS tables in OVMF :)) > > Thanks, > Laszlo