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