[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [Xen-devel] 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 _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |