From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Michael S. Tsirkin" Subject: Re: KVM call agenda for 2013-06-11 Date: Tue, 11 Jun 2013 22:15:24 +0300 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-Transfer-Encoding: 7bit Cc: KVM devel mailing list , Juan Quintela , "Jordan Justen \(Intel address\)" , seabios@seabios.org, qemu-devel , dwmw2@infradead.org To: Laszlo Ersek Return-path: Content-Disposition: inline In-Reply-To: <51B76717.1030502@redhat.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: seabios-bounces@seabios.org Sender: seabios-bounces@seabios.org List-Id: kvm.vger.kernel.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