linux-kernel - Re: [PATCH RFC] x86/acpi: don't ignore I/O APICs just because there's no local APIC

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <m17hz9djwn.fsf@fess.ebiederm.org>
Date:	Thu, 18 Jun 2009 19:42:00 -0700
From:	ebiederm@...ssion.com (Eric W. Biederman)
To:	Jeremy Fitzhardinge <jeremy@...p.org>
Cc:	Len Brown <lenb@...nel.org>, Ingo Molnar <mingo@...hat.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	"H. Peter Anvin" <hpa@...or.com>,
	the arch/x86 maintainers <x86@...nel.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Xen-devel <xen-devel@...ts.xensource.com>
Subject: Re: [PATCH RFC] x86/acpi: don't ignore I/O APICs just because there's no local APIC

Jeremy Fitzhardinge <jeremy@...p.org> writes:

> On 06/18/09 13:39, Eric W. Biederman wrote:
>>> Well, if acpi_pci_irq_lookup() and friends return the right things
>>> without having parsed the MADT and set up the secondary state, then we
>>> should be fine either way.
>>>
>>> acpi_irq_model gets tested in all sorts of random places, so I wonder if
>>> we'll need to set it to ACPI_IRQ_MODEL_IOAPIC (or something else?) to
>>> make things work properly.
>>>     
>>
>> And this is where things get interesting.  Xen strictly speaking has
>> already made that decision.  Unless you support non APIC mode it
>> should always be ACPI_IRQ_MODEL_IOAPIC.
>>   
>
> We could decide by fiat to not support non-APIC machines (which is more
> or less the case), but they do happen to work at the moment; Gerd even
> has one and provided fixes to make it work.  (Ditto non-ACPI, though
> they're commonly related.)

Interesting.  Then we need to know what Xen has chosen to do.
This whole logic of having linux and Xen happen to choose the
same interrupt handling mode by coincidence that is in use
right now seems fragile.

Xen runs a timer so I can't see Xen actually leaving the decision
up to linux.  It certainly doesn't leave the physical versus logical
mode decision up to linux.

>> But Xen runs the hardware so Xen knows, and Xen should be running
>> all of the acpi and what not to make it happen.
>>   
>
> There are two separate issues:
>
>    1. If we intercept interrupt routing at the pcibios_pci_irq_enable
>       level, will anything in the kernel care about the state of its
>       acpi_irq_model variable?  At first glance it *shouldn't* care,
>       because its just handing the whole problem off to Xen.

>    2. Xen has no AML interpreter, so its use of ACPI is limited to
>       parsing tables.  It looks like we'll need to set acpi_irq_model
>       appropriately and then get acpi_bus_init_irq() to run.

Assuming Xen not having the AML interpreter is the right decision.
I recall from some of the hibernation discussions that ACPI is not an easy
thing to start/stop on a machine unless it is handled just so.

Which if dom0 is to be redundant/restartable seems to make the
argument for AML living in Xen.

Xen has everything except the AML interpreter.

> (Related to this is making sure any chipset configuration that happens
> in the depths of the DSDT does in fact happen.)
>
>>> Hm, and principle we just get the SCI gsi from the FADT, but there's all
>>> that other mucking about with it in the MADT processing... Wonder what
>>> needs to happen there...
>>>     
>>
>> Good question.  What does the domU case do?
>>   
>
> DomU doesn't know or care about ACPI at all.  There's no reason for it
> to get any kind of ACPI event.

Yet at least occasionally Xen fakes up ACPI tables for a guest.

DomU has to do something to get the mapping, which is what I thought you
were referring to.

I can believe a Xen dom0 that is the same as domU except with lots
more hardware.  I have trouble understanding and Xen dom0 that has to
all kinds of special one off hardware manipulation because Xen is too
lazy too.  Xen is already 300,000 lines of code so it's not like it is
fully comprehensible/maintainable by a single person anyway.

Eric
--
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/