Message-ID: <86802c440806182326m8c3ad56j29242895507e074d@mail.gmail.com>
Date:	Wed, 18 Jun 2008 23:26:11 -0700
From:	"Yinghai Lu" <yhlu.kernel@...il.com>
To:	"Len Brown" <lenb@...nel.org>
Cc:	"Ingo Molnar" <mingo@...e.hu>,
	"Thomas Gleixner" <tglx@...utronix.de>,
	"H. Peter Anvin" <hpa@...or.com>,
	"Andrew Morton" <akpm@...ux-foundation.org>,
	"Eric W. Biederman" <ebiederm@...ssion.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] x86: update mptable v7

On Wed, Jun 18, 2008 at 10:20 PM, Len Brown <lenb@...nel.org> wrote:
>
>
>> >> >> 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?

if the system doesn't support mps, this patch will bail out, because
it can not find mptable

>
> 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?

it will use irq from mptable that is updated according to acpi

when acpi irq set routing, and it will set some bits in pci config in
southbridge, and the irq routing is consistent between HW and irq
returned by acpi.
when first kernel is shutdown, it doesn't restore the bits about irq
routing in pci config. So if keep updated mptable has correct pin,
then device on second
kernel will work.

>
>> >> > 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.

the patch doesn't change entries in mptable that pin < 16 and irq is
not for pci device...

and normal sci/acpi is using 9..., and even mptable even doesn't has that entry.
and there is no pci device share that irq with sci/acpi..., so it will
be put into updated mptable.
so next kernel will mask that.

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

for system that have 6 pcie slots and more, with full populated cards.
when boot with mptable, BIOS will use irq < 16 for all pci devices,
and several devices will share same irq.
but when acpi is enabled, irqs are spanned all over.

also when pci card with several pci bridges is plugged in, the mptable
is totally messed up, some slot will work, and some doesn't work.

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

Powered by blists - more mailing lists