linux-kernel - Re: [PATCH] pci: enable MSI on 8132

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: <499FD623.1010105@kernel.org>
Date:	Sat, 21 Feb 2009 02:23:31 -0800
From:	Yinghai Lu <yinghai@...nel.org>
To:	"Eric W. Biederman" <ebiederm@...ssion.com>
CC:	Robert Hancock <hancockrwd@...il.com>,
	Jesse Barnes <jbarnes@...tuousgeek.org>,
	Andrew Morton <akpm@...ux-foundation.org>, david@...g.hm,
	Matthew Wilcox <matthew@....cx>,
	linux-kernel <linux-kernel@...r.kernel.org>,
	linux-scsi@...r.kernel.org, DL-MPTFusionLinux@....com,
	linux-pci@...r.kernel.org
Subject: Re: [PATCH] pci: enable MSI on 8132

Eric W. Biederman wrote:
> Yinghai Lu <yinghai@...nel.org> writes:
> 
>> On Fri, Feb 20, 2009 at 11:50 PM, Eric W. Biederman
>> <ebiederm@...ssion.com> wrote:
>>> Robert Hancock <hancockrwd@...il.com> writes:
>>>> Is there a reason why we can't just enable the HT MSI mapping for any bridge
>>>> device that has that PCI capability and is underneath an HT bridge?
>>> The code should be under CONFIG_X86 because the rules for enabling HT MSI
>> mappings
>>> are different for other architectures.  But otherwise I can't think of a
>> reason.
>>
>> move to arch/x86/pci/fixup.c?
>>
>> it seems some other arch do support HT ... powerpc, mips?
> 
> The difference is that there is a magic address on x86 that all MSI
> cycles are sent to.  I think it is 0xfffe0000.  In an msi to HT
> mapping capability it is necessary to program in the address to listen
> for msi packets.  That is very much an arch dependent thing.
> 
>>>> Essentially
>>>> the code for nv_msi_ht_cap_quirk could potentially be applied to all bridges
>> as
>>>> it is currently for NVIDIA and ALi bridges..
>>> Sounds like it would save a fair amount of grief.
>> it seems there is some difference.
>> 8132 is some kind of HT tunnel, and the bridge is acctually pci-x bridge.
>>
>> mcp55 and ck804: is HT end device with several pcie bridges.
> 
> Not really they are all hypertransport to pci bridges (of some flavor).
> But any hypertransport device is allowed to have a mapping capability.
> In which case they can implement normal MSI interrupts instead of the
> weird hypertransport ones.
for mcp55
00:00.0 is HT device
00:0b.0 00:0c.0, 00:0d.0, 00:0e.0, 00:0f.0 are pcie bridge.
current quirks will check 00:00.0 HT MSI is set, it will not set that in those bridges any more.

> 
>> also 8131 has problem with HT MSI?
> 
> The 8131 does not implement the msi to hypertransport mapping
> capability so it can not support MSI interrupts.
it seems there is one quirks to disable MSI for 8131.
/* Disable MSI on chipsets that are known to not support it */
static void __devinit quirk_disable_msi(struct pci_dev *dev)
{
        if (dev->subordinate) {
                dev_warn(&dev->dev, "MSI quirk detected; "
                        "subordinate MSI disabled\n");
                dev->subordinate->bus_flags |= PCI_BUS_FLAGS_NO_MSI;
        }
}
DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_8131_BRIDGE, quirk_disable_msi);


> 
> 
> In general on x86, if a device has a MSI to hypertransport mapping
> capability then we can enable it and mark that devices and all
> downstream devices as supporting MSI.

looks some aggressive.

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