Re: [PATCH] x86: update mptable v7

[ebiederm@xmission.com (Eric W. Biederman)]

Len Brown <lenb@kernel.org> writes:

>> >>> > Is this an effort to boot an ACPI-mode kernel,
>> >>> > and then kexec a non-ACPI kernel?
>> >>>
>> >>> Yes,
>> >>
>> >> Why is this feature needed?
>> >> There are a number of ways that the resulting kernel may fail,
>> >> all platform specific.
>> >
>> > other os still doesn't have update acpi irq routing support. but has
>> > broken mptable.
>> 
>> Which is at least in part a reason to go back to the BIOS manufacturer
>> and get them to fix their table.
>
> Who says it is broken?

In the common case if not in general the MP table and the ACPI 
version of the same table, provide the same data in slight different
formats.

>> I can see a warning coming from the kernel if these two tables are
> inconsistent
>> though.
>
> Again, there may not *be* an MPS table, and if there is but the
> interrupt links are programmable, the MPS table may have very little
> in common with the state of the machine in ACPI mode.

That I will believe.

> I'm sorry, kexec continues to sound like science fiction to me.
> I don't understand why scribbling on upstream Linux in the name
> of science fiction makes any sense.
>
> I just don't get it.

In the normal kexec case not the kexec on panic (aka kdump) we should
have shutdown ACPI on the way down.  So the machine won't be running
in ACPI mode.  I assume ACPI supports that.

What YH is doing does sound potentially dangerous.  If you can indeed compare
the two tables and in fact see they are inconsistent.  That is a good case
for printing a warning message.  YH clearly started this because in his
testing the MP table was broken and he had an older Enterprise kernel to run
that had unusable ACPI support.  That however is a BIOS bug.  Pushing back
on BIOS bugs and making them easy to find is always a good deal.  Silently
fixing them (not just working around them) seems unprecedented.

Eric