Hi David,
I agreed with your fix this _ADR for PCI router issue as we discussed
one week before. I think adding more _PRT slot is fine for more new PCI
devices
Yes, current qemu using apic as pic IRQ0-15's one to one mapping. Same
thing for MPS table for non-acpi mode.
Now we cut the apic mode support, always return the pic mode IRQ and
Link, that may be fine, but when we want to expand more apic IRQs, what
are we going to do? Then have to going back if need more IRQs.
By the way, does the code working on SMP guest OS (when apic=1)?
Thanks,
Winston,
-----Original Message-----
Date: Thu, 12 Oct 2006 14:01:16 -0400
From: David Lively <dlively@xxxxxxxxxxxxxxx>
Subject: [Xen-devel] [PATCH][HVM] fix PCI interrupt routing via ACPI
To: xen-devel@xxxxxxxxxxxxxxxxxxx
Message-ID: <452E82EC.8000402@xxxxxxxxxxxxxxx>
Content-Type: text/plain; charset="iso-8859-1"
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@xxxxxxxxxx
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 ...
-------------- next part --------------
A non-text attachment was scrubbed...
Name: acpi-bios-pci-rt-fixes.patch
Type: text/x-patch
Size: 49220 bytes
Desc: not available
Url :
http://lists.xensource.com/archives/html/xen-devel/attachments/20061012/
34239df8/acpi-bios-pci-rt-fixes.bin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: acpi-bios-pci-rt-fixes-after-xen-platform-dsdt-fix.patch
Type: text/x-patch
Size: 48537 bytes
Desc: not available
Url :
http://lists.xensource.com/archives/html/xen-devel/attachments/20061012/
34239df8/acpi-bios-pci-rt-fixes-after-xen-platform-dsdt-fix.bin
------------------------------
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
End of Xen-devel Digest, Vol 20, Issue 93
*****************************************
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home