From: Alexander G. <ag...@su...> - 2008-05-02 14:54:22
Attachments:
acpi-apic.patch
|
Hi, in the DSDT there are two different ways of defining, how an interrupt is supposed to be routed. Currently we are using the LNKA - LNKD method, which afaict is for legacy support. The other method is to directly tell the Operating System, which APIC pin the device is attached to. We can get that information from the very same entry, the LNKA to LNKD pseudo devices receive it. For now this does not give any obvious improvement. It does leave room for more advanced mappings, with several IOAPICs that can handle more devices separately. This might help when we have a lot of devices, as currently all devices sit on two interrupt lanes. More importantly (for me) though, is that Darwin enables the APIC mode unconditionally, so it won't easily run in legacy mode. Regards, Alex |
From: Marcelo T. <mto...@re...> - 2008-05-02 15:32:32
|
On Fri, May 02, 2008 at 04:55:24PM +0200, Alexander Graf wrote: > Hi, > > in the DSDT there are two different ways of defining, how an interrupt > is supposed to be routed. Currently we are using the LNKA - LNKD method, > which afaict is for legacy support. > The other method is to directly tell the Operating System, which APIC > pin the device is attached to. We can get that information from the very > same entry, the LNKA to LNKD pseudo devices receive it. > > For now this does not give any obvious improvement. It does leave room > for more advanced mappings, with several IOAPICs that can handle more > devices separately. This might help when we have a lot of devices, as > currently all devices sit on two interrupt lanes. > > More importantly (for me) though, is that Darwin enables the APIC mode > unconditionally, so it won't easily run in legacy mode. Hi Alexander, I'm just about to resend the patchset to add 3 PCI bridges, which already adds the _SUN method appropriately. Please rebase the APRT patch on top of that. Thanks! |
From: Alexander G. <ag...@su...> - 2008-05-03 20:29:38
|
On May 2, 2008, at 5:35 PM, Marcelo Tosatti wrote: > On Fri, May 02, 2008 at 04:55:24PM +0200, Alexander Graf wrote: >> Hi, >> >> in the DSDT there are two different ways of defining, how an >> interrupt >> is supposed to be routed. Currently we are using the LNKA - LNKD >> method, >> which afaict is for legacy support. >> The other method is to directly tell the Operating System, which APIC >> pin the device is attached to. We can get that information from the >> very >> same entry, the LNKA to LNKD pseudo devices receive it. >> >> For now this does not give any obvious improvement. It does leave >> room >> for more advanced mappings, with several IOAPICs that can handle more >> devices separately. This might help when we have a lot of devices, as >> currently all devices sit on two interrupt lanes. >> >> More importantly (for me) though, is that Darwin enables the APIC >> mode >> unconditionally, so it won't easily run in legacy mode. > > Hi Alexander, > Hi Marcelo, > I'm just about to resend the patchset to add 3 PCI bridges, which > already adds the _SUN method appropriately. Please rebase the APRT > patch > on top of that. Sure, unfortunately I probably won't find the time to do so (or even have a closer look at your patches) until the end of this week. Alex > > > Thanks! > > ------------------------------------------------------------------------- > This SF.net email is sponsored by the 2008 JavaOne(SM) Conference > Don't miss this year's exciting event. There's still time to save > $100. > Use priority code J8TL2D2. > http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone > _______________________________________________ > kvm-devel mailing list > kvm...@li... > https://lists.sourceforge.net/lists/listinfo/kvm-devel |
From: Avi K. <av...@qu...> - 2008-05-07 10:20:51
|
Alexander Graf wrote: > Hi, > > in the DSDT there are two different ways of defining, how an interrupt > is supposed to be routed. Currently we are using the LNKA - LNKD > method, which afaict is for legacy support. > The other method is to directly tell the Operating System, which APIC > pin the device is attached to. We can get that information from the > very same entry, the LNKA to LNKD pseudo devices receive it. > > For now this does not give any obvious improvement. It does leave room > for more advanced mappings, with several IOAPICs that can handle more > devices separately. This might help when we have a lot of devices, as > currently all devices sit on two interrupt lanes. > > More importantly (for me) though, is that Darwin enables the APIC mode > unconditionally, so it won't easily run in legacy mode. > Please properly signoff on patches. Also: > + // PCI Slot 8 > + Package() {0x0008ffff, 0, 0, ARQ3}, > + Package() {0x0008ffff, 1, 0, ARQ0}, > + Package() {0x0008ffff, 2, 0, ARQ1}, > + Package() {0x0008ffff, 3, 0, ARQ2}, > + > + // PCI Slot 9 > + Package() {0x0008ffff, 0, 0, ARQ0}, > + Package() {0x0008ffff, 1, 0, ARQ1}, > + Package() {0x0008ffff, 2, 0, ARQ2}, > + Package() {0x0008ffff, 3, 0, ARQ3}, > + Slot 9 uses the same addresses as slot 8. Similarly for slot 25. (found by Marcelo for the code which was the source for this copy-paste) -- error compiling committee.c: too many arguments to function |