Hi -

  The attached patch gets PCI interrupt routing working with ACPI.
The basic problem was we weren't specifying the correct _ADR for
the PCI-ISA bridge in the ACPI DSDT.  (It's the PCI-ISA bridge that
implements PCI interrupt routing.  Its address is device 1, fn 0 on the
parent PCI bus -- see the _ADR change in the patch.)  This makes attempts
to program the PCI interrupt routing (i.e., to assign a particular IRQ 
to one
of the four PCI "LNK" devices) write into the correct device's PCI config
space.  (These writes were going into the PCI-host bridge's config space 
...)

  But that fix alone causes even more grief with ACPI-compliant guests
that use (the I/O) APIC.  What happens is the fixed PRTA PCI routing table
returned for APIC mode doesn't reference the LNK devices (which are still
defined in ACPI), and so calls their _DIS (disable) methods in ACPI, which
effectively stops PCI devices from interrupting.  There are a couple of 
alternatives
for fixing this.  I think the best one (which happens to be easiest, and 
what I've
implemented in this patch) is to *always* return the programmable PRTP
routing table, even in APIC mode.  That way the LNK devices are always used
so we don't need to detect that they're not used.

  This also has the advantage of allowing APIC-mode guests to better manage
IRQ conflicts.  Normally (on real hardware) the APIC-mode PRT table maps
the four PCI interrupts to IRQs > 15.  But QEMU is (essentially, for 
now) wired
straight into a virtual PIC -- we can't raise IRQs > 15, so the old 
APIC-mode
PRT was mapping them to IRQS < 16, subjecting them to the possible IRQ-
sharing that the PIC-mode table allows them to adjust via the LNK devices.

  Oh yeah, the patch also corrects a typo in LNKA's _CRS method.  Surely 
this
should be referencing PIRA, not PIRB (see the other LNKx's _CRS methods).

  This combination of things gets rid of complaints about not finding IRQs
for some PCI devices from several ACPI-compliant guests, including Win2003
and RHEL4-64.  It also seemed to fix some more mysterious hang I was seeing
(on xen-unstable only) when trying to boot certain configs with 
ACPI-compliant
guests.

Dave

P.S. The second attachment is a version of the fix that applies after 
the DSDT
fix from qing.he@intel.com.

P.P.S. Keir -- should we be submitting the patched AML (acpi_dsdt.c) as 
well?
I did, but wasn't sure of the convention ...