On 2 Dec 2018, at 18:31, Kevin O'Connor
On Fri, Nov 30, 2018 at 09:53:05PM +0200, Liran Alon wrote:
On 30 Nov
2018, at 21:25, Kevin O'Connor <kevin(a)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.
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?).
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
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
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.