On 03/06/14 17:09, Gabriel L. Somlo wrote:
On Thu, Mar 06, 2014 at 10:03:32AM +0100, Gerd Hoffmann wrote:
You don't need to worry about live migration, but the smbios stuff clearly goes into the guest-visible change category.
smbios_type1_defaults is one of the compatibility controls. It is false for 1.7 (+older) machine types and true otherwise. So when mucking with it we need to be careful to not break the compatibility stuff.
So, if we manage to get the patches into shape in time for qemu 2.0 your way to do that is fine. We are pretty close to the 2.0 freeze though, so maybe we should better plan for post-2.0 anyway, especially as you plan to add more tables.
Well, the only other type I'm personally interested in is 17 (memory device), because SeaBIOS doesn't build its smbios-v2.3 fields, even though it advertises v2.4 in its entry point data structure. And OS X is calling us out on that bluff... :)
Type 2 (base board) is required during boot by OS X 10.7 and 10.8 (strangely though, not by 10.6 or 10.9). But if it were only about Type 2, I'd probably have left it at passing the binary table in via the command line :)
What really convinced me to go for all this additional work was Laszlo's suggestion that this might help if/when we try to start trying to use UEFI/tianocore/ovmf instead of SeaBIOS.
Let me be a bit more precise... :)
Moving SMBIOS generation from SeaBIOS to qemu (similarly to ACPI) would benefit: - SeaBIOS (IIRC Kevin had implied his preference for this), - OVMF (no need to play catch-up field-wise), - other boot firmware.
I think I didn't suggest using OVMF *instead of* SeaBIOS. :)
In any case, I think if you can pull of this migration of SMBIOS tables, that would be a huge service to the community. I should have reviewed your series but it seemed hard, and I didn't have to "look very far" for other work :), so I postponed it. Then Gerd said "please split it up into smaller patches", which I can only agree with! :)
Thanks! Laszlo