On Mo, 2014-02-17 at 15:33 -0500, Kevin O'Connor wrote: > On Mon, Feb 17, 2014 at 11:09:48AM -0500, Gabriel L. Somlo wrote: > > On Fri, Feb 07, 2014 at 04:37:58PM +0100, Paolo Bonzini wrote: > > >Il 06/02/2014 14:38, Gabriel L. Somlo ha scritto: > > >>On Wed, Feb 05, 2014 at 08:02:25PM -0500, Kevin O'Connor wrote: > > >>> Thanks. In general, though, it is preferred to make smbios changes at > > >>> the QEMU layer. Indeed, going forward, I'd like to see all the smbios > > >>> stuff moved up to QEMU. > > >>> > > >>> Is there something in these two patches that can't be done in QEMU? > > >> > > >> But anyhow, right now QEMU seems to be making relatively minor tweaks > > >> to something that's firmly at home in SeaBIOS, which is why I sent my > > >> patches to the latter... > > > > > >Yeah, that's correct. There's really no particular hook in QEMU to do this. > > > > Would it be OK to apply this in SeaBIOS now, so that 1. it can be > > useful until whenever SMBIOS gets transferred/absorbed into QEMU, > > and 2. it won't fall through the cracks when that transition happens ? > > Unfortunately, if we change the smbios in SeaBIOS, it will show up on > all machine types that use the new version of SeaBIOS. We've had > issues with this type of change before as various OSes react > differently to the change. > > Gerd, what's your take on this change?
I think we can do this in qemu, without touching seabios at all. The currently used fw_cfg interface allows to pass both individual fields and complete tables. In practice the individual fields interface is used for type0 and type1 table fields. I think the only way to pass complete tables is 'qemu -smbios file=<pregenerated-blob-here>'. If seabios finds a table provided by qemu it used it, otherwise it (possibly) generates its own. So we can smoothly switch over to qemu, table-by-table. You can have qemu provide type2+type17 tables, and leave everything else as-is. And when doing it in qemu it is easy to do it for new machine types only. cheers, Gerd