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: <4A3AC0C4.6060508@goop.org>
Date:	Thu, 18 Jun 2009 15:33:40 -0700
From:	Jeremy Fitzhardinge <jeremy@...p.org>
To:	"Eric W. Biederman" <ebiederm@...ssion.com>
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

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

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

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

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