Re: [PATCH] x86: update mptable v7

[Len Brown]

> >> >> make mptable to be consistent to acpi routing, so we could
> >> >> 1. kexec kernel with acpi=off
> >> >> 2. workaround BIOS that acpi routing is working, but mptable is not right.
> >> >>    so can use kernel/kexec to start other os that doesn't have good acpi support
> >> >
> >> > 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.

I don't see how this can work.

What if the the platform doesn't suport MPS -- the
2nd OS will try to run in PIC mode and will see
only the legacy interrupts?

What if it does support MPS but ACPI has configured
its PCI Interrupt Link Devices to direct interrupts
to different IRQs that are described by MPS?

> >> > Doing so could confuse the heck out of the platform firmware,
> >> > which will think that an ACPI-mode kernel is still running.

There is state in the chip-set that the ACPI OS has set
that makes no sense in an non-ACPI context and can lead
to bizzare behaviour.  The Links above is just one example.

the ACPI SCI interrupt is configured in ACPI mode only.
What happens when the non-ACPI OS boots and GPE's
fire and result in SCI's?  They'll not get serviced
and will kill that IRQ and anything else on it.

Can somebody clue me into why this concept
is something other than totally insane?

-Len


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/