On 2 Dec 2018, at 18:31, Kevin O'Connor kevin@koconnor.net wrote:
On Fri, Nov 30, 2018 at 09:53:05PM +0200, Liran Alon wrote:
On 30 Nov 2018, at 21:25, Kevin O'Connor kevin@koconnor.net wrote: These tables are considered static in SeaBIOS. We've found that any change to these legacy tables tends to break something. We moved the generation of SMBIOS and ACPI to QEMU for this reason. I don't think MPTable was moved into QEMU, but I think that should be the way forward if a particular guest needs different content in this table.
Makes sense.
Until that MPTable will be propagated to SeaBIOS via fw_cfg from QEMU, don’t you think it makes sense to revert this commit for now? As it caused a real guest workload to break (with non-trivial issue to diagnose) and doesn’t provide a real value of it’s own (or am I missing something?).
Hi Liran,
The original commit is from almost six years ago. I know it's very difficult to track down these types of regressions. I don't doubt it took a large effort to find the root cause. However, there's a very real risk that a change (any change) would introduce a further regression.
Even when the change is correct, we know from experience that different operating systems sometimes take unexpected actions when parsing these tables. In particular, we've seen in the past that innocuous changes to the bios tables can cause some operating systems to redo "hardware scans". For these (and other) reasons we've moved bios table generation out of SeaBIOS.
So, I don't think it would be a good idea to make this change to SeaBIOS.
Thanks, -Kevin
Hmm OK. I understand your point. BTW, we have run a big variety of OSes with this change and haven’t seen a regression.
So you recommend that even if we implement the mechanism to pass mptable via fw_cfg from QEMU that this specific behaviour will be controlled by a flag? That is doable. Just wondering on your opinion.
-Liran